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?
|
