From owner-ietf-ediint@mail.imc.org Fri Apr 1 17:49:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29408 for ; Fri, 1 Apr 2005 17:49:32 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31Md4PG011062; Fri, 1 Apr 2005 14:39:04 -0800 (PST) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j31Md488011061; Fri, 1 Apr 2005 14:39:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from drummondgroup.com (drummondgroup.com [161.58.166.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31Md3rl011055 for ; Fri, 1 Apr 2005 14:39:03 -0800 (PST) (envelope-from kyle@drummondgroup.com) Received: from KYLEDGILAPTOP (pcp517486pcs.nash01.tn.comcast.net [68.53.139.87]) by drummondgroup.com (8.12.11/8.12.11) with ESMTP id j31Md2DO084331; Fri, 1 Apr 2005 15:39:02 -0700 (MST) Message-Id: <200504012239.j31Md2DO084331@drummondgroup.com> From: "Kyle Meadors" To: "'Dmitry Dolinsky'" , Subject: RE: Filename in AS2 messages Date: Fri, 1 Apr 2005 16:39:06 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUw44P8NK/8KOS3SQmk7ZhLgdoKXAGJwudA In-Reply-To: <6.2.1.2.0.20050324182819.06a4b298@rwcexvs01.tumbleweed.com> Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Dmitry Dolinsky Sent: Thursday, March 24, 2005 8:28 PM To: ietf-ediint@imc.org 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 " 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 From owner-ietf-ediint@mail.imc.org Fri Apr 1 18:11:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01529 for ; Fri, 1 Apr 2005 18:11:26 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31N0q87012126; Fri, 1 Apr 2005 15:00:52 -0800 (PST) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j31N0qwX012125; Fri, 1 Apr 2005 15:00:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [216.138.89.24]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31N0pwY012114 for ; Fri, 1 Apr 2005 15:00:51 -0800 (PST) (envelope-from dmoberg@cyclonecommerce.com) Received: from usazscsmh1.cyclonecommerce.com [10.1.0.24] by spyglass.cyclonecommerce.com with XWall v3.31h ; Fri, 1 Apr 2005 16:00:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Filename in AS2 messages Date: Fri, 1 Apr 2005 16:00:44 -0700 Message-ID: Thread-Topic: Filename in AS2 messages Thread-Index: AcUw44P8NK/8KOS3SQmk7ZhLgdoKXAGJwudAAACkLuA= From: "Dale Moberg" To: "Kyle Meadors" , "Dmitry Dolinsky" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j31N0pwY012120 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit 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@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Kyle Meadors Sent: Friday, April 01, 2005 3:39 PM To: 'Dmitry Dolinsky'; ietf-ediint@imc.org 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@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Dmitry Dolinsky Sent: Thursday, March 24, 2005 8:28 PM To: ietf-ediint@imc.org 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 " 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 From kecia@access-one.com Sat Apr 2 23:19:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21275 for ; Sat, 2 Apr 2005 23:19:36 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHwhx-0003E9-0S for ediint-archive@ietf.org; Sat, 02 Apr 2005 23:27:34 -0500 Received: from [61.11.8.16] (helo=61.11.8.16) by mx2.foretec.com with smtp (Exim 4.24) id 1DHwaF-00038P-2s for ediint-archive@ietf.org; Sat, 02 Apr 2005 23:19:36 -0500 Message-ID: From: "Vanessa J. Smith" To: ediint-archive@ietf.org Subject: =?iso-8859-1?B?TWFjcm9tZWRpYSBTdHVkaW8gTVggMjAwNCAtIDc1JSBPRkY=?= Date: Sun, 03 Apr 2005 04:07:39 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_0BECCAAA.6968C5E8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 23.0 (+++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 31247fb3be228bb596db9127becad0bc This is a multi-part message in MIME format. ------=_NextPart_000_0000_0BECCAAA.6968C5E8 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_5D627298.FA4F3122" ------=_NextPart_001_0001_5D627298.FA4F3122 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Access all the popular software you ever imagined for bottom prices! Our software is 2-10 times cheaper than sold by our competitors. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 Quark Xpress 6 Passport Multilanguage Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... For full list of products go: http://www.oemunlimited.biz Regards, Vanessa J. Smith _____________________________________________________ To change your mail details, go: http://www.oemunlimited.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_5D627298.FA4F3122 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Access all the popular software you ever imagined for unbelievably low prices!
Our software is 2-10 times cheaper than sold by our competitors.

Just a few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 Quark Xpress 6 Passport Multilanguage

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many other... Enter here:

http://www.oemunlimited.biz

Best regards,
Vanessa Smith


_____________________________________________________
To be taken out, go: http://www.oemunlimited.biz/uns.htm
_____________________________________________________

------=_NextPart_001_0001_5D627298.FA4F3122-- ------=_NextPart_000_0000_0BECCAAA.6968C5E8-- From owner-ietf-ediint@mail.imc.org Mon Apr 4 13:10:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29299 for ; Mon, 4 Apr 2005 13:10:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34Gw5iQ046936; Mon, 4 Apr 2005 09:58:05 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34Gw5M5046935; Mon, 4 Apr 2005 09:58:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34Gw2L5046913 for ; Mon, 4 Apr 2005 09:58:05 -0700 (PDT) (envelope-from dmitry.dolinsky@tumbleweed.com) Received: from 10.1.5.15 by mms2-dmz.tumbleweed.com with ESMTP ( Tumbleweed MMS SMTP Relay (Email Firewall v6.1.0)); Mon, 04 Apr 2005 10:02:42 -0700 X-Server-Uuid: CACBA3D1-98E2-4A10-9C71-AA596331CC64 Received: from gilmore.tumbleweed.com (GILMORE [10.1.214.81]) by pigeon.corp.tumbleweed.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GV6FZM1L; Mon, 4 Apr 2005 09:57:34 -0700 Message-ID: <6.2.1.2.0.20050404095100.05e18008@rwcexvs01.tumbleweed.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 04 Apr 2005 09:56:15 -0700 To: "Kyle Meadors" , ietf-ediint@imc.org From: "Dmitry Dolinsky" Subject: RE: Filename in AS2 messages In-Reply-To: <200504012239.j31Md2DO084331@drummondgroup.com> References: <6.2.1.2.0.20050324182819.06a4b298@rwcexvs01.tumbleweed.com> <200504012239.j31Md2DO084331@drummondgroup.com> MIME-Version: 1.0 X-WSS-ID: 6E4FACB81SW3727204-01-04 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kyle, We have seen people using AS2 to transfer files that are not necessarily EDI. In that case preserving the filenames does have a benefit. I've seem some discussion on this list about non-EDI payload in AS2. Is it something completely out of scope of AS2 specification? --Dmitry At 03:39 PM 4/1/2005, Kyle Meadors wrote: >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@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org] >On Behalf Of Dmitry Dolinsky >Sent: Thursday, March 24, 2005 8:28 PM >To: ietf-ediint@imc.org >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 " 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 " made the following annotations on 04/04/05 10:02:48 ------------------------------------------------------------------------------ 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. ============================================================================== From owner-ietf-ediint@mail.imc.org Mon Apr 4 14:06:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06179 for ; Mon, 4 Apr 2005 14:06:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34HuQhF052144; Mon, 4 Apr 2005 10:56:26 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34HuQA9052143; Mon, 4 Apr 2005 10:56:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34HuQAw052134 for ; Mon, 4 Apr 2005 10:56:26 -0700 (PDT) (envelope-from brent.haines@tumbleweed.com) Received: from 10.1.5.72 by mms2-dmz.tumbleweed.com with ESMTP ( Tumbleweed MMS SMTP Relay (Email Firewall v6.1.0)); Mon, 04 Apr 2005 11:01:22 -0700 X-Server-Uuid: CACBA3D1-98E2-4A10-9C71-AA596331CC64 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Filename in AS2 messages Date: Mon, 4 Apr 2005 10:56:20 -0700 Message-ID: <4EAC5BADAD46804CA829F8BBB74AB9264D259D@RWCEXVS01.corp.tumbleweed.com> Thread-Topic: Filename in AS2 messages Thread-Index: AcUw44P8NK/8KOS3SQmk7ZhLgdoKXAGJwudAAACkLuAAjEOPwA== From: "Brent Haines" To: "Dale Moberg" , "Kyle Meadors" , "Dmitry Dolinsky" , ietf-ediint@imc.org X-WSS-ID: 6E4F5F781SW3728536-01-04 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j34HuQAw052138 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit 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@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Dale Moberg Sent: Friday, April 01, 2005 3:01 PM To: Kyle Meadors; Dmitry Dolinsky; ietf-ediint@imc.org 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@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Kyle Meadors Sent: Friday, April 01, 2005 3:39 PM To: 'Dmitry Dolinsky'; ietf-ediint@imc.org 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@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Dmitry Dolinsky Sent: Thursday, March 24, 2005 8:28 PM To: ietf-ediint@imc.org 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 " 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 " 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. ============================================================================== From owner-ietf-ediint@mail.imc.org Mon Apr 4 15:15:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13749 for ; Mon, 4 Apr 2005 15:15:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34J1Ydb057259; Mon, 4 Apr 2005 12:01:34 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34J1YtZ057258; Mon, 4 Apr 2005 12:01:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from smtpred.systrends.com ([162.42.79.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34J1WVf057249 for ; Mon, 4 Apr 2005 12:01:32 -0700 (PDT) (envelope-from Shan@systrends.com) Content-Class: urn:content-classes:message Received: from systrend69a3f7 ([162.42.79.224]) by smtpred.systrends.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Apr 2005 11:58:44 -0700 Reply-To: From: "Shan Harter" To: "'Brent Haines'" , "'Dale Moberg'" , "'Kyle Meadors'" , "'Dmitry Dolinsky'" , Subject: RE: Filename in AS2 messages Date: Mon, 4 Apr 2005 11:59:58 -0700 Organization: Systrends Message-ID: <002101c53948$7f03a120$6400a8c0@systrend69a3f7> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <4EAC5BADAD46804CA829F8BBB74AB9264D259D@RWCEXVS01.corp.tumbleweed.com> X-OriginalArrivalTime: 04 Apr 2005 18:58:44.0546 (UTC) FILETIME=[53279A20:01C53948] Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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 .@ 1835122349.20050210084222_000@dev36.com.814_03_STK10.edi.pgp Other implementations took this approach _@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@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Brent Haines Sent: Monday, April 04, 2005 10:56 AM To: Dale Moberg; Kyle Meadors; Dmitry Dolinsky; ietf-ediint@imc.org 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@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Dale Moberg Sent: Friday, April 01, 2005 3:01 PM To: Kyle Meadors; Dmitry Dolinsky; ietf-ediint@imc.org 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@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Kyle Meadors Sent: Friday, April 01, 2005 3:39 PM To: 'Dmitry Dolinsky'; ietf-ediint@imc.org 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@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Dmitry Dolinsky Sent: Thursday, March 24, 2005 8:28 PM To: ietf-ediint@imc.org 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 " 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 " 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. From scuito@emailaccount.com Wed Apr 6 14:11:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11828; Wed, 6 Apr 2005 14:11:17 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJF8B-0008Ko-9n; Wed, 06 Apr 2005 14:20:00 -0400 Received: from s01060010dca1966e.lb.shawcable.net ([70.65.185.158]) by mx2.foretec.com with smtp (Exim 4.24) id 1DJEzl-0004wE-Go; Wed, 06 Apr 2005 14:11:17 -0400 Received: from freak-jcoppens.com (EHLO injunct.jcoppens.com) by wolcott.jcoppens.com with SMTP; Wed, 06 Apr 2005 18:03:43 -0100 Date: Wed, 06 Apr 2005 12:01:43 -0700 From: "Earnest Curry" To: drafts@ietf.org Cc: drums-archive@ietf.org, dvsqhmanet@ietf.org, dxnvmrouting-discussion-admin@ietf.org, e@ietf.org, e3@ietf.org, eamoby@ietf.org, eap-archive@ietf.org, eb-archive@ietf.org, eccmtmagma-admin@ietf.org, ediint-archive@ietf.org, edu-discuss@ietf.org, edu-discuss-admin@ietf.org, edu-discuss-web-archive@ietf.org, edu-team@ietf.org Subject: High rates? Not with us! low fixed rate Message-ID: X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [932], SpamtestISP/Release X-Mailer: MIME-tools 5.41 (Entity 5.404) X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Felipe Summers to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From owner-ietf-ediint@mail.imc.org Wed Apr 6 15:53:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24397 for ; Wed, 6 Apr 2005 15:53:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j36JgfKF054342; Wed, 6 Apr 2005 12:42:41 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j36JgfjA054341; Wed, 6 Apr 2005 12:42:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j36Jgejh054328 for ; Wed, 6 Apr 2005 12:42:40 -0700 (PDT) (envelope-from dmitry.dolinsky@tumbleweed.com) Received: from 10.1.5.15 by mms2-dmz.tumbleweed.com with ESMTP ( Tumbleweed MMS SMTP Relay (Email Firewall v6.1.0)); Wed, 06 Apr 2005 12:47:37 -0700 X-Server-Uuid: CACBA3D1-98E2-4A10-9C71-AA596331CC64 Received: from gilmore.tumbleweed.com (GILMORE [10.1.214.81]) by pigeon.corp.tumbleweed.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GV6FZMS3; Wed, 6 Apr 2005 12:42:24 -0700 Message-ID: <6.2.1.2.0.20050406123649.063aac90@rwcexvs01.tumbleweed.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 06 Apr 2005 12:42:21 -0700 To: shan.harter@systrends.com, "'Brent Haines'" , "'Dale Moberg'" , "'Kyle Meadors'" , ietf-ediint@imc.org From: "Dmitry Dolinsky" Subject: RE: Filename in AS2 messages In-Reply-To: <002101c53948$7f03a120$6400a8c0@systrend69a3f7> References: <4EAC5BADAD46804CA829F8BBB74AB9264D259D@RWCEXVS01.corp.tumbleweed.com> <002101c53948$7f03a120$6400a8c0@systrend69a3f7> MIME-Version: 1.0 X-WSS-ID: 6E4AE3521SW3763976-01-04 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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 > >.@ > >1835122349.20050210084222_000@dev36.com.814_03_STK10.edi.pgp > >Other implementations took this approach > >_@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@mail.imc.org >[mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Brent Haines >Sent: Monday, April 04, 2005 10:56 AM >To: Dale Moberg; Kyle Meadors; Dmitry Dolinsky; ietf-ediint@imc.org >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@mail.imc.org >[mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Dale Moberg >Sent: Friday, April 01, 2005 3:01 PM >To: Kyle Meadors; Dmitry Dolinsky; ietf-ediint@imc.org >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@mail.imc.org >[mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Kyle Meadors >Sent: Friday, April 01, 2005 3:39 PM >To: 'Dmitry Dolinsky'; ietf-ediint@imc.org >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@mail.imc.org >[mailto:owner-ietf-ediint@mail.imc.org] >On Behalf Of Dmitry Dolinsky >Sent: Thursday, March 24, 2005 8:28 PM >To: ietf-ediint@imc.org >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 " 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 " 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 " 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. ============================================================================== From owner-ietf-ediint@mail.imc.org Wed Apr 6 18:11:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10756 for ; Wed, 6 Apr 2005 18:11:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j36Lw7wW063874; Wed, 6 Apr 2005 14:58:07 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j36Lw7Lq063873; Wed, 6 Apr 2005 14:58:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [216.138.89.24]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j36Lw5T7063849 for ; Wed, 6 Apr 2005 14:58:06 -0700 (PDT) (envelope-from dmoberg@cyclonecommerce.com) Received: from usazscsmh1.cyclonecommerce.com [10.1.0.24] by spyglass.cyclonecommerce.com with XWall v3.31h ; Wed, 6 Apr 2005 14:57:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Filename in AS2 messages Date: Wed, 6 Apr 2005 14:57:58 -0700 Message-ID: Thread-Topic: Filename in AS2 messages Thread-Index: AcU64MpKi26DJnNgQj+7wU8qM22PmQAETPEA From: "Dale Moberg" To: "Dmitry Dolinsky" , , "Brent Haines" , "Kyle Meadors" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j36Lw6T7063861 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I still have several questions: 1. Is there an interoperability problem caused by varying interpretations of the "Content-disposition" header? What is it? What failure or error is caused? 2. Is the intent to require the use of "Content-Disposition" and to also require that the header be used to say what the name of the file was at the sender side? If so, this functionality might be better addressed by using the "Content-description" header. The content-disposition "filename" parameter has specified semantics of suggesting processing at the receiving end (that is, how the bodypart is "disposed of"). If the point of the information is to permit logging/tracking/diagnostics, it does not seem that content-disposition is a good semantic fit. We are saying: here is the filename we are suggesting that you use for the file, but by the way, don't use it. 3. If we required a filename, what about deployments where data is not obtained from a file system, but from a stream, pipe, queue, or database blob? -----Original Message----- From: Dmitry Dolinsky [mailto:dmitry.dolinsky@tumbleweed.com] Sent: Wednesday, April 06, 2005 12:42 PM To: shan.harter@systrends.com; 'Brent Haines'; Dale Moberg; 'Kyle Meadors'; ietf-ediint@imc.org 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 > >.@ > >1835122349.20050210084222_000@dev36.com.814_03_STK10.edi.pgp > >Other implementations took this approach > >_@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@mail.imc.org >[mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Brent Haines >Sent: Monday, April 04, 2005 10:56 AM >To: Dale Moberg; Kyle Meadors; Dmitry Dolinsky; ietf-ediint@imc.org >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@mail.imc.org >[mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Dale Moberg >Sent: Friday, April 01, 2005 3:01 PM >To: Kyle Meadors; Dmitry Dolinsky; ietf-ediint@imc.org >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@mail.imc.org >[mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Kyle Meadors >Sent: Friday, April 01, 2005 3:39 PM >To: 'Dmitry Dolinsky'; ietf-ediint@imc.org >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@mail.imc.org >[mailto:owner-ietf-ediint@mail.imc.org] >On Behalf Of Dmitry Dolinsky >Sent: Thursday, March 24, 2005 8:28 PM >To: ietf-ediint@imc.org >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 " 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 " 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 " 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. ======================================================================== ====== From owner-ietf-ediint@mail.imc.org Wed Apr 6 20:30:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25575 for ; Wed, 6 Apr 2005 20:30:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j36JpRrO055235; Wed, 6 Apr 2005 12:51:27 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j36JpRTJ055234; Wed, 6 Apr 2005 12:51:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from smtpred.systrends.com ([162.42.79.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j36JpQ2j055228 for ; Wed, 6 Apr 2005 12:51:26 -0700 (PDT) (envelope-from Shan@systrends.com) Content-Class: urn:content-classes:message Received: from systrend69a3f7 ([162.42.79.224]) by smtpred.systrends.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 6 Apr 2005 12:48:37 -0700 Reply-To: From: "Shan Harter" To: "'Dmitry Dolinsky'" , , "'Brent Haines'" , "'Dale Moberg'" , "'Kyle Meadors'" , Subject: RE: Filename in AS2 messages Date: Wed, 6 Apr 2005 12:49:48 -0700 Organization: Systrends Message-ID: <001901c53ae1$ca02f050$6400a8c0@systrend69a3f7> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <6.2.1.2.0.20050406123649.063aac90@rwcexvs01.tumbleweed.com> X-OriginalArrivalTime: 06 Apr 2005 19:48:37.0562 (UTC) FILETIME=[9FF519A0:01C53AE1] Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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@tumbleweed.com] Sent: Wednesday, April 06, 2005 12:42 PM To: shan.harter@systrends.com; 'Brent Haines'; 'Dale Moberg'; 'Kyle Meadors'; ietf-ediint@imc.org 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 > >.@ > >1835122349.20050210084222_000@dev36.com.814_03_STK10.edi.pgp > >Other implementations took this approach > >_@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@mail.imc.org >[mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Brent Haines >Sent: Monday, April 04, 2005 10:56 AM >To: Dale Moberg; Kyle Meadors; Dmitry Dolinsky; ietf-ediint@imc.org >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@mail.imc.org >[mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Dale Moberg >Sent: Friday, April 01, 2005 3:01 PM >To: Kyle Meadors; Dmitry Dolinsky; ietf-ediint@imc.org >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@mail.imc.org >[mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Kyle Meadors >Sent: Friday, April 01, 2005 3:39 PM >To: 'Dmitry Dolinsky'; ietf-ediint@imc.org >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@mail.imc.org >[mailto:owner-ietf-ediint@mail.imc.org] >On Behalf Of Dmitry Dolinsky >Sent: Thursday, March 24, 2005 8:28 PM >To: ietf-ediint@imc.org >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 " 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 " 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 " 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. From azelrnaeiilj@gamedev.net Thu Apr 7 14:07:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21269; Thu, 7 Apr 2005 14:07:50 -0400 (EDT) Date: Thu, 7 Apr 2005 14:07:50 -0400 (EDT) Received: from gen92-4-82-235-10-136.fbx.proxad.net ([82.235.10.136]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJbYZ-0004wz-Lu; Thu, 07 Apr 2005 14:16:45 -0400 Received: from duopoly.gamedev.net ([208.254.3.160]) by lykes.free-hosting.lt (InterMail vK.4.04.00.00 976-723-645 license 135078mi97wl1tul7mq336b3b32z3f95) with ESMTP id <20035034726418.YETO827.lykes@duopoly.gamedev.net> for ; Thu, 07 Apr 2005 13:07:39 -0600 Received: from diaphragm (primacy.gamedev.net [209.157.71.50]) by duopoly.gamedev.net (Mirapoint Messaging Server MOS 3.3.8-GR) with SMTP id CAI01150; Thu, 07 Apr 2005 16:03:39 -0300 (IST) Date: Thu, 07 Apr 2005 13:07:39 -0600 From: Kellie Goss Subject: Online Pharmacy To: References: In-Reply-To: Message-ID: <241426768379.DGS10886@freeze.com>primacy.gamedev.net> Message-ID: <241426768379.DGS10886@freeze.com> MIME-version: 1.0 Content-Type: multipart/alternative; boundary="----_001_4274_36P90VY2.90HF9876" X-Mailer: CommuniGate Pro WebUser Interface v.4.1.6 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a This is a multi-part message in MIME format. ------_001_4274_36P90VY2.90HF9876 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Hi, You can buy the most wanted medications from our site. we sell ViCODiN(179 $),VALiUM(169 $) and ViAGRA(199 $) at a very reasonable price. we ship worldwide and no prescription is needed. http://www.grx-meds.com/scripts/default.asp?idaff=110 Cheapest Online Pharmacy ------_001_4274_36P90VY2.90HF9876 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7Bit Hi,
You can buy the most wanted medications from our site.
we sell ViCODiN(179 $),VALiUM(169 $) and ViAGRA(199 $) at a very reasonable price.
we ship worldwide and no prescription is needed.
Cheapest Online Pharmacy ------_001_4274_36P90VY2.90HF9876-- From owner-ietf-ediint@mail.imc.org Thu Apr 7 17:27:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10133 for ; Thu, 7 Apr 2005 17:27:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37LFRCj017549; Thu, 7 Apr 2005 14:15:27 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37LFRp7017548; Thu, 7 Apr 2005 14:15:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from smtpred.systrends.com ([162.42.79.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37LFPEP017540 for ; Thu, 7 Apr 2005 14:15:26 -0700 (PDT) (envelope-from Shan@systrends.com) Content-Class: urn:content-classes:message Received: from systrend69a3f7 ([70.190.21.66]) by smtpred.systrends.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Apr 2005 14:12:39 -0700 Reply-To: From: "Shan Harter" To: "'Dale Moberg'" , "'Dmitry Dolinsky'" , "'Brent Haines'" , "'Kyle Meadors'" , Cc: "'Farley, David'" Subject: RE: Filename in AS2 messages Date: Thu, 7 Apr 2005 14:13:36 -0700 Organization: Systrends Message-ID: <003f01c53bb6$b0715070$eb00a8c0@systrend69a3f7> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-OriginalArrivalTime: 07 Apr 2005 21:12:39.0343 (UTC) FILETIME=[878193F0:01C53BB6] Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have run out of time to go more in depth, but here are some of the topics (hopefully complete in thought) for consideration: Although I believe this originally was addressed to Dmitry, I can add some value from the question posed to me regarding the company that regards file naming to be an industry issue (Utility - ERCOT). The standard deployed is different but has very similar ideas around names. For this reason there is less disparity and more concomitant aspects that deserves some attention for this discussion. The MIME header concept and compliancy standards are the same between the two. Both are HTTP posts and comply with RFC 1767. Both allow for SSL (TLS) connections and both require receipts and error notification of some form. Both also encrypt the payload, albeit one uses Open PGP (Gnupg) or PGP and the other uses S/MIME. The subject of the headers in the clear is removed by the use of SSL in both cases. The point is they have very similar attributes and serve the same function. The concept of file naming as a design feature for a system to take action based on content is the real subject. For the content AS2 chooses the form Content-Type: application/EDI-X12; name=CompanyZHeader-1024.edi and Content-Disposition: attachment; filename=SYSTREND_TO_ZZIDDXIE_105.edi So there are a few options here with AS2 more than NAESB. NAESB chooses the form "Content-type: application/EDI-X12" with no mention of file name at the encrypted level and references the file name as part of the unencrypted MIME (except for SSL) Content-Disposition: form-data; name="input-data"; filename="E:\MBPostOffice\MAILBOXES\texas_new_mexico_power_tsp\OUT\997.T NMP3Clay3.edi.pgp" Specifically, from the specification, "When the sender of a file intends to use encryption and digital signature functions to secure the contents of a data file the file must be prepared in accordance with the above mentioned IETF standards. ASC X12 data must first be prepared in canonical form as specified in RFC 1767. The ASC X12 data file would be concatenated with the MIME Content-type of application/EDI-X12 as the first line of the file. For example below is a file before encryption: Content-type: application/EDI-X12 ISA~00~ ~01~AAA6300300~14~1234567890000 ~14~2345678900000 ... more data from the X12 file. IEA~1~000003616 This file is encrypted, signed and packaged, which follows EDIINT AS1 and RFC 2015, which produces a file containing MIME headers and encrypted content as follows." "Below is the file after encryption: Content-Type: multipart/encrypted; boundary=8760; protocol="application/pgp-encrypted" --8760 Content-Type: application/pgp-encrypted Version: 1" The interoperability problem occurs when x number of 300 trading partners potentially send the same file name, such as payload.edi. The issue may not be as obvious at the front end due to "mailboxing" techniques that obscure the problem by segregation. Both NAESB and AS2 make no allowances for naming collisions that occur. In this case file routing becomes a problem and unique naming is lost. The syntax of unique naming (perhaps a derivative of the contextual values used in the system identifiers) could be solved by nomenclature similar to AS2 draft 20 Paragraph 5.3.3 Message-ID with an added domain name (registered domain), sequence and timestamp and or counter. A counter is required for applications that can process files less than a second. Above are some of the requirements that ERCOT had to deploy on within their internet transaction application for both ebXML and NAESB protocols. Their real intent was to create an industry wide standard that would take care of this for them such as mentioned above. In addition, Farley's suggestion (copied on this email) is to allow a application content type that is open. In this way the Content-Type: application/EDI-something; or Content-Type: application/something; could be the format but not the exact content similar to Content-Type: application/MutuallyDefined; name= .@. Where all values (and syntax) within < > are to be defined. This would have the objective of minimal impact on say RFC 1767. Content-Type: application/EDI-X12 Content-Type: application/EDIFACT Content-Type: application/edi-consent Content-Type: application/XML Content-Type: application/MutuallyDefined Adding the virtually unlimited number of permutations of names and content types would be a monumental task and is not recommended. This mutually defined syntax would work regardless of the sending entity and regardless of the source of the "file" (aka database blob, message queue, etc.). However, the application would have to make allowances to define what MutuallyDefined really meant per the implementation. This is easily solved with minor user input fields that define what it means (which do not need to be in the standard). Just as both users of AS2 must define their trading partner agreement (aka sign or not sign). Mutually defined may require a lookup once received in order to interpret the agreement. This also keeps the RFC's general and very broad as they are today. On other comments, the "Content-Disposition" or "Content-Type" such as: Content-Type: application/EDI-X12; name=xxxxxx.edi Content-Disposition: attachment; filename=xxxxxx.edi should not be in the header (as AS2 does not do now), unless the user chooses not to encrypt. There are many options that could/should be discussed and are beyond the scope of this email. Dave Farley with ERCOT may want to join the group so he can add his knowledge and input. Shan -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Wednesday, April 06, 2005 2:58 PM To: Dmitry Dolinsky; shan.harter@systrends.com; Brent Haines; Kyle Meadors; ietf-ediint@imc.org Subject: RE: Filename in AS2 messages I still have several questions: 1. Is there an interoperability problem caused by varying interpretations of the "Content-disposition" header? What is it? What failure or error is caused? 2. Is the intent to require the use of "Content-Disposition" and to also require that the header be used to say what the name of the file was at the sender side? If so, this functionality might be better addressed by using the "Content-description" header. The content-disposition "filename" parameter has specified semantics of suggesting processing at the receiving end (that is, how the bodypart is "disposed of"). If the point of the information is to permit logging/tracking/diagnostics, it does not seem that content-disposition is a good semantic fit. We are saying: here is the filename we are suggesting that you use for the file, but by the way, don't use it. 3. If we required a filename, what about deployments where data is not obtained from a file system, but from a stream, pipe, queue, or database blob? -----Original Message----- From: Dmitry Dolinsky [mailto:dmitry.dolinsky@tumbleweed.com] Sent: Wednesday, April 06, 2005 12:42 PM To: shan.harter@systrends.com; 'Brent Haines'; Dale Moberg; 'Kyle Meadors'; ietf-ediint@imc.org 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 > >.@ > >1835122349.20050210084222_000@dev36.com.814_03_STK10.edi.pgp > >Other implementations took this approach > >_@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@mail.imc.org >[mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Brent Haines >Sent: Monday, April 04, 2005 10:56 AM >To: Dale Moberg; Kyle Meadors; Dmitry Dolinsky; ietf-ediint@imc.org >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@mail.imc.org >[mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Dale Moberg >Sent: Friday, April 01, 2005 3:01 PM >To: Kyle Meadors; Dmitry Dolinsky; ietf-ediint@imc.org >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@mail.imc.org >[mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Kyle Meadors >Sent: Friday, April 01, 2005 3:39 PM >To: 'Dmitry Dolinsky'; ietf-ediint@imc.org >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@mail.imc.org >[mailto:owner-ietf-ediint@mail.imc.org] >On Behalf Of Dmitry Dolinsky >Sent: Thursday, March 24, 2005 8:28 PM >To: ietf-ediint@imc.org >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 " 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 " 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 " 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. From pthoms@fadmail.com Fri Apr 8 05:47:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27868; Fri, 8 Apr 2005 05:47:53 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJq4y-0001od-VM; Fri, 08 Apr 2005 05:47:10 -0400 Received: from j36015.upc-j.chello.nl ([24.132.36.15]) by mx2.foretec.com with smtp (Exim 4.24) id 1DJpwF-0003cc-Sr; Fri, 08 Apr 2005 05:38:08 -0400 Authentication-Results: quartzite.es from=premium.mexico.es; domainkeys=neutral (no sig) X-Originating-IP: [79.152.6.208] Received: from premium.desperate.es (EHLO premium.lectionary.es) by premium.bottommost.es with SMTP; Fri, 08 Apr 2005 13:38:52 +0300 Date: Fri, 08 Apr 2005 13:31:52 +0300 From: "Alison Castro" To: drafts@ietf.org Cc: drums-archive@ietf.org, dvsqhmanet@ietf.org, dxnvmrouting-discussion-admin@ietf.org, e@ietf.org, e3@ietf.org, eamoby@ietf.org, eap-archive@ietf.org, eb-archive@ietf.org, eccmtmagma-admin@ietf.org, ediint-archive@ietf.org, edu-discuss@ietf.org, edu-discuss-admin@ietf.org, edu-discuss-web-archive@ietf.org, edu-team@ietf.org Subject: Your account #2M7015 Message-ID: <119441.7259.pthoms@fadmail.com> X-Mailer: Kana Connect 6 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Bryan Savage to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From saul@doramail.com Fri Apr 8 05:48:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27970; Fri, 8 Apr 2005 05:47:59 -0400 (EDT) Received: from [219.255.124.24] (helo=MW0T1T8WEVK4XVF) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJq1i-0001cz-DY; Fri, 08 Apr 2005 05:43:48 -0400 Received: from apart.eduardo-rubicund.com (HELO chinatown.com 66.0.117.61) by dortmund.com with EMQP; Fri, 08 Apr 2005 06:29:14 -0400 Date: Fri, 08 Apr 2005 05:22:14 -0500 From: "Edgar Durham" Message-Id: To: drafts@ietf.org Cc: drums-archive@ietf.org, dvsqhmanet@ietf.org, dxnvmrouting-discussion-admin@ietf.org, e@ietf.org, e3@ietf.org, eamoby@ietf.org, eap-archive@ietf.org, eb-archive@ietf.org, eccmtmagma-admin@ietf.org, ediint-archive@ietf.org, edu-discuss@ietf.org, edu-discuss-admin@ietf.org, edu-discuss-web-archive@ietf.org, edu-team@ietf.org Subject: Save hundreds every month on low rates X-Mailer: CompuServe 7.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Lemuel Metcalf to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From owner-ietf-ediint@mail.imc.org Fri Apr 8 10:33:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25853 for ; Fri, 8 Apr 2005 10:33:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38EO3Gl066356; Fri, 8 Apr 2005 07:24:03 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38EO3rO066355; Fri, 8 Apr 2005 07:24:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38EO2l3066349 for ; Fri, 8 Apr 2005 07:24:02 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24989; Fri, 8 Apr 2005 10:24:00 -0400 (EDT) Message-Id: <200504081424.KAA24989@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ediint@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ediint-as3-03.txt Date: Fri, 08 Apr 2005 10:23:59 -0400 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Electronic Data Interchange-Internet Integration Working Group of the IETF. Title : FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet Author(s) : T. Harding, R. Scott Filename : draft-ietf-ediint-as3-03.txt Pages : 29 Date : 2005-4-7 This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content-types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ediint-as3-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ediint-as3-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ediint-as3-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-8105738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ediint-as3-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ediint-as3-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-8105738.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ediint@mail.imc.org Fri Apr 8 13:20:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15248 for ; Fri, 8 Apr 2005 13:20:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38H6WQr082285; Fri, 8 Apr 2005 10:06:32 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38H6WvR082284; Fri, 8 Apr 2005 10:06:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38H6VH6082275 for ; Fri, 8 Apr 2005 10:06:31 -0700 (PDT) (envelope-from dmitry.dolinsky@tumbleweed.com) Received: from 10.1.5.15 by mms2-dmz.tumbleweed.com with ESMTP ( Tumbleweed MMS SMTP Relay (Email Firewall v6.1.0)); Fri, 08 Apr 2005 10:11:32 -0700 X-Server-Uuid: CACBA3D1-98E2-4A10-9C71-AA596331CC64 Received: from caelum.tumbleweed.com (172.20.1.12 [172.20.1.12]) by pigeon.corp.tumbleweed.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GV6FZM8H; Fri, 8 Apr 2005 10:06:12 -0700 Message-ID: <6.2.1.2.0.20050408095230.04df0460@rwcexvs01.tumbleweed.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 08 Apr 2005 10:06:07 -0700 To: "Dale Moberg" , shan.harter@systrends.com, "Brent Haines" , "Kyle Meadors" , ietf-ediint@imc.org From: "Dmitry Dolinsky" Subject: RE: Filename in AS2 messages In-Reply-To: References: MIME-Version: 1.0 X-WSS-ID: 6E4864CE1SW3795725-01-04 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dale, At 02:57 PM 4/6/2005, Dale Moberg wrote: >I still have several questions: > >1. Is there an interoperability problem caused by varying >interpretations of the "Content-disposition" header? What is it? What >failure or error is caused? We have not actually tested that. It's just that AS2 spec is silent on the matter. Do you have reasons to believe that Content-disposition is generally supported by the current known AS2 implementations? I did not see it in OpenAS2, for example. >2. Is the intent to require the use of "Content-Disposition" and to also >require that the header be used to say what the name of the file was at >the sender side? > >If so, this functionality might be better addressed by using the >"Content-description" header. The content-disposition "filename" >parameter has specified semantics of suggesting processing at the >receiving end (that is, how the bodypart is "disposed of"). If the >point of the information is to permit logging/tracking/diagnostics, it >does not seem that content-disposition is a good semantic fit. We are >saying: here is the filename we are suggesting that you use for the >file, but by the way, don't use it. What I like about the content-disposition is that there is a clearly defined standard for specifying the filename using that header. Not only that, but also it's used widely in email and web. It's also specified that the header is optional. If we go with "Content-description" we would need to additionally specify how it is to be used, formatted. It seems to me that AS2 (quite wisely) mainly relies on the existing and popular standards. Use of "Content-Disposition" is more in the same spirit. Beyond that I do not have a strong opinion as long as this point gets addressed in some way. >3. If we required a filename, what about deployments where data is not >obtained from a file system, but from a stream, pipe, queue, or database >blob? I think it should be a "should" and a "must". --Dmitry >-----Original Message----- >From: Dmitry Dolinsky [mailto:dmitry.dolinsky@tumbleweed.com] >Sent: Wednesday, April 06, 2005 12:42 PM >To: shan.harter@systrends.com; 'Brent Haines'; Dale Moberg; 'Kyle >Meadors'; ietf-ediint@imc.org >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 > > > >.@ > > > >1835122349.20050210084222_000@dev36.com.814_03_STK10.edi.pgp > > > >Other implementations took this approach > > > >_@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@mail.imc.org > >[mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Brent Haines > >Sent: Monday, April 04, 2005 10:56 AM > >To: Dale Moberg; Kyle Meadors; Dmitry Dolinsky; ietf-ediint@imc.org > >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@mail.imc.org > >[mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Dale Moberg > >Sent: Friday, April 01, 2005 3:01 PM > >To: Kyle Meadors; Dmitry Dolinsky; ietf-ediint@imc.org > >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@mail.imc.org > >[mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Kyle Meadors > >Sent: Friday, April 01, 2005 3:39 PM > >To: 'Dmitry Dolinsky'; ietf-ediint@imc.org > >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@mail.imc.org > >[mailto:owner-ietf-ediint@mail.imc.org] > >On Behalf Of Dmitry Dolinsky > >Sent: Thursday, March 24, 2005 8:28 PM > >To: ietf-ediint@imc.org > >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 " 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 " 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 " 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. >======================================================================== >====== "Tumbleweed E-mail Firewall " made the following annotations on 04/08/05 10:11:41 ------------------------------------------------------------------------------ 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. ============================================================================== From owner-ietf-ediint@mail.imc.org Fri Apr 8 14:07:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18725 for ; Fri, 8 Apr 2005 14:07:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38Hu1tv085326; Fri, 8 Apr 2005 10:56:01 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38Hu14g085325; Fri, 8 Apr 2005 10:56:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from spyglass.cyclonecommerce.com (spyglass.cyclonecommerce.com [216.138.89.24]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38Hu0AI085316 for ; Fri, 8 Apr 2005 10:56:00 -0700 (PDT) (envelope-from dmoberg@cyclonecommerce.com) Received: from usazscsmh1.cyclonecommerce.com [10.1.0.24] by spyglass.cyclonecommerce.com with XWall v3.31h ; Fri, 8 Apr 2005 10:55:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Filename in AS2 messages Date: Fri, 8 Apr 2005 10:55:53 -0700 Message-ID: Thread-Topic: Filename in AS2 messages Thread-Index: AcU8XVNJmVNmLbQTQCit98zxZ8suZgAABsMw From: "Dale Moberg" To: "Dmitry Dolinsky" , , "Brent Haines" , "Kyle Meadors" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j38Hu0AI085320 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Some specific responses and a general question at the end: > >1. Is there an interoperability problem caused by varying >interpretations of the "Content-disposition" header? What is it? What >failure or error is caused? We have not actually tested that. It's just that AS2 spec is silent on the matter. Do you have reasons to believe that Content-disposition is generally supported by the current known AS2 implementations? I did not see it in OpenAS2, for example. Dale>> Let's break the question down into receiver support and sender support. Receivers might support C-Disp., but since a receiver should ignore headers they don't understand, having a header should not cause a failure (if they are following the underlying specifications of AS2). Because AS2 does not mandate the use of C-Disp, no one should depend upon it being present. So at present a sender can add C-Disp or skip it, and interop should survive. By "support" do you mean "require senders to include the header"? If so, AS2 doesn't support it but interoperability should survive them being used. I think what you want is to be able to count on it being present for some reason. [And I am gathering from responses I have read here, that the general reason may be a desire to standardize the functionality of "receiver routing" (that is, an approach to defining what meta-information in the message will be used by the software to initiate specific processing after the AS2 defined behavior is completed.)] >2. Is the intent to require the use of "Content-Disposition" and to also >require that the header be used to say what the name of the file was at >the sender side? >If so, this functionality might be better addressed by using the >"Content-description" header. The content-disposition "filename" >parameter has specified semantics of suggesting processing at the >receiving end (that is, how the bodypart is "disposed of"). If the >point of the information is to permit logging/tracking/diagnostics, it >does not seem that content-disposition is a good semantic fit. We are >saying: here is the filename we are suggesting that you use for the >file, but by the way, don't use it. What I like about the content-disposition is that there is a clearly defined standard for specifying the filename using that header. Not only that, but also it's used widely in email and web. It's also specified that the header is optional. If we go with "Content-description" we would need to additionally specify how it is to be used, formatted. It seems to me that AS2 (quite wisely) mainly relies on the existing and popular standards. Use of "Content-Disposition" is more in the same spirit. Beyond that I do not have a strong opinion as long as this point gets addressed in some way. Dale>> OK, I am trying to identify what point needs addressing, and I apologize for being slow. I am now thinking that what you want is a set of meta-information items placed on the payload by the sender, that will allow the receiver to clearly identify that a specific payload is targeted for specific processing (after the successful completion of the AS2 specified behavior, of course). You are proposing using a sender assigned "filename" value as doing the job here (I think.) You have explored things such as "Content-type" and found them not doing what you want (too many very different message contents can all be of media-type "application/edifact" for example.) I agree with you that the MIME types don't generally work for the identifying task you have in mind. I am wondering whether filename values will do the job you want. If they do, the sender will need to always know what processing task needs to be done, and put the appropriate filename somewhere (preferably a reusable spot that does not violate the semantics). The problem is that no IETF headers that I know of actually have the semantics that you want them to have, so we would end up attaching a new function to an old header if we reused one. The closest is C-Description, that is so wide open, we can put any (syntactically ok) string in it. But unfortunately that is too wide open, because there are all kinds of descriptions which might fail to uniquely identify the intended processing task. So that does not work too well either... More recent protocols, in ebXML and in WS areas, have approached the topic by supplying additional constructs beyond the IETF ones, for indicating what is the intent of the message and what needs to be done with it. For example, in ebXML, there is metainformation (such as "Service" "Action" & "Role") that supplement the identification of the sender and receiver, to indicate--at whatever granularity is needed--what should happen in terms of intended subsequent processing phases. My own preference would be to add another header like "AS2-TransactionTypeIdentifier" and let it be specified to meet the requirements you are formulating. Unless there is something about the sender side filename that I am just missing, I don't see how it _must_ be able to help the receiver to decide what the next processing step is. It _might_ help, but not unless filenames were used with the same systematic care as TransactionTypeIdenfier values. (Some obvious candidates for these Transaction values from the EDI world would be 850, ORDERS, and so forth). (Would those transaction type values work for the problem you are conderned with, by the way?) >3. If we required a filename, what about deployments where data is not >obtained from a file system, but from a stream, pipe, queue, or database >blob? I think it should be a "should" and a "must". --Dmitry Dale> Not certain I get your meaning here. Do you mean "should" and not a "must"? If it's a "must to implement," "should implement" follows directly. =========== Am I getting close to identifying the requirements you are interested in or are you still thinking that "filename" values are exactly what is needed? From owner-ietf-ediint@mail.imc.org Fri Apr 8 17:26:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13669 for ; Fri, 8 Apr 2005 17:26:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38LFWug099158; Fri, 8 Apr 2005 14:15:32 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38LFWqG099157; Fri, 8 Apr 2005 14:15:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from mms2-dmz.tumbleweed.com (mms2-dmz.tumbleweed.com [216.148.232.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38LFWJl099141 for ; Fri, 8 Apr 2005 14:15:32 -0700 (PDT) (envelope-from dmitry.dolinsky@tumbleweed.com) Received: from 10.1.5.15 by mms2-dmz.tumbleweed.com with ESMTP ( Tumbleweed MMS SMTP Relay (Email Firewall v6.1.0)); Fri, 08 Apr 2005 14:20:37 -0700 X-Server-Uuid: CACBA3D1-98E2-4A10-9C71-AA596331CC64 Received: from caelum.tumbleweed.com (172.20.1.12 [172.20.1.12]) by pigeon.corp.tumbleweed.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GV6FZM0K; Fri, 8 Apr 2005 14:15:17 -0700 Message-ID: <6.2.1.2.0.20050408134746.04f953c8@rwcexvs01.tumbleweed.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 08 Apr 2005 14:15:13 -0700 To: "Dale Moberg" , shan.harter@systrends.com, "Brent Haines" , "Kyle Meadors" , ietf-ediint@imc.org From: "Dmitry Dolinsky" Subject: RE: Filename in AS2 messages In-Reply-To: References: MIME-Version: 1.0 X-WSS-ID: 6E482A2F1SW3800078-01-04 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think there are two issues that are perhaps related. 1. Preservation of the filename of the payload between the sender and receiver systems. 2. Ability to specify targeted processing (as you describe below) more generally. (1) is less ambitious goal and it's what I had in mind originally. We have certainly received requests for this functionality. (2) is also an interesting idea worth exploring. Content-Disposition solves (1) nicely, I think. However, I agree with you that it's probably too much of a stretch to convey (2) and a new AS2-specific header may be a better way to go. If there is a consensus towards doing (2) in a way that it addresses (1) as well, that may be a reasonable approach. I agree that including Content-Disposition should not break receiver that does not support it. A given implementation can include this header and use the information for storage and remain interoperable with other vendors. Of course, the filename preservation would not occur across different implementations and that's the core of my concern. With "should" and "must" I was trying to say that if AS2 specification calls for use of Content-Disposition header, it should not make at a hard requirement. It should recommend including the header on the sender side if the information is available and call for using it on the receiver side if the header is present. That way vendors concerned with filename preservation have a way of doing it in interoperable manner. In cases when filename is not important or desired or available, it does not have to be included. --Dmitry At 10:55 AM 4/8/2005, Dale Moberg wrote: >Some specific responses and a general question at the end: > > > > >1. Is there an interoperability problem caused by varying > >interpretations of the "Content-disposition" header? What is it? What > >failure or error is caused? > >We have not actually tested that. It's just that AS2 spec is silent on >the >matter. Do you have reasons to believe that Content-disposition is >generally supported by the current known AS2 implementations? I did not >see >it in OpenAS2, for example. > >Dale>> Let's break the question down into receiver support and sender >support. Receivers might support C-Disp., but since a receiver should >ignore headers they don't understand, having a header should not cause a >failure (if they are following the underlying specifications of AS2). >Because AS2 does not mandate the use of C-Disp, no one should depend >upon it being present. So at present a sender can add C-Disp or skip it, >and interop should survive. By "support" do you mean "require senders to >include the header"? If so, AS2 doesn't support it but interoperability >should survive them being used. I think what you want is to be able to >count on it being present for some reason. [And I am gathering from >responses I have read here, that the general reason may be a desire to >standardize the functionality of "receiver routing" (that is, an >approach to defining what meta-information in the message will be used >by the software to initiate specific processing after the AS2 defined >behavior is completed.)] > > >2. Is the intent to require the use of "Content-Disposition" and to >also > >require that the header be used to say what the name of the file was at > >the sender side? > >If so, this functionality might be better addressed by using the > >"Content-description" header. The content-disposition "filename" > >parameter has specified semantics of suggesting processing at the > >receiving end (that is, how the bodypart is "disposed of"). If the > >point of the information is to permit logging/tracking/diagnostics, it > >does not seem that content-disposition is a good semantic fit. We are > >saying: here is the filename we are suggesting that you use for the > >file, but by the way, don't use it. > >What I like about the content-disposition is that there is a clearly >defined standard for specifying the filename using that header. Not only > >that, but also it's used widely in email and web. It's also specified >that >the header is optional. >If we go with "Content-description" we would need to additionally >specify >how it is to be used, formatted. >It seems to me that AS2 (quite wisely) mainly relies on the existing and > >popular standards. Use of "Content-Disposition" is more in the same >spirit. >Beyond that I do not have a strong opinion as long as this point gets >addressed in some way. > >Dale>> OK, I am trying to identify what point needs addressing, and I >apologize for being slow. I am now thinking that what you want is a set >of meta-information items placed on the payload by the sender, that will >allow the receiver to clearly identify that a specific payload is >targeted for specific processing (after the successful completion of the >AS2 specified behavior, of course). You are proposing using a sender >assigned "filename" value as doing the job here (I think.) You have >explored things such as "Content-type" and found them not doing what you >want (too many very different message contents can all be of media-type >"application/edifact" for example.) I agree with you that the MIME types >don't generally work for the identifying task you have in mind. I am >wondering whether filename values will do the job you want. If they do, >the sender will need to always know what processing task needs to be >done, and put the appropriate filename somewhere (preferably a reusable >spot that does not violate the semantics). > >The problem is that no IETF headers that I know of actually have the >semantics that you want them to have, so we would end up attaching a new >function to an old header if we reused one. The closest is >C-Description, that is so wide open, we can put any (syntactically ok) >string in it. But unfortunately that is too wide open, because there are >all kinds of descriptions which might fail to uniquely identify the >intended processing task. So that does not work too well either... > >More recent protocols, in ebXML and in WS areas, have approached the >topic by supplying additional constructs beyond the IETF ones, for >indicating what is the intent of the message and what needs to be done >with it. For example, in ebXML, there is metainformation (such as >"Service" "Action" & "Role") that supplement the identification of the >sender and receiver, to indicate--at whatever granularity is >needed--what should happen in terms of intended subsequent processing >phases. > >My own preference would be to add another header like >"AS2-TransactionTypeIdentifier" and let it be specified to meet the >requirements you are formulating. Unless there is something about the >sender side filename that I am just missing, I don't see how it _must_ >be able to help the receiver to decide what the next processing step is. >It _might_ help, but not unless filenames were used with the same >systematic care as TransactionTypeIdenfier values. (Some obvious >candidates for these Transaction values from the EDI world would be 850, >ORDERS, and so forth). >(Would those transaction type values work for the problem you are >conderned with, by the way?) > > >3. If we required a filename, what about deployments where data is not > >obtained from a file system, but from a stream, pipe, queue, or >database > >blob? > >I think it should be a "should" and a "must". --Dmitry > >Dale> Not certain I get your meaning here. Do you mean "should" and not >a "must"? If it's a "must to implement," "should implement" follows >directly. > >=========== > >Am I getting close to identifying the requirements you are interested in >or are you still thinking that "filename" values are exactly what is >needed? "Tumbleweed E-mail Firewall " made the following annotations on 04/08/05 14:20:40 ------------------------------------------------------------------------------ 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. ============================================================================== From loppard@yebox.com Sun Apr 10 03:31:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29527; Sun, 10 Apr 2005 03:31:22 -0400 (EDT) Received: from [222.113.98.82] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKX3p-0007K2-FA; Sun, 10 Apr 2005 03:40:50 -0400 X-Apparently-To: ediint-archive@ietf.org X-Sieve: CMU Sieve 2.2 Received: from caught.sperry.pochta.ru ([unix socket]) by eeoc.bit.pochta.ru (Cyrus v2.2.5) with LMTPA; Sun, 10 Apr 2005 10:21:36 +0200 Date: Sun, 10 Apr 2005 11:26:36 +0300 From: "Genaro Fry" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: ediint-archive@ietf.org Cc: edu-discuss@ietf.org, edu-discuss-admin@ietf.org, edu-discuss-web-archive@ietf.org, edu-team@ietf.org Subject: Lowest rate approval X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 20.7 (++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.3-m-n.net/sign.asp Best Regards, Noemi Fink to be remov(ed: http://www.3-m-n.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From francisc@abacom.com Mon Apr 11 07:23:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03041 for ; Mon, 11 Apr 2005 07:23:35 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKxAH-0004an-Dm for ediint-archive@ietf.org; Mon, 11 Apr 2005 07:33:19 -0400 Received: from [24.178.102.12] (helo=24.178.102.12) by mx2.foretec.com with smtp (Exim 4.24) id 1DKx0t-0007wA-K0 for ediint-archive@ietf.org; Mon, 11 Apr 2005 07:23:32 -0400 Message-ID: From: "Vanessa J. Smith" To: ediint-archive@ietf.org Subject: =?iso-8859-1?B?QWxsIHNvZnR3YXJlIC0gd2hvbGVzYWxlIHByaWNl?= Date: Mon, 11 Apr 2005 11:11:32 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_E226C07C.783E09DD" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.4 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0000_E226C07C.783E09DD Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_E56CD99E.B5D98D5C" ------=_NextPart_001_0001_E56CD99E.B5D98D5C Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Get access to all the popular software possible for unbelievably low prices! We sell software 2-6 times cheaper than retail price. A few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 Quark Xpress 6 Passport Multilanguage Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... Go visit us at: http://www.bestcds.su Best regards, Vanessa Smith _____________________________________________________ To change your mail preferences, go here: http://www.bestcds.su/uns.htm _____________________________________________________ ------=_NextPart_001_0001_E56CD99E.B5D98D5C Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Access all the software possible for wholesale prices!
Our software is 2-10 times cheaper than sold by our competitors.

A few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 MS Project 2003 Professional

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And lots more... Please visit us at:

http://www.bestcds.su

Sincerely,
Vanessa J. Smith


_____________________________________________________
To be taken out, go here: http://www.bestcds.su/uns.htm
_____________________________________________________

------=_NextPart_001_0001_E56CD99E.B5D98D5C-- ------=_NextPart_000_0000_E226C07C.783E09DD-- From bratu@mailAccount.com Tue Apr 12 18:51:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21002; Tue, 12 Apr 2005 18:51:42 -0400 (EDT) Received: from [222.105.43.170] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLUO7-0002ua-6x; Tue, 12 Apr 2005 19:01:45 -0400 Delivered-To: pratt@synchrotron.dreamhost.com Received: from bituminous.dreamhost.com by scotland.dreamhost.com (Pingofix) with ESMTP id 1CC9A29D8B for ; Tue, 12 Apr 2005 20:51:43 -0300 Message-ID: Date: Wed, 13 Apr 2005 00:52:43 +0100 From: "Ophelia Owens" To: Subject: Rates fixed X-Mailer: Mailman v2.0.2 X-SpamTest-Info: Profile: Formal (167/041159) X-SpamTest-Info: Profile: Detect Hard No RBL (4/030508) X-Spam-Score: 13.0 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.mrg-now-yes.com/sign.asp Best Regards, Susana Velez to be remov(ed: http://www.mrg-now-yes.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From deadeye@yebox.com Thu Apr 14 14:50:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11579; Thu, 14 Apr 2005 14:50:20 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM9Zz-0004PA-N8; Thu, 14 Apr 2005 15:00:45 -0400 Received: from [82.226.207.95] (helo=lec67-2-82-226-207-95.fbx.proxad.net) by mx2.foretec.com with smtp (Exim 4.24) id 1DM9Pu-00005R-In; Thu, 14 Apr 2005 14:50:19 -0400 X-Apparently-To: drafts@ietf.org X-Sieve: CMU Sieve 2.2 Received: from dodecahedral.balinese.pochta.ru ([unix socket]) by canvasback.coates.pochta.ru (Cyrus v2.2.1) with LMTPA; Thu, 14 Apr 2005 18:47:08 -0100 Date: Thu, 14 Apr 2005 17:45:08 -0200 From: "Rodney Barajas" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: drafts@ietf.org Cc: drums-archive@ietf.org, dvsqhmanet@ietf.org, dxnvmrouting-discussion-admin@ietf.org, e@ietf.org, e3@ietf.org, eamoby@ietf.org, eap-archive@ietf.org, eb-archive@ietf.org, eccmtmagma-admin@ietf.org, ediint-archive@ietf.org, edu-discuss@ietf.org Subject: Become a homeowner with low rates X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.mrg-now-yes.com/sign.asp Best Regards, Sheldon Day to be remov(ed: http://www.mrg-now-yes.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From uwirjo@doramail.com Fri Apr 15 07:28:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18642; Fri, 15 Apr 2005 07:28:15 -0400 (EDT) Received: from [220.121.5.133] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMP9p-0001N9-LF; Fri, 15 Apr 2005 07:38:47 -0400 Delivered-To: maledict@schoolteacher.dreamhost.com Received: from burma.dreamhost.com by crete.dreamhost.com (Pingofix) with ESMTP id 7CC6A28D1B for ; Fri, 15 Apr 2005 11:23:08 -0100 Message-ID: Date: Fri, 15 Apr 2005 13:23:08 +0100 From: "Ty Kirk" To: Subject: Instant low rates X-Mailer: Mailman v2.0.7 X-SpamTest-Info: Profile: Formal (167/041134) X-SpamTest-Info: Profile: Detect Hard No RBL (4/030542) X-Spam-Score: 7.0 (+++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.n0wwewillsave.com/sign.asp Best Regards, Janice Humphrey to be remov(ed: http://www.n0wwewillsave.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From sposh@doneasy.com Fri Apr 15 14:12:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27895; Fri, 15 Apr 2005 14:12:31 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMVT4-0004KU-BW; Fri, 15 Apr 2005 14:23:07 -0400 Received: from 219.10.97-84.rev.gaoland.net ([84.97.10.219]) by mx2.foretec.com with smtp (Exim 4.24) id 1DMUZL-0000HS-AB; Fri, 15 Apr 2005 13:25:27 -0400 Received: from northeastern.absence-aging.com (HELO diatonic.com 66.6.149.23) by poole.com with EMQP; Fri, 15 Apr 2005 15:03:04 -0400 Date: Sat, 16 Apr 2005 01:09:04 +0600 From: "Maude Kruse" Message-Id: To: drafts@ietf.org Cc: drums-archive@ietf.org, dvsqhmanet@ietf.org, dxnvmrouting-discussion-admin@ietf.org, e@ietf.org, e3@ietf.org, eamoby@ietf.org, eap-archive@ietf.org, eb-archive@ietf.org, eccmtmagma-admin@ietf.org, ediint-archive@ietf.org, edu-discuss@ietf.org Subject: Need a low mortage rate? X-Mailer: CompuServe 7.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.n0wwewillsave.com/sign.asp Best Regards, Katelyn Robinson to be remov(ed: http://www.n0wwewillsave.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From corbridge@doramail.com Fri Apr 15 17:39:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29007; Fri, 15 Apr 2005 17:39:52 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMYhn-0003Bl-Rw; Fri, 15 Apr 2005 17:50:31 -0400 Received: from [211.213.234.51] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DMYXP-0006G5-Pj; Fri, 15 Apr 2005 17:39:44 -0400 Received: from should-jcoppens.com (EHLO detector.jcoppens.com) by basic.jcoppens.com with SMTP; Sat, 16 Apr 2005 03:33:15 +0500 Date: Fri, 15 Apr 2005 19:34:15 -0300 From: "Ava Tuttle" To: ediint-archive@ietf.org Cc: edu-discuss@ietf.org, edu-discuss-admin@ietf.org, edu-discuss-web-archive@ietf.org, edu-team@ietf.org, edu-team-admin@ietf.org, edu-team-bounces@ietf.org, edu-team-web-archive@ietf.org Subject: Pre-approved Application #WHOAV273 Message-ID: X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [856], SpamtestISP/Release X-Mailer: MIME-tools 5.41 (Entity 5.404) X-Spam-Score: 10.1 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.n0wwewillsave.com/sign.asp Best Regards, Angela Gunter to be remov(ed: http://www.n0wwewillsave.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s.