Subject: RE: SGML tags in X.400 or MIME

From: "Alain LaBont/e'/" <[email-masked]>
Date: Thu, 5 Sep 1996 16:10:22 -0400

At 14:32 05/09/1996 -0400, glenn (g.w.) parsons wrote:
>In message "RE: SC18 Meeting 1996.A.5 Membership Status", 
>Ed Buchinski writes:
>
>>     For a matter closer to the SC18 agenda, I would like to draw attention 
>>to the issue that I raised with Glenn Parsons during the past few months. 
>> As mentioned in another message, the issue was the best means of 
>>identifying SGML-encoded forms as attachments in e-mail messages.   If I 
>>recall correctly from the various messages that were exchanged with Glenn 
>>and the e-form pilot participants, the X.400 option was to extend the 
>>"body-part" values.  The process could begin with the upcoming SC18/WG4 
>>meeting in Ottawa in October.  I was contemplating what might need to be 
>>done to get this item progressed.
>
>I seem to recall some earlier request for a SGML body part for X.400, 
>but I'm not sure what happened to it.  I could check this out for you if
>you'd like...  This may be worthwhile, as it would probably be beneficial
>to have a base SGML bodypart.
>
>As for the OIDs that I was suggesting earlier -- X.400 allows for the use
>of either billaterally (between two parties), nationally (in one country)
>and extended (OID) defined bodyparts.  Of these, the latter is the most
>robust and would allow you to tag each bodypart with a number that uniquely
>identifies it.
>
>The EMA has defined a mechanism using the File Transfer Body Part (FTBP)
>version of the extended BP to allow the seemless transmission of files.
>Many vendors (e.g. Lotus, WP, Microsoft) have listed their OIDs for their
>favourite files with the EMA.  This might be a useful path.
>
>Note that I am only speculating, since I do not know your issues.
>
>>     However, the draft report from the consultant suggests that we use 
>>MIME-types instead and work through the IEFT do get any added extensions! 
>
>As most consultants would these days...as short sighted as it may seem.
>
>> The reasons for doing so are practical considerations.  Internet messaging 
>>is affordable, X.400 isn't.  Not ISO's fault.  Internet "standards" can be 
>>updated more expeditiously.  The Internet option is easier to implement and 
>>provides a larger marketplace.  Yes, the implementations aren't as robust.
>
>I would suggest that it is important to look at the market for your pilot.
>If it is indeed the government, then I would suggest that registering
>values for both X.400 and SMTP/MIME is important (and not just the latter).
>I would agree that SMTP implementations are not perceived to be robust
>and that in most mission critical applications (e.g. banking, finance,
>oil, pharmaceuticals, etc.) X.400 is used as the transport.  Of course,
>most of the hype you hear is about making SMTP/MIME (aka Internet mail)
>more secure to be viable in these mission critical apps!
>
>Another possible path is to simply register MIME types (note that
>text/SGML and application/SGML are already defined in the experimental
>RFC 1874) and also note that they are for use in X.400.  The MIXER series
>specifies how MIME types can be transfered (e.g. text/plain to ia5) or
>tunnelled (using EMA's FTBP mechanism).  This may also be a worthwhile
>approach to take.
>
>Let me know if you have any questions.
>
>It would likely be worthwhile for you to attend the WG4 meeting in
>Ottawa next month to discuss the finer details with the X.400
>experts present.  If you'd like I could try to arrange having
>SGML bodyparts put on the agenda (a contribution which at the minimum
>need only state a problem, would be ensure its discussion).
>
>Cheers,
>Glenn.
>
>-----------------------------------------------------------------
>Glenn Parsons                     Multimedia & Security Standards
>                                  Nortel Technology 
>Phone: +1-613-763-7582            Ottawa, Ontario, CANADA
>G3fax: +1-613-763-8385
>X.400: G=Glenn; S=Parsons; P=Nortel; A=Telecom.Canada; C=CA
>Internet: [email-masked]

Let me make another comment. As long as X400 will not be 8-bit-enabled by
default, it will be for us, French-speakers, less robust than the Internet.

I do not count the horror stories in which urgent messages get back to me
after days with an error notice saying that I have a bad parameter in my
headers, just because there is an accented character (by inadvertence, I
forget not to write my name correctly sometimes) in the *body* of the
message. Indeed it requires a parameter to do so... We discovered that here,
but with a British Telecom expert, a while ago, the guy could not discover
what was wrong in our parameters, which were all right. We were using the
IMMEDIA gateway at that time, which we replaced by direct Internet PPP link,
with an immediate cost reduction of 1000%.

Furthermore, most platforms do not accept the French parameters (ex: NOM)
nor French characters in headers mandated by X400 conformance, nor all
parameters at all.

Even more, there has been cases where, because of bad parameters, messages
have looped infinitely between Montréal, Bruxelles and Genève, that without
any notification to the sender nor to the recipient (this case has been
experienced by ALIS Technmologies in Montréal). Error tolerance is not part
of X400 design, does it seem.

So I am sorry to say that the robustness of X400 is to us in practice but
vapourware.

I only saw to this day one conformant X400 site and it was in Genève, a
correspondent of one of my colleagues.

That said, X400 concepts are really excellent and are being progressively
implemented under the Internet, in a less pretentious but more efficient,
and more error-tolerant manner.

If I err in facts in what I said, I will be glad to retract myself, and I
would be glad if I were proven wrong in practice with actual examples. All
those who tried to this day have failed to demonstrate this.

Alain LaBonté
Québec