Reply to Proposed change to HARPOON

["Kevin E. Jordan" <[e-mail]>]

> Because I know you, and because of your insistent (and consistent)
> arguments, I am prepared to take the (good traditional IETF way) practical
> approach and accept Haralds " do both" proposal. I still want to add to this
> however that I feel we are forced by the "practical/sheer number of PCs"
> arguments into accepting a solution which in my view is from an X.400
> architectural point of view (does such a thing exist for X.400 :-) very
> unclean.

Let's be very practical about the consequences of doing both.  Doing both
properly requires sending hosts to know a priori the preferred format
of all possible destination hosts.  This is not currently possible.  Therefore,
a default format must be defined, and if we accept Ned's arguments, the
only reasonable default would be to use IA5-Text body parts for exchanging
MIME data.  Since IA5-Text should always work under this model, and since
maintaining bilateral agreements for using BilaterallyDefined will be extra
work for administrators, what incentive will they have to use
BilaterallyDefined?  Obviously, they will have no incentive.  Nor will
implementors have any incentive to support the BilaterallyDefined variant for
MIME.

Also note that the IA5-Text variant is in use and works today.  Both RFC's
987 and 1327 explicitly define mechanisms for preserving headings which
do not map onto X.400 service elements directly.  Any X.400 gateway which
conforms to either of these RFC's preserves the MIME headings today.  In
RFC987, the initial IA5-Text body part headed by "RFC-822-Headers:" is used
for this purpose.  RFC1327 employs the '88 X.400 header extension features.
In either case, a correctly implemented gateway will preserve all MIME
information.

I have actually tested this against two independent RFC987 gateway
implementations which are available to me, and it works as specified.
MIME messages originating in an RFC822 UA, destined for an RFC822 UA, and
traversing an intermediate X.400 network are mapped into and out of X.400
without destroying any MIME information.  Also, MIME messages originating in
an RFC822 UA and destined for an X.400 UA arrive at the X.400 mailbox with
the RFC987-prescribed initial IA5-Text body part containing the initial
MIME headers.  Subsequent IA5-Text body part(s) contain the individual MIME
parts with their individual headings intact.

The conclusion to draw is that if we accept Ned's arguments, then I would
argue that allowing the BilaterallyDefined versus IA5-Text choice adds
complexity which will not be used in most real-world situations.  There will
simply be no incentive for administrators or implementors to support the
BilaterallyDefined variant.  Therefore, there is no point in defining the
BilaterallyDefined variant.

Furthermore, since the IA5-Text variant is already fully supported by
RFC's 987 and 1327, and it works today, defining it again (or worse,
differently) in the HARPOON specification would be at best redundant and at
worst conflicting.  So, if we accept Ned's arguments, I see no justification
for the existance of the HARPOON document.