dml@rabbit1.UUCP (David Langdon) (05/22/87)
We are looking for a public domain version of an X.400 Mail package for
either UNIX or DOS. If none exists, we are still interested in commercially
available implementations. In particular, we are interested in interfacing this
with a SNA PU2.1 gateway and DIA/DISSOS application. If PD or commercial
versions are known to you, please email information to me (unless you think
this information is interesting enough to be posted to the NET in general).
Thanx for your help.
--
David Langdon Rabbit Software Corp.
(215) 647-0440 7 Great Valley Parkway East Malvern PA 19355
...!ihnp4!{cbmvax,cuuxb}!hutch!dml ...!psuvax1!burdvax!hutch!dmlmac@idacrd.UUCP (05/26/87)
in article <289@rabbit1.UUCP>, dml@rabbit1.UUCP (David Langdon) says: > Xref: idacrd comp.sources.wanted:1169 comp.dcom.lans:450 comp.mail.misc:306 > > We are looking for a public domain version of an X.400 Mail package for > either UNIX or DOS. If none exists, we are still interested in commercially > available implementations. In particular, we are interested in interfacing this > David Langdon Rabbit Software Corp. > (215) 647-0440 7 Great Valley Parkway East Malvern PA 19355 There was a recent description of an implementation in an interview in UNIX Review. As with all things designed by committee this bohemoth was 1.5 Megawords and the supporter of X.400 that was being interviewed called it "the ADA of mailing systems". Bob
dennis@rlgvax.UUCP (06/09/87)
In article <220@idacrd.UUCP>, mac@idacrd.UUCP (Bob McGwier) writes: > As with all things designed by committee this bohemoth was > 1.5 Megawords and the supporter of X.400 that was being interviewed > called it "the ADA of mailing systems". > > Bob Recently I was tasked to write-up an internal memo that compared X.400 to our electronic mail system that we sell as part of our OA package (OfficePower). Well, the X.400 series (8 of 'em) standards are *very* difficult to read casually. When are those standards writers going to start writing documentation that is isn't so abstract, terse, and hard to understand? Maybe we need a standard for writing standards? :-) -dennis bednar -- FullName: Dennis Bednar UUCP: {seismo|sundc}!rlgvax!dennis USMail: CCI; 11490 Commerce Park Dr.; Reston VA 22091 Telephone: +1 703 648 3300
dmt@mtunb.UUCP (06/10/87)
In article <493@rlgvax.UUCP> dennis@rlgvax.UUCP (Dennis.Bednar) writes: >Recently I was tasked to write-up an internal memo that compared >X.400 to our electronic mail system that we sell as part of our >OA package (OfficePower). Well, the X.400 series (8 of 'em) standards >are *very* difficult to read casually. When are those standards >writers going to start writing documentation that is isn't so abstract, >terse, and hard to understand? Probably never; I'll even defend that's as it should be. The purpose of the standard is unambiguous precision. Bad standards are bad not because their statement is abstract or difficult to read, but because their content is wrong or ambiguous. It seems to be a fact of life (or at least of the state of the art in languages) that precision REQUIRES terse abstract notation. What there REALLY ought to be is a tutorial, readable statement of what the standard says. This tutorial should NOT be confused with the standard itself; where there is a discrepancy, the [unreadable] standard rules. Since standards committees seldom publish such documents, the book industry may be missing a profitable market here. > >Maybe we need a standard for writing standards? :-) If it's a good standard, you'll have trouble reading it, too. :-) +---------------------------------------------------------------+ | Dave Tutelman | | Physical - AT&T - Lincroft, NJ | | Logical - ...ihnp4!mtuxo!mtunb!dmt | | Audible - (201) 576 2442 | +---------------------------------------------------------------+
howard@cos.UUCP (06/12/87)
In article <493@rlgvax.UUCP>, dennis@rlgvax.UUCP (Dennis.Bednar) writes: > > Recently I was tasked to write-up an internal memo that compared > X.400 to our electronic mail system that we sell as part of our > OA package (OfficePower). Well, the X.400 series (8 of 'em) standards > are *very* difficult to read casually. When are those standards > writers going to start writing documentation that is isn't so abstract, > terse, and hard to understand? Unfortunately for a newcomer to standards, there are underlying agendas for them which tend to make them hard to read. Standards are to some extent political and anticipatory, and do not necessarily intend to be directly implementable. The X.400 standards are hard even for experts to read. It is important to realize, however, that there is an intermediate stage between standards and products (at least in OSI): the implementation agreements document, and the functional profile defined for a specific environment. Most implementation agreements are developed by the OSI Implementors' Workshop sponsored by the National Bureau of Standards; specific options to be used, even beyond the NBS agreements, are in profiles such as the Corporation for Open Systems (COS) protocol stack for X.400 or the European SPAG functional profile. There are good tutorial introductions to X.400, such as that of Omnicom. They cost a few hundred dollars and are worth it. Incidentally, X.400 does not replace electronic mail systems, in that it provides an intelligent messaging capability among multiple nodes but does not prescribe the user interface. Your task probably should be to look at X.400 as an _enhancement_ to your own products. Howard howard@cos.com [via hadron, seismo->hadron, usda-ai, sundc] (703) 883-2812
dave@lsuc.UUCP (06/17/87)
In article <959@mtunb.ATT.COM> dmt@mtunb.UUCP (Dave Tutelman) writes: >> When are those standards >>writers going to start writing documentation that is isn't so abstract, >>terse, and hard to understand? > > Probably never; I'll even defend that's as it should be. > The purpose of the standard is unambiguous precision. Dave is correct on this. A standard in the computer industry, once accepted, plays the same role as legislation in society. Much legislation is difficult to read by non-lawyers, a fact which causes some to criticize it. But it's the same issue. I don't expect non-lawyers to be able to read the Canadian Income Tax Act, although millions of people are affected by it. Nor to I expect the computer world at large, outside of the people who implement {compilers, X.400 systems, whatever} to understand such systems from their standards documents. > What there REALLY ought to be is a tutorial, readable statement > of what the standard says. This tutorial should NOT be confused > with the standard itself; where there is a discrepancy, the > [unreadable] standard rules. Absolutely. In the case of complex legislation such as amendments to the Income Tax Act, our Department of Finance publishes an explanation of the amendments in readable English. And, of course, for many areas of the law that affect the public at large there are publications available that explain, in understandable terms, most of what the law says. David Sherman The Law Society of Upper Canada Toronto -- { seismo!mnetor cbosgd!utgpu watmath decvax!utcsri ihnp4!utzoo } !lsuc!dave
daveb@geac.UUCP (Dave Brown) (06/18/87)
In article <1875@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes: >I don't expect non-lawyers to be able to read the Canadian >Income Tax Act, although millions of people are affected by it. > >.... In the case of complex legislation such as >amendments to the Income Tax Act, our Department of Finance >publishes an explanation of the amendments in readable English. Another necessary (but not sufficent) technique comes from the world of the law, too: Preambles. If one is drafting a very-high-level document (ie, one which may be vague or overgeneral) you start with a description of what one means to achieve. Not how the law is supposed to work, but what its supposed to do. Makes it easier to understand right from the beginning, and isn't binding on anyone so that it doen't have to be written in standard-/legal-ese. --dave () brown
sid@rtech.UUCP (06/19/87)
In article <1875@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes: >In article <959@mtunb.ATT.COM> dmt@mtunb.UUCP (Dave Tutelman) writes: >>> When are those standards >>>writers going to start writing documentation that is isn't so abstract, >>>terse, and hard to understand? >> >> Probably never; I'll even defend that's as it should be. >> The purpose of the standard is unambiguous precision. > >Dave is correct on this. A standard in the computer industry, >once accepted, plays the same role as legislation in society. >Much legislation is difficult to read by non-lawyers, a fact which >causes some to criticize it. But it's the same issue. > >I don't expect non-lawyers to be able to read the Canadian >Income Tax Act, although millions of people are affected by it. (Since my question really brings up another subject, I have redirected discussion to a more appropriate new group.) Why is it too much to expect the "common" person to be able to understand laws? He must live under them. Consider the idea that if a law is too complex for him to understand than the law is too complex period and should be simplified. Just a random thought... / Sid /