From alb@sct.gouv.qc.ca Thu Sep 5 22:07:58 1996 Received: from socrate.riq.qc.ca (socrate.riq.qc.ca [199.84.128.1]) by dkuug.dk (8.6.12/8.6.12) with SMTP id WAA17004 for ; Thu, 5 Sep 1996 22:07:53 +0200 Received: from 506.sct.gouv.qc.ca (riq-44-159.riq.qc.ca) by socrate.riq.qc.ca (5.x/SMI-SVR4) id AA02841; Thu, 5 Sep 1996 16:10:22 -0400 Date: Thu, 5 Sep 1996 16:10:22 -0400 Message-Id: <9609052010.AA02841@socrate.riq.qc.ca> X-Sender: alb@mail.riq.qc.ca X-Mailer: Eudora Light pour Windows Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: "glenn (g.w.) parsons" , /G=Ed/S=Buchinski/PRMD=gc+tbs.cts/@govmt.canada.ca From: "Alain LaBont/e'/" Subject: RE: SGML tags in X.400 or MIME Cc: cac-jtc1-sc18@scc.ca, /G=kent/S=lancaster/PRMD=gc+gta.atg/@govmt.canada.ca 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: Glenn.Parsons@nortel.ca 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