std-unix@ut-sally.UUCP (Moderator, John Quarterman) (01/18/87)
From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore) Date: Sun, 11 Jan 87 02:51:14 PST > From: gwyn@brl.arpa (Douglas A. Gwyn) > >From: hoptoad!gnu@lll-crg.arpa (John Gilmore) > >... Is it going to be possible to sell a > >POSIX system without UUCP? Ditto for "mail"... > > I don't see why these should be mandated when many sites use > superior facilities in their place. Ditto for the spooler. There are several points here, and I didn't make things very clear. (1) A Posix system should be able to talk *over the phone* with a Unix UUCP site. Why should a Posix user be reduced to public domain kermits and things for communication, when we all know we are standardizing Unix, and uucp comes with every Unix ever released by AT&T or Berserkeley? (2) Applications should be able to use a standard interface to send mail. It should always be possible for a shell script or program to invoke "/bin/mail" with an addressee as argument and a message on standard input. No matter what the protocol used to move or read the mail. SysV and Sun do this right; BSD Unix messes it up a bit with the Apparently-To: headers, producing mail that violates RFC822 if you invoke it this way. But it works well enough everywhere; make it standard. (3) The same is true of a spooler. You can provide a fancy spooler, but please let dumb programs invoke it by the same old name as long as they only depend on the dumb options, e.g. "lpr" and "lpr -p". (4) This would be useful for file transfers too, but there is no clear standard (uucp, kermit, ftp, rcp, tftp, plus whatever comes with 3Bnet) and the different methods disagree on whether it happens immediately or is queued, whether return status is available, whether you have to specify text, binary or other file attributes, etc. If we require that Posix talk over the phone to uucp, we might as well require that the uucp command syntax be usable to invoke those transfers. > From: gwyn@brl.arpa (Douglas A. Gwyn) > The standard should not be weakened unduly to permit existing > inadequate facilities to be advertised as already conforming! This last statement is indicative of a severe miscommunication somewhere. I thought we were standardizing *UNIX*. U. N. I. X. Not somebody's great idea of what Unix should be after you fix the "inadequate facilities", but what it already is. Right now the de facto standard, that is, what commercial applications or mod.sources postings can reasonably assume, is roughly V7 with a few mods (the Berkeley directory access library, for example). Why should we write up a document that claims differently and call it a standard? The point is to limit the variation. We have failed if we create yet another variant that's not a subset of most of the existing ones. I'm not interested in old vendors' being able to advertise their systems as "already conforming". (I'm working on the GNU project which will write it all from scratch anyway.) What I *am* interested in is portability of applications. Talked to Mike Gallaher about Unix portability? He's been porting Emacs to Gosling knows how many systems. Talked to RMS, or the Alis or Ingres or Common Lisp or AutoCad people? What does mdqs depend upon? What do they need to be able to depend upon? If today's version of netnews would not run unchanged on Posix, as it runs unchanged on dozens of variants of Unix, I say Posix is not meeting its goals. (I don't know whether it would run under Posix, or not.) :-) I can see it now, it will take Guy Harris another 2 years to produce "the amazing Veg-a-Sun-Unix, it slices, it dices, it splits hairs, it runs BSD and SYSV and if you order today you'll even get the terrific unified separate but equal Posix variation compatability library!" :-) NO thanks... Volume-Number: Volume 9, Number 19
std-unix@ut-sally.UUCP (01/28/87)
From: seismo!nyu-acf4.arpa!cmcl2!tihor (Stephen Tihor)
Date: Sat, 17 Jan 87 22:45:31 est
What several people seem to be missing in the discussion about including
UUCP in POSIX is that (drum roll) IT IS NOT POSSIBLE TO STANDARDIZE AN
UNDOCUMENT PROTOCOL (..actually standardize de jure..). Everything else
in the POSIX spec is being reasonably specified or left out. When the
command syntax of UUCP could be standardized that would be about as useful
as standardizing a tar/cpio program without specifing the format in
which a tape of pure 7-bit ASCII text files is written.
Sure we all know that most vendors will pay AT&T (or maybe Lauren) for the
specification to UUCP so that it can run on their POSIX compatible system
but I didn't think the IEEE has sunk to the level of stanrardizing the
external appearance of tool without adequately specifying what it does.
Someone might argue that it doesn't matter how you move data from place to
place UUCP is just the syntax that a POSIX user employs to initiate a
file transfer and a complying implementation can use FTP or NFS and CP
or whatever to move the data. This means that it will not be possible
to assume that two POSIX compliant systems can exchange data using modems
and wires. Ughh!!! {UUCP as a link to RCP bouble UGH!!}
Either include the low level UUCP<->UUCP communications specs for as many
protocols as possible so someone can build a UUCP from scratch or don't
include. The LAW of LEAST SUPRISES argues greatly against having the name
not mean at least roughly the same thing. (After all POSIX is supposed
to bring the family closer together not drive it farther apart.)
Volume-Number: Volume 9, Number 23std-unix@ut-sally.UUCP (01/28/87)
From: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) Date: Tue, 20 Jan 87 4:59:34 EST Organization: Ballistic Research Lab (BRL), APG, MD. In article <6881@ut-sally.UUCP> std-unix@ut-sally.UUCP: >(2) Applications should be able to use a standard interface to send >mail. >(3) The same is true of a spooler. You can provide a fancy spooler, >but please let dumb programs invoke it by the same old name as long as >they only depend on the dumb options, e.g. "lpr" and "lpr -p". I am in full agreement that a SUBSET of "mail" and "lp" (or "lpr") interfaces should be standardized, just not the whole package (for instance, definitely NOT the interactive mail-reading interface). My command-set proposal to 1003.2 contained several such cases of limited subsets of what was in the SVID. I view 1003.2 primarily as a collections of tools for use by application programs, not as things a naive user would confront directly. >We have failed if we create yet another >variant that's not a subset of most of the existing ones. There is little value in restricting the 1003 standards to lowest- common denominator subsets of existing UNIX implementations, since many interesting and useful applications simply cannot be written to work well within such a limited subset. Consequently, the 1003.1 trial-use standard already differs in several (relatively minor, we hope) ways from existing UNIX systems. POSIX conformance will require a certain amount of change to existing systems. We've been working fairly closely with AT&T SVID people on this issue, in an attempt to ensure that a system can be simultaneously SVID and POSIX compliant without requiring separate "universes" (libraries, etc.). As one of the original separate-universe implementors, I wish to state that any such implementation should be viewed as an interim measure while we attempt to converge on a single universal standard. (I believe this is what Sun is attempting to do.) It will sure be nice to be able to quit worrying about annoying trivial system variations and get to work on better applications. Volume-Number: Volume 9, Number 27
std-unix@ut-sally.UUCP (01/28/87)
From: seismo!mcnc.org!ecsvax!bet (Bennett Todd) Date: Mon, 19 Jan 87 14:26:45 est Organization: Duke User Services >From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore) > >> From: gwyn@brl.arpa (Douglas A. Gwyn) >> >From: hoptoad!gnu@lll-crg.arpa (John Gilmore) >> >... Is it going to be possible to sell a >> >POSIX system without UUCP? Ditto for "mail"... >> >> I don't see why these should be mandated when many sites use >> superior facilities in their place. Ditto for the spooler. >... >(1) A Posix system should be able to talk *over the phone* with a Unix >UUCP site. Why should a Posix user be reduced to public domain kermits and >things for communication, when we all know we are standardizing Unix, and >uucp comes with every Unix ever released by AT&T or Berserkeley? Because UUCP is distinctive among UNIX applications in having "secrets" buried inside it. To be a UUCP a utility should, at a minimum, be able to communicate successfully with at least some large proportion of all existing implementations; unfortunately, the protocol isn't documented for potential implementors. The only reasonable way to get the protocol is to read the source code; this makes your resulting implementation a derivative work and therefore AT&T proprietary. It is *not* appropriate to produce a standard mandating something which is strictly AT&T proprietary. Actually, I have heard of one (1) instance of a UUCP being written and not beholden to AT&T. However, with substantially less effort than is required to work from a line trace up and reverse engineer the protocol, you can produce a complete replacement that works far better in several important respects (e.g. built-in quoting to enable transparent transmission through 7-bit communication channels, support for various flow control mechanisms including the terrible XON/XOFF, ability to work efficiently in the face of long round-trip packet delays and/or half duplex, logon dialog specification far more flexible than "expect-send strings", and so forth). If you want the ability to intercommunicate with arbitrary other UNIX systems, write a host end portably. Let's not go out of our way to put roadblocks in the way of competition; AT&T already isn't the only source for substantially UNIX-like operating systems; they aren't the only ones who could make available a POSIX compatible operating system, if gratuitous obstructions like UUCP (with its undocumented protocol) are avoided. -Bennett -- Bennett Todd -- Duke Computation Center, Durham, NC 27706-7756; (919) 684-3695 UUCP: ...{decvax,seismo,philabs,ihnp4,akgua}!mcnc!ecsvax!duccpc!bet BITNET: DBTODD@TUCC.BITNET -or- DBTODD@TUCCVM.BITNET -or- bet@ECSVAX.BITNET terrorist, cryptography, DES, drugs, cipher, secret, decode, NSA, CIA, NRO. Volume-Number: Volume 9, Number 28
std-unix@ut-sally.UUCP (01/28/87)
From: hadron!jsdy@seismo.css.gov (Joseph S. D. Yao) Date: 26 Jan 87 14:36:44 GMT Organization: Hadron, Inc., Fairfax, VA In article <6881@ut-sally.UUCP> hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore) writes: >There are several points here, and I didn't make things very clear. >> From: gwyn@brl.arpa (Douglas A. Gwyn) >> The standard should not be weakened unduly to permit existing >> inadequate facilities to be advertised as already conforming! >This last statement is indicative of a severe miscommunication >somewhere. I thought we were standardizing *UNIX*. U. N. I. X. Yes, is miscommunication. (tm)UNIX is a trademark of Bell Labs, and now a Registered Trademark of AT&T. Only those folk have the right to standardise it. And they have: "System V (ex-III): consider it The Standard." They issued the SVID (System V Interface Desciption). And then re-wrote it: twice, so far. POSIX, P1003.2, is a Standard for An Operating System Interface. Note that it's called POSIX, and not that registered trademark. Yes, it looks a lot like our favourite OS that's better than any other OS out there (yet). No coincidence. But it doesn't have to look exactly like any existing version. However, the quote above referred specifically to the Shell! Not to the OS, but to the user interface. BTW, I rather agree that such things as UUCP, mail, et al. should be mentioned in the standard at least by reference or in an appendix as minimal interfaces. But room should be allowed to make these replacable by updated facilities, and perhaps even to be made an optional package. -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} jsdy@hadron.COM (not yet domainised) Volume-Number: Volume 9, Number 29
std-unix@ut-sally.UUCP (02/03/87)
Hey, has anyone ever asked the nice folks at AT&T whether they'd be willing
to publish specs for UUCP's protocol? It seems likely that they just might
do it, at least for the 'g' and 'f' protocols. If they are really serious
about wanting us to consider Sys/V "the Standard", it seems that it would be
in their interests to make it in fact the standard. Maybe they would even
be willing to let the IEEE (1003.7?) publish the specs.
It seems like it oughta be worth at least an inquiry or three.
--
John M Chambers Phone: 617/364-2000x7304
Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp}
Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193
Volume-Number: Volume 9, Number 50