chrisb@escargot.UUCP (Chris Bradley) (07/15/89)
Greetings: Before I ask my question, I should tell you that I'm writing a BBS that will incorporate UUCP, Fidonet, and its own protocol, which will use xmodem, ymodem, and/or zmodem. I would like to use the existing UUCP startup rather than having to write my own startup for the x, y, and zmodem protocols. The normal UUCP startup looks something like this: \020Pefg\0 <--- List of protocols available \020Ug\0 <--- Use the "g" protocol What I'd like to do is add in "x", "y", and "z", respectively, for X, Y, and Zmodem. Do X, Y, and Z already exist? If not, is it okay to impliment this feature in my bbs so I won't clash with anything else? If it isn't a good idea, what would any of you suggest? I have tried unsuccesfully to get ahold of Peter Honeyman, however it seems as though my messages are getting lost in transit. Any help on this matter would be greatly appreciated. Thanks! -->Chris =============================================================================== | Name : Chris Bradley | Wanna | "I didn't like the Mercury | | UUCP : ...tektronix!escargot!chrisb | talk? | Sable, so I bought a Ford | | Phone: (503) 644-3585 (Home) | Call me! | Taurus instead!" | ===============================================================================
csg@pyramid.pyramid.com (Carl S. Gutekunst) (07/17/89)
In article <256@escargot.UUCP> chrisb@escargot.UUCP (Chris Bradley) writes: >I'm writing a BBS that will incorporate UUCP, Fidonet, and its own protocol, >which will use xmodem, ymodem, and/or zmodem. I would like to use the >existing UUCP startup rather than having to write my own startup for the x, >y, and zmodem protocols. What I'd like to do is add in "x", "y", and "z", >respectively, for X, Y, and Zmodem. Do X, Y, and Z already exist? 'x' (note the lower case) is already taken, for AT&T's X.25. Someone is almost certainly going to add the Zmodem protocol to uucico, which will use 'z'. But no one is claiming upper case 'X', 'Y', and 'Z' at this point. I don't think it would be that difficult to use a higher-level mechanism for protocol selection, though -- something that uses all printable ASCII plus the carriage return, like a signon procedure. Just a thought. >I have tried unsuccesfully to get ahold of Peter Honeyman, however it seems >as though my messages are getting lost in transit. The present "world authorities" on UUCP would be Peter or Rick Adams, plus a gaggle of peripheral hangers-on like Guy Harris, Henry Spencer, and myself. Someone at AT&T has also been hacking on BNU a lot, but has so far had the good sense not to identify themselves. All of us are pretty busy, so if we don't reply to your mail, it's probably because we're ignoring you. :-) <csg>
dtynan@altos86.Altos.COM (Dermot Tynan) (07/19/89)
In article <256@escargot.UUCP>, chrisb@escargot.UUCP (Chris Bradley) writes: > > What I'd like to do is add in "x", "y", and "z", respectively, for X, Y, and > Zmodem. Do X, Y, and Z already exist? If not, is it okay to impliment this > feature in my bbs so I won't clash with anything else? If it isn't a good > idea, what would any of you suggest? > -->Chris Well, I am the self-appointed "keeper-of-the-list". Seeing as no-one else out there was keeping track of protocol letters, I assumed the job. If you (or anyone else) want to generate a new protocol, I would ask that you let me know (dtynan@zorba.Tynan.COM), so I can check to see if the letter is available, and if not, I can add it to the list. Also, if anyone is interested in making their protocol available (in source form, natch!), I'd be more than happy to snag a copy. Furthermore, if you know of any protocol in existance, which is not on the below list, I'd appreciate it if you'd let me know. ---------- CUT HERE ---------- CUT HERE ---------- CUT HERE ---------- Official GNUUCP Protocols List ============================== Created by: Dermot Tynan (gnu@zorba.Tynan.COM) Last change: December 13, 1988. In an effort to keep track of all the different protocols available for the GNU UUCP implementation (GNUUCP), I am keeping a master copy of this list. If you know of a protocol which is not on this list, please let me know (gnu@zorba.Tynan.COM). If, on the other hand, you wish to develop a *new* protocol for GNUUCP, please contact me, and I will allocate a letter for you. Remember, of course, that in accordance with the terms of the GNU copyleft (see the file COPYING), if you develop a new and improved protocol for GNUUCP, you must make it available in source form. Here is the most up-to-date list: b - This is reported to be an extended version of the 'g' protocol. e - This is a variation on the 'f' protocol. Probably for use with Ethernet. f - This is an X.25 protocol implementation. It assumes that the channel is error-free. g - The standard UUCP packet protocol (named after Greg Chesson, it's inventor). The mainstay of UUCP communications. k - Similar to 'f' for 7-bit in-band flow control channels included with PCMAIL which was posted to comp.sources.misc recently. t - This protocol was developed for use over flow-controlled error-free transports such as TCP/IP. x - Also similar to the 'f' protocol. Developed by AT&T, for use over X.25, but doesn't support checksums. z - It is rumored that someone is working on this protocol, to be used with ZMODEM. Film at 11. A - Designed for use with UUCP over Appletalk (ATP based) I would like to thank the following people, for helping me produce this list: Dave Arnold <dave@arnold.UUCP> Paul Campbell <mtxinu!taniwha!paul> Robert Claeson <uunet!ERBE.SE!prc> Matt Goheen <ames!srs!matt> Guy Harris <mips!auspex!guy> Karl Swartz <ditka!rt1!kls> Lauren Weinstein <rand.org!vortex!lauren> Edwin Wiles <sundc!netxcom!ewiles> ---------- CUT HERE ---------- CUT HERE ---------- CUT HERE ---------- -- dtynan@altos86.Altos.COM (408) 946-6700 x4237 Dermot Tynan, Altos Computer Systems, San Jose, CA 95134 "Far and few, far and few, are the lands where the Jumblies live..."
csg@pyramid.pyramid.com (Carl S. Gutekunst) (07/19/89)
> e - This is a variation on the 'f' protocol. Probably for use > with Ethernet. 'e' is the "error free" protocol written for the Streams TLI interface of HoneyDanBer UUCP. Peter Honeyman has blamed it on various people from time to time. :-) It requires that the link be error free and 8-bit transparent. > f - This is an X.25 protocol implementation. It assumes that > the channel is error-free. This is a 7-bit printable-ASCII only protocol, allowing in-band flow control, and providing a simple checksum per file. It is specifically for X.29 links, which are considered "mostly error free," but where some kind of end-to-end error detection is required. > t - This protocol was developed for use over flow-controlled > error-free transports such as TCP/IP. Yup. Written by Rick Adams, it is (coincidentally) almost identical to 'e', but never-the-less quite incompatible. Rick has mentioned that he would never have written 't', had he known that 'e' already existed. > x - Also similar to the 'f' protocol. Developed by AT&T, for use > over X.25, but doesn't support checksums. Nothing at all like the 'f' protocol, 'x' requires a completely error free line, 8 bit transparency, and the ability of the network to pass a zero-length data packet end-to-end. As such, it is useless for virtually any application. > z - It is rumored that someone is working on this protocol, to > be used with ZMODEM. Film at 11. Yeah, we'll let you know. :-) Also: d - Datakit. A trivial variant of the 'x' protocol, it adds Datakit- specific setup, end-of-file, and other optimizations. G - Rick Adams' extended 'g' protocol. s - A streaming protocol I am designing, with adaptive encoding and efficient, robust error correction. <csg>