mark@cbosgd.UUCP (09/09/83)
gummo!ber Sep 8 09:12:00 1983 The correct behaviour of uucp is that which is reasonable, effective and logically valid. Although most versions of uucp truncate system names to seven characters, that behaviour is incorrect. I don't know where ber gets his ideas about what "correct" means, but I beg to differ. When you have a large network of over 1500 sites, many of which you have no idea who they are or how to contact them, and you do not have administrative control over any of them, the ONLY correct behavior is behavior which is upward compatible with the existing protocol, or which has a behavior which is not quite compatible but nothing really bad happens. Don't forget, too, that there are people with binary licenses out there. While I think it is silly for UUCP to truncate at 7 characters, I believe that decision was made to force spooled files of the form C.abcdefgP1234 to fit in the 14 character filename space. I am not convinced that a few sites suddenly not truncating will not break some site somewhere severely (e.g. cause uucico to dump core from some buffer which has overflowed.) I call on the authors of this new UUCP to do the following: (1) Describe this new behavior in more detail. Exactly what is different? System names get transferred in lots of different places - in the Shere=sysname, in the reply, in file names stored, in filenames transferred, in filename copy requests, in the files that are transferred that are generated by UUCP, in mail, in news. Which of these are affected? Is there a new upper limit on the length of a host name, or the number of characters that must be unique, such as 14? (2) Convince the net that the behavior of this new UUCP is upward compatible with the existing versions of UUCP. (3) If there is a simple set of changes that can be made to an existing UUCP that will upgrade it, post this set of changes and tell us how to upgrade, what the results of this upgrade will be, and what will happen if they don't upgrade. (4) Tell us what machines currently run this new UUCP, and what distributions will contain it. I would also tell you that it is crucial for this UUCP to go into the public domain, but since you are an employee of Bell Labs, we all know where that would lead. I also submit that we (those of us running UUCP) as a network are vulnerable, because there is no "standard" document that defines the UUCP protocol. Lacking such a document, we cannot point to it as defense against some new incompatible implementation. This problem has come up before - some system changes their UUCP to check certain things that were not checked before for security reasons, and some other system changes things so that these checks no longer work. Both new UUCP's work with a vanilla V7 UUCP, but they don't work with each other. Who is wrong? Nobody knows. I call on the experts on the net (Lauren Weinstein, Peter Honeyman, and whoever else is involved and interested) to write a standard document that defines the UUCP protocol. Mark Horton
tbray@mprvaxa (09/12/83)
This is to voice my support for M Horton's point of view. Backwards compatibility is in fact a sine qua non of UUCP, and furthermore I feel that 7 characters is, if not ideal, livable. I am intimate with the Bell UUCP code and implementing full system names would be - uh - nontrivial. Also, UUCP has several FAR more glaring deficiencies than the system-naming rules - to the extent that I question the value of putting band-aids over little problems like system names. I speak from the midst of a UUCP port - would be happy to contribute to a standard. Working without one has contributed to my receding hairline in past weeks... T Bray ...decvax!microsoft!ubc-vision!mprvaxa!tbray
ber@gummo.UUCP (09/13/83)
#R:ihnp4:-42200:gummo:34700003:000:484 gummo!ber Sep 12 20:49:00 1983 I posted an article here to head off a negative backlash toward an as yet unanounced, unpublished, unoffered version of uucp. I posted a trivial fix to existing versions of uucp for those readers who might be interested. This modification is applicable to both source and object code. Keep in mind that this token problem only affects consenting sites and is not cause for public concern. I apologize for binary only Unix licensees. I would that they weren't. brian redman