RE: Filename in AS2 messages

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=
<TO_DUNS>.<TIMESTAMP><SEQ>@<DOMAIN>.<ext>

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:[email protected]] 
Sent: Wednesday, April 06, 2005 2:58 PM
To: Dmitry Dolinsky; [email protected]; Brent Haines; Kyle
Meadors; [email protected]
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:[email protected]] 
Sent: Wednesday, April 06, 2005 12:42 PM
To: [email protected]; 'Brent Haines'; Dale Moberg; 'Kyle
Meadors'; [email protected]
Subject: RE: Filename in AS2 messages

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

just by referencing another standard).

Shan,

Is the standard you are referring to available for review?

--Dmitry

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


>In other markets we have deployed systems that "take control" of the 
>filename, for example. The reason is that in that market there is a
need
>to track and trace a file and correspond back to its transactions
within
>and all the way back to the original inbound filename. The file name 
>inbound is simply recorded and new intelligent naming is created
inbound
>and tracked all the way back to the transactional level. Then reports 
>could be generated that not only referenced the trading partner's file 
>name but also time stamps, and other attributes such as size, etc. This

>information was kept and later reported to the trading partner as a 
>reference yet still allowing the receiving company to manage the naming

>of over 300 trading partners. This is important when the file name
comes
>in as just .payload or edi. There are a lot of applications that send 
>the same name.
>
>
>A standard was created that did this
>
><TO_DUNS>.<TIMESTAMP><SEQ>@<DOMAIN><ORIGINALFILENAME>
>
>[email protected]_03_STK10.edi.pgp
>
>Other implementations took this approach
>
><DUNS><TS>_<SEQ>@domain
>
>My recommendation is that file name control be managed by the system 
>receiving with reverences to the received filename.
>
>Regards,
>Shan
>
>Shan Harter
>Project Services
>Systrends, Inc.
>7855 South River Parkway
>Tempe Arizona, 85284
>ph:  480-756-6777 Ext 205,
>fax: 480-756-9755, cell: 602-821-2951
>
>
>
>-----Original Message-----
>From: [email protected] 
>[mailto:[email protected]] On Behalf Of Brent Haines
>Sent: Monday, April 04, 2005 10:56 AM
>To: Dale Moberg; Kyle Meadors; Dmitry Dolinsky; [email protected]
>Subject: RE: Filename in AS2 messages
>
>
>
>Filename preservation isn't necessary. That implies that I can name a 
>file that will appear on your system with that filename.
>
>What we are getting from several users is a requirement to have the 
>original filename in some standard header in the message such as the 
>Content-Disposition Header. We can implement that for our products, but

>it seems like the kind of thing that should be part of the standard.
>
>I can see no real security issues with this and no changes to how the 
>standard works other than to allow trading partners to track the 
>filename through the transaction.
>
>-Brent Haines
>  Tumbleweed Communications
>
>-----Original Message-----
>From: [email protected] 
>[mailto:[email protected]] On Behalf Of Dale Moberg
>Sent: Friday, April 01, 2005 3:01 PM
>To: Kyle Meadors; Dmitry Dolinsky; [email protected]
>Subject: RE: Filename in AS2 messages
>
>
>Applications can make use of Content-Disposition Header and not violate

>AS1,2 (and I think 3) but this is not specifically and explicitly 
>mentioned in the applicability statements. It is certainly not mandated

>behavior and implementations should not depend on the behavior to 
>interoperate.
>
>Historically, there were security concerns about threats/exploits when 
>not checking filenames (and especially filenames with a full path).
Kyle
>also points out that there are not overwhelmingly convincing use cases 
>for letting/requiring the partner saying what the filename should be on

>the system. Early experience back in the late 90s with AS1 showed that 
>implementations were not always good about using unique filenames; so 
>operational problems of clobbering data could show up for incautious 
>implementations. The safest bet when implementing was to have the 
>receiver ensure no-clobbering, and an easy way to do that was to just 
>ignore the suggested filenames.
>
>I am unconvinced we should open this up again without clear and 
>persuasive end-user requirements for why this functionality is needed.
>
>Dale Moberg
>
>
>-----Original Message-----
>From: [email protected] 
>[mailto:[email protected]] On Behalf Of Kyle Meadors
>Sent: Friday, April 01, 2005 3:39 PM
>To: 'Dmitry Dolinsky'; [email protected]
>Subject: RE: Filename in AS2 messages
>
>
>Dmitry,
>
>Generally, I did not consider filenames of EDI/XML payloads to be 
>significant in themselves. The information in the EDI interchanges is 
>not treated differently because of the filename. What would be the 
>benefit of your trading partner knowing the filename?
>
>Kyle Meadors
>DGI
>
>-----Original Message-----
>From: [email protected] 
>[mailto:[email protected]]
>On Behalf Of Dmitry Dolinsky
>Sent: Thursday, March 24, 2005 8:28 PM
>To: [email protected]
>Subject: Filename in AS2 messages
>
>
>I'd like to clarify how the filenames are expected to be communicated
in
>
>AS2. Since AS2 data is represented by MIME body, the implication is
that
>
>Content-Disposition header can be used for that purpose.
>
>Is this a correct assumption?
>
>If so, it would be great if AS2 spec made an explicit reference to 
>RFC-2183 (update of rfc1806) "Communicating Presentation Information in

>Internet
>Messages: The Content-Disposition Header Field"  with respect to AS2 
>filename. I've noticed that the header is included in the samples that 
>accompany the specification but making it explicit would improve 
>interoperability.
>
>Also, as a practical question, do current AS2 implementation include 
>Content-Disposition header with filename parameter when sending and
look
>
>for it when receiving as far as people know?
>
>Thank you.
>
>Dmitry Dolinsky
>Tumbleweed Communications Corp.
>
>
>"Tumbleweed E-mail Firewall <tumbleweed.com>" made the following 
>annotations on 03/24/05 18:34:12
>-----------------------------------------------------------------------
-
>----
>--
>This e-mail, including attachments, may include confidential and/or 
>proprietary information, and may be used only by the person or entity
to
>which it is addressed.  If the reader of this e-mail is not the
intended
>recipient or his or her authorized agent, the reader is hereby notified

>that any dissemination, distribution or copying of this e-mail is 
>prohibited. If you have received this e-mail in error, please notify
the
>sender by replying to this message and delete this e-mail immediately. 
>=======================================================================
=
>====
>==
>
>
>--
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.308 / Virus Database: 266.7.4 - Release Date: 3/18/2005
>
>
>--
>No virus found in this outgoing message.
>Checked by AVG Anti-Virus.
>Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 3/30/2005
>
>
>
>
>
>"Tumbleweed E-mail Firewall <tumbleweed.com>" made the following 
>annotations on 04/04/05 11:01:26
>-----------------------------------------------------------------------
-
>------
>This e-mail, including attachments, may include confidential and/or 
>proprietary information, and may be used only by the person or entity
to
>which it is addressed.  If the reader of this e-mail is not the
intended
>recipient or his or her authorized agent, the reader is hereby notified

>that any dissemination, distribution or copying of this e-mail is 
>prohibited. If you have received this e-mail in error, please notify
the
>sender by replying to this message and delete this e-mail immediately. 
>=======================================================================
=
>======
>
>
>
>CONFIDENTIALITY NOTE:
>This message and any of the attached documents contain privileged and 
>confidential information only for the use of the individual or entity 
>that was the intended recipient.  If you are not the  intended
recipient
>you may not read, copy, distribute, retain or use this information. If 
>you have received this message and any of the attached documents in 
>error, please immediately notify the sender by reply e-mail and then 
>delete this message.  Thank you.


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


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.