headers
Kyle Meadors | 2 Apr 2005 00:39

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 <at> mail.imc.org [mailto:owner-ietf-ediint <at> mail.imc.org]
On Behalf Of Dmitry Dolinsky
Sent: Thursday, March 24, 2005 8:28 PM
To: ietf-ediint <at> 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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dale Moberg | 2 Apr 2005 01:00

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 <at> mail.imc.org
[mailto:owner-ietf-ediint <at> mail.imc.org] On Behalf Of Kyle Meadors
Sent: Friday, April 01, 2005 3:39 PM
To: 'Dmitry Dolinsky'; ietf-ediint <at> imc.org
Subject: RE: Filename in AS2 messages
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dmitry Dolinsky | 4 Apr 2005 18:56

RE: Filename in AS2 messages


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 <at> mail.imc.org [mailto:owner-ietf-ediint <at> mail.imc.org]
>On Behalf Of Dmitry Dolinsky
>Sent: Thursday, March 24, 2005 8:28 PM
>To: ietf-ediint <at> imc.org
>Subject: Filename in AS2 messages
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brent Haines | 4 Apr 2005 19:56

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 <at> mail.imc.org
[mailto:owner-ietf-ediint <at> mail.imc.org] On Behalf Of Dale Moberg
Sent: Friday, April 01, 2005 3:01 PM
To: Kyle Meadors; Dmitry Dolinsky; ietf-ediint <at> 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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Shan Harter | 4 Apr 2005 20:59

RE: Filename in AS2 messages


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> <at> <DOMAIN><ORIGINALFILENAME>

1835122349.20050210084222_000 <at> dev36.com.814_03_STK10.edi.pgp

Other implementations took this approach

<DUNS><TS>_<SEQ> <at> domain

My recommendation is that file name control be managed by the system
receiving with reverences to the received filename.

Regards,
Shan
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dmitry Dolinsky | 6 Apr 2005 21:42

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
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Shan Harter | 6 Apr 2005 21:49

RE: Filename in AS2 messages


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 <at> tumbleweed.com] 
Sent: Wednesday, April 06, 2005 12:42 PM
To: shan.harter <at> systrends.com; 'Brent Haines'; 'Dale Moberg'; 'Kyle
Meadors'; ietf-ediint <at> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dale Moberg | 6 Apr 2005 23:57

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 <at> tumbleweed.com] 
Sent: Wednesday, April 06, 2005 12:42 PM
To: shan.harter <at> systrends.com; 'Brent Haines'; Dale Moberg; 'Kyle
Meadors'; ietf-ediint <at> imc.org
Subject: RE: Filename in AS2 messages
(Continue reading)

Permalink | Reply | 1 comment |
headers
Shan Harter | 7 Apr 2005 23:13

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 8 Apr 2005 16:23
Picon
Favicon

I-D ACTION:draft-ietf-ediint-as3-03.txt

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 <at> 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,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane