RE: Filename in AS2 messages

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 <tumbleweed.com>" 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.
==============================================================================