[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: A simpler approach to bilateral non-repudiation of EDI trans
I request you use the x- for all new things, that are not part of the "standard stuff".
From: Gunther Schadow [SMTP:gunther@xxxxxxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, December 04, 1997 9:15 AM
To: chucks@xxxxxxxxxxxxx; gunther@xxxxxxxxxxxxxxxxxxxxxxxx
Cc: carl@xxxxxxxxx; hl7-mime@xxxxxxxxx; ietf-ediint@xxxxxxx
Subject: Re: A simpler approach to bilateral non-repudiation of EDI trans
> Great! I look forward to reading AS#3, and when it is available
> we'll post it through IETF. I agree with you -- I like option 2 as
> well. It is specific to the job at hand.
option 2 was:
- multipart/related; type="application/edi-response";
- multipart/report; report-type="disposition-notification";
As AS#3 will be an EDIINT draft valid for all EDI protocols, we should
immediately start using the TYPE="APPLICATION/EDI-RESPONSE" to be
defined in that upcoming AS#3 document and not use any intermediary
"X-HL7-RESPONSE", shouldn't we?
However, I discovered a conflict with the official definition of the
MULTIPART/RELATED MIME type. The document RFC 2112 sais:
> 3.1. The Type Parameter
> The type parameter must be specified and its value is the MIME media
> type of the "root" body part. It permits a MIME user agent to
> determine the content-type without reference to the enclosed body
> part. If the value of the type parameter and the root body part's
> content-type differ then the User Agent's behavior is undefined.
the last sentence would mean that our first (or "root") body part
itself should be of content type "application/edi-response" or
otherwhise we step on an "undefined" ground! But this would drive the
use of MULTIPART/RELATED ad absurdum as we would have to define a new
content type anyway. Then it would be cleaner to define a
MULTIPART/EDI-RESPONSE right away! It'll be rather difficult to get a
direction that is 99% sure before December 12? However, it is merely
a question of a name. The following seems 99% sure:
MULTIPART/* (... something with: "EDI-RESPONSE")
1st part: MULTIPART/REPORT
2nd part: APPLICATION/EDI*
The rest of 1% is the Carl Hague's option to define a fourth part
directly in MULTIPART/REPORT.
Any comments please?