geoff@utstat.uucp (Geoff Collyer) (08/18/89)
Rick Adams: >Cnews [sic] is another transport system (just like notes is). it may be >better or worse, but it clearly paid no attention to backwards >compatibility. Nonsense. C news meets the specification for message format in RFC 1036 and provides a compatible interface to the newsreaders (e.g. the active file, stored articles and silly options to inews); our sys file is compatible with the B 2.11 one except for a few obsolete options for multicasting (see our batcher) and unbatched ihave/sendme. News administration differs somewhat from B news, but the C news rules are documented and easy to learn. We exchange news with B news sites and have run vanilla news readers like readnews, rn and nn locally. -- Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu
rick@uunet.UU.NET (Rick Adams) (08/19/89)
nonsense. The RFC was an attempt to document the behavior of Bnews. (The rfc is 4 years old and out of date.) Where the RFC and Bnews differ the behavior of Bnews should generall be considered correct. To me (and just about everyone else) backwards compatible means behaves the same as Bnews. As I said before, your wrote something compatilble with the the RFC, so your have developed a new transport. It is not backwards compatible with Bnews. You are doing everyone a great disservice claiming that it is backwards compatible. Anyone who has tried to use Cnews will tell you that it is not. Note the argument is not better or worse, but compatible vs. incompatible. Cnews chose to have serveral incompatible (and wrong in my opinion) differences with Bnews. Fine. Just dont claim to be backwards compatible. Dont rationalize your decisions by referring to the RFC. If you were concerned about backwards compatibility, then you would have paid attention to current behavior of the commonly used program that defines the behavior that everyone expects.
fletcher@cs.utexas.edu (Fletcher Mattox) (08/19/89)
If C news is backward compatible with B news, then why do I have to have to modify NNTP to work with with C news? Fletcher
geoff@utstat.uucp (Geoff Collyer) (08/19/89)
Rick Adams: > (The rfc is 4 years old and out of date.) My copy of RFC 1036 is dated December 1987, so I make it 1.67 years old. > Where the RFC and Bnews differ the behavior of Bnews should generall be > considered correct. Henry and I do not buy this argument. The behaviour of B news does not make a de facto standard. > To me (and just about everyone else) backwards compatible means behaves > the same as Bnews. Perhaps we are not speaking the same language. My OED says ``compatible a. Consistent, able to coexist, (with); mutually tolerant; (of equipment etc.) able to be used in combination''. I don't see any meaning which implies cloning. C news is not a clone of B news. People who want a clone should get B news; it's a clone of B news. > your wrote something compatilble with the the RFC, so your have developed > a new transport. It is not backwards compatible with Bnews. And where is C news incompatible with the message format of B news? Our users seem to be exchanging news with B news sites just fine. > You are doing everyone a great disservice claiming that it is > backwards compatible. Anyone who has tried to use Cnews will tell > you that it is not. We have had letters from many satisfied users of C news; no one (other than you) who has actually used C news claims that it is incompatible with B news. > Cnews chose to have serveral incompatible (and wrong in my opinion) > differences with Bnews. Again, what are they? We haven't seen them. > If you were concerned about backwards compatibility, then you would have > paid attention to current behavior of the commonly used program > that defines the behavior that everyone expects. We have no interoperability problems. Fletcher Mattox: > If C news is backward compatible with B news, then why do I have to > have to modify NNTP to work with C news? In general, you don't have to; you can continue to suffer horrible performance. The two things you do need to compensate for are that B news changed its mind about case sensitivity of Message-IDs and C news uses the B 2.10.1 interpretation (case insensitive), and that NNTP relies on an implementation detail, the format of the second field of the history file (which B news changed its mind about; NNTP wants the B 2.11 format), so we provide a minor change to nntp/server/newnews.c to understand the C news format. -- Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu
rick@uunet.UU.NET (Rick Adams) (08/19/89)
In article <1989Aug19.004434.29961@utstat.uucp>, geoff@utstat.uucp (Geoff Collyer) writes: > Rick Adams: > > (The rfc is 4 years old and out of date.) > > My copy of RFC 1036 is dated December 1987, so I make it 1.67 years old. However, the text of the rfc was frozen and sent to Postel the summer of 1986. It took him well over a year to "release" is as an RFC. This is also why no on has bothered to do an update. The text of the RFC is basically 1985 with minor changes in early 1986. (SCCS logs support this.) If I buy a copy of Robinson Crusoe that has a 1985 printing date on it, I dont claim the book is only 4 years old. The date on the RFC is the printing date, not the date of the information. > > > Where the RFC and Bnews differ the behavior of Bnews should generall be > > considered correct. > > Henry and I do not buy this argument. The behaviour of B news does not > make a de facto standard. WRONG. Pull your dictionary out again. Something is a de facto standard when the vast majority of sites comply with it. Since the vast majority of sites run Bnews, they can be said to comply with it. You are thinking of de jure standard, which is is not. > > > To me (and just about everyone else) backwards compatible means behaves > > the same as Bnews. > > Perhaps we are not speaking the same language. My OED says > ``compatible a. Consistent, able to coexist, (with); mutually > tolerant; (of equipment etc.) able to be used in combination''. I > don't see any meaning which implies cloning. C news is not a clone of > B news. People who want a clone should get B news; it's a clone of B > news. Who cares about the definition of compatible. What does the OED say about backwards compatible. Something is backwards compatible when you can replace an older system with it and things keep running. If you could remove all of the Bnews executables and replace them with Cnews and the system kept running, then it would be backwards compatible. Clearly you can not do that. Therefore, clearly it is not backwards compatible. > > > your wrote something compatilble with the the RFC, so your have developed > > a new transport. It is not backwards compatible with Bnews. > > And where is C news incompatible with the message format of B news? > Our users seem to be exchanging news with B news sites just fine. No one is arguing about the message format. Notes files exchange articles with Bnews sites too. Would you claim they are backwards compatible. The notes people wouldn't. They also wouldn't care. > > > You are doing everyone a great disservice claiming that it is > > backwards compatible. Anyone who has tried to use Cnews will tell > > you that it is not. > > We have had letters from many satisfied users of C news; no one (other > than you) who has actually used C news claims that it is incompatible > with B news. Ask them. EVERYONE I have talked to has said it is not backwards compatible. God, look at all the patches for nntp compatibility, etc. Interoperable hsa nothing to do with backwards compatibility. > > Cnews chose to have serveral incompatible (and wrong in my opinion) > > differences with Bnews. Messageids are case independant. Period. You intentionally ignore it with some sleazy rationalization about its not being in the RFC. The RFC is wrong. My name is on the RFC. I think that lets me say with some authority whether the RFC is wrong or not. > Again, what are they? We haven't seen them. > > > If you were concerned about backwards compatibility, then you would have > > paid attention to current behavior of the commonly used program > > that defines the behavior that everyone expects. > > We have no interoperability problems. Damn it, try having the same conversation as I do. No one has said it does not interoperate. It does. So does Notes. However Cnews is not backwards compatible with Bnews. Interoperability has nothing to do with backwards compatibility. > > > Fletcher Mattox: > > If C news is backward compatible with B news, then why do I have to > > have to modify NNTP to work with C news? > > In general, you don't have to; you can continue to suffer horrible > performance. The two things you do need to compensate for are that B > news changed its mind about case sensitivity of Message-IDs and C news > uses the B 2.10.1 interpretation (case insensitive), and that NNTP > relies on an implementation detail, the format of the second field of > the history file (which B news changed its mind about; NNTP wants the B > 2.11 format), so we provide a minor change to nntp/server/newnews.c to > understand the C news format. Jesus. Would you drop your damned "bnews sucks" campaign. Bnews fixed a bug in the early code that didnt ignore case. it didn't "change its mind" B 2.10.1 is BROKEN. Basing Cnews on 5 or 6 year old code was just plain stupid. Would you write a unix and base it on Version 7 and claim it was backwards compatible with System 5? Of course not, people would laugh at you. This situation is similar. Your last sentence says it all. Backwards compatible programs DO pay attention to implementation details. Thats what backwards compatible means. Why dont you just admit that you did a better, but non-backwards compatible implementation? There is nothing wrong with that. --rick
jbuck@epimass.EPI.COM (Joe Buck) (08/19/89)
In article <64125@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: >nonsense. The RFC was an attempt to document the behavior of Bnews. >(The rfc is 4 years old and out of date.) Where the RFC and Bnews differ the >behavior of Bnews should generall be considered correct. That's not acceptable, Rick. B news has evolved and mutated beyond recognition, and in many places it's just plain broken. Or do you want to tell me that the B news behavior when handed the line Distribution: world,!eunet is correct? Hardly; this was broken long ago, and you told me yourself that this part of the code was so horribly complex and unwieldy you don't dare touch it. Must we duplicate B news bugs and all? Just the same, you have a point. The RFC only describes article format and distribution and the meaning of header fields; it says nothing about sys file formats, active file formats, command line options, etc. I thought the idea of C news was to make a small, fast, tight system that could be dropped in in place of B news with minimal changes. There seem to be quite a few gratuitous changes, as you say. It's not sufficient to meet the RFC to call yourself "backward compatible". But if RFC1036 (? is this the number) is out of date, put out a revision (for example, the "Supersedes:" header is a new feature). -- -- Joe Buck jbuck@epimass.epi.com, uunet!epimass.epi.com!jbuck
geoff@utstat.uucp (Geoff Collyer) (08/19/89)
Pardon me, I did mean "de jure", not "de facto". > Something is backwards compatible when you can replace an older system > with it and things keep running. > If you could remove all of the Bnews executables and replace them > with Cnews and the system kept running, then it would be backwards > compatible. Clearly you can not do that. Therefore, clearly it is not backwards > compatible. Using your definition of "backwards compatible", we have never intended to claim that C news is completely backwards compatible with B news. You cannot just remove your B news binaries and install C news and have nothing break, though we believe that most things will continue to work. > Messageids are case independant. Period. You intentionally ignore it > with some sleazy rationalization about its not being in the RFC. > The RFC is wrong. My name is on the RFC. I think that lets me > say with some authority whether the RFC is wrong or not. We did not cite "some sleazy rationalization", we cited RFC 822, which RFC 1036 claims takes precedence in case of a disagreement. RFC 822 says that local-parts are case-sensitive. Are you now saying that 822 does not take precedence over 1036 in general or just in this one case? > Jesus. Would you drop your damned "bnews sucks" campaign. I did not say "bnews sucks" and perhaps I should not have said "horrible". It's tricky to talk about news performance without offending. > Why dont you just admit that you did a better, but non-backwards compatible > implementation? There is nothing wrong with that. Okay, by your definition of "backwards compatible", we wrote a better, but not-completely-backwards-compatible news implementation. -- Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu
emv@math.lsa.umich.edu (Edward Vielmetti) (08/19/89)
In article <64167@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: >The RFC is wrong. My name is on the RFC. I think that lets me >say with some authority whether the RFC is wrong or not. Sounds like it's time to update the RFC, then. --Ed
rick@uunet.UU.NET (Rick Adams) (08/19/89)
Yes Bnews has bugs. no doubt about it. My point is that blindly relying on the rfc is not good. blindly relying on a particular piece of code is not good. If you discover a case that the RFC doesnt fully handle or that differs from the bnews code, ASK someone what the intent was. Dont go your own way.
henry@utzoo.uucp (Henry Spencer) (08/20/89)
In article <3536@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes: >... The RFC only describes article >format and distribution and the meaning of header fields; it says >nothing about sys file formats, active file formats, command line >options, etc. I thought the idea of C news was to make a small, fast, >tight system that could be dropped in in place of B news with minimal >changes. There seem to be quite a few gratuitous changes, as you say. Active file format is compatible, period. Sys file format is compatible with the exceptions of a few very obscure flags and ihave/sendme (which almost didn't make it into C News at all). Command line options are compatible on all the things -- i.e., inews -- that users have any business invoking. The sysadmin interface *is* different; we don't feel we could have avoided that. We'd be interested to hear which changes you consider "gratuitous"; we did make some effort to be incompatible only when there was a reason. >It's not sufficient to meet the RFC to call yourself "backward compatible". Well, yes and no. There really are several different aspects of backward compatibility involved here. Interoperability we have got, 100% -- proof by demonstration, i.e. all the C News sites out there interoperating with B News sites. User-level and newsreader-level compatibility we have also definitely got, proof is trivial since most C News sites (including ours) run user-interface software written for B News. Sysadmin compatibility we have not got -- 95% in file formats, less in commands -- but we feel there were adequate reasons for that. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (08/20/89)
In article <773@stag.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: >>The RFC is wrong... > >Sounds like it's time to update the RFC, then. Geoff and I see nothing wrong with it apart from excessive vagueness in some places -- in particular, you *cannot* understand ihave/sendme from the RFC's description -- but would not deeply object to an effort to revise it. We trust that any such effort would consult with, and pay attention to, the authors of the major news software packages currently in use or under development. (And that, given the number of sites running C News already, we would be counted as such.) (No, we don't want veto power, but we want to see "alternate" packages like 3.0 and C News treated as equals, i.e. B2.11 doesn't get veto power either.) -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (08/20/89)
In article <64125@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: >... The RFC was an attempt to document the behavior of Bnews. That is its origin. However, it does not say "this is the standard for the behavior of B News", it says "this is the standard for news transmission". And it does say "standard". Definitions of the C language started out more or less as documentation of the behavior of Dennis Ritchie's C compiler, but these days the compilers are written to match the standards, not vice versa. Same thing for RFC1036: its flaws and origin notwithstanding, it is written as an implementation-independent standard for news transmission, and we treat it as such. >... Where the RFC and Bnews differ the >behavior of Bnews should generall be considered correct. Um, considered by who? This is like AT&T saying "where POSIX and System V differ, the behavior of System V should be considered correct". The older documents that POSIX is derived from did originate as an attempt to document the behavior of System V, but these days the standard is the primary document. RFC1036 says it is the standard; we believe it. On a more pragmatic note, there are a couple of very serious problems with taking B News's behavior as the standard. One is that it's a moving target: B2.11 differs from B2.10.1 in important ways. (Some of the B2.11 <-> C News differences arise because some of C News predates 2.11.) Another is that finding out what that behavior *is* can be very difficult. Geoff had to resort to the B News code to figure out ihave/sendme, since RFC1036's description is simply inadequate. It took him a long time. The groaning, swearing, and complaining were something to hear. The B News code is not practical as a standards document. >To me (and just about everyone else) backwards compatible means behaves >the same as Bnews... As I've said in another article, there is more than one aspect of compatibility involved here, and we are backward compatible in most of the ones that matter to most people. >You are doing everyone a great disservice claiming that it is >backwards compatible. Anyone who has tried to use Cnews will tell >you that it is not. Many people who have tried, and succeeded, and continued using it, tell us that it is. Rick, you have some special problems, given the enormous size of your sys file and your complex administrative situation. We recognize this, and in the past have offered to help (specifically, to take a look at your sys file and shell programs for compatibility problems). But most sites do not have the problems you have with even the slightest change to the sysadmin interface, and find C News's major-although-imperfect backward compatibility adequate for their purposes. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (08/20/89)
In article <64167@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: >Something is backwards compatible when you can replace an older system >with it and things keep running. Quite a few older systems have been replaced by C News, and Usenet is still running fine. When people replace B2.nn with C News, their news readers keep running. (In fact, utzoo ran B New's readnews until about a year ago.) Sounds backwards compatible to me. >If you could remove all of the Bnews executables and replace them >with Cnews and the system kept running, then it would be backwards >compatible. Clearly you can not do that. Therefore, clearly it is not backwards >compatible. Of course, when one replaced the B2.10.1 executables with B2.11 ones, duplicate-article rejection broke until all the old entries got expired out of the history file, because of the change to message-id case policy. That being a rather serious matter for many sites, clearly B2.11 was not backwards compatible with B2.10.1, by your reasoning. (*Why* it was done is irrelevant, by your own definition.) >Messageids are case independant. Period. You intentionally ignore it >with some sleazy rationalization about its not being in the RFC. We ignore it because the specifications say it's not true. The matter very definitely is in RFC822. RFC1036 says 822 dominates in the event of dispute, and on this issue there isn't even a dispute, since 1036 is silent on the matter. (Actually, we agree that the wording about 822 dominating needs to be revised, since taken literally it invalidates most of 1036, but here there can be little doubt about what the current specs say.) >The RFC is wrong. My name is on the RFC. I think that lets me >say with some authority whether the RFC is wrong or not. No argument. However, it begs the question: what's right? Dennis Ritchie considers C bitfields "a botch and a blemish" (his exact words), but I trust you would not buy a C compiler that therefore left them out. Dennis no longer sets the standard for C; B2.11 and its maintainer no longer set the standard for news. In both cases, the standard is set by a consensus document, not by a man ("government of laws, not men"). When the documents are wrong, eventually they get revised, but until then, they are the best standard we've got and the proper basis for a new implementation. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
scott@dtscp1.UUCP (Scott Barman) (08/23/89)
In article <64229@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: >Yes Bnews has bugs. no doubt about it. Show me software that doesn't have bugs and I'll show you obsolete software! :-) >My point is that blindly relying on the rfc is not good. blindly >relying on a particular piece of code is not good. > >If you discover a case that the RFC doesnt fully handle or that >differs from the bnews code, ASK someone what the intent was. Dont >go your own way. I've been watching this argument and trying to find some that I've been in in the news.* concerning standards. (I am not trying to dredge that argument up again, but I am using it for illustration) I wanted to know why headers, etc. were the way they were and all I got many very high flames telling me to read the RFC. I changed the question and was told to read the RFC. Even when I questioned what RFC stood for, I was emphatically told that it is the standard. Now (and I am making this naieve sounding on purpose), the same person who told me to think of RFC standing for "Requirements for Compliance" when I said I had a problem with the name is saying *NOT* to follow the RFC because it is wrong! This leads to the question what other RFCs are wrong? Are the RFCs standards or are selected ones standards at the whim of the author? Where are the lines drawn? Rick, I am *not* "against" you, but something you said does bother me. Something that was written four years ago and updated 1.6 (whatever) years ago is 1.6 years old. If Websters updates their dictionary in 1988, the dictionary is one year old, not the age of it from when the word "radio" first appeared. If that 1987 released RFC is not correct, then maybe an update is in order. But either way, it is a document udated and realased in 1987 not 1985! -- scott barman {gatech, emory}!dtscp1!scott
ted@frf.omron.junet (Ted Timar) (08/23/89)
Rick and Henry are both considered Net.Gods. Geoff probably soon will be. Why are you flaming each other in news.software.b? Please stop. Discuss the situation by E-mail, then calmly and rationally post, your conclusions. Even if they just say, "Here are our opinions. We disagree on these 5 points." My comments are: Long ago, somebody told me, "If the documentation disagrees with the code, they are probably both wrong." This is probably worth considering in the B2.11 vs. RFC 822/1036 considerations. It is a well known fact that what are known to the world as "bugs" are known to programmers as "undocumented features". This could also be used to explain the above controversy. Personally, I see only a few potential problems. If the Message-Id is treated as case insensitive, one day, some really stupid program will produce message-id's that differ only in case. If Message-Id's are treated as case sensitive, some stupid program will convert all incoming Message-Id's to upper (or lower case). The best rule I can see is to treat Message-Id's as case sensitive, and risk getting duplicates on rare occasions. Regardless of all else, being as there are other news programs to consider. These are B3.0 (TMNN), Notes and software for other OS's. Please look at all of these, and come to some consensus. (Have a vote among all of the authors or something.) When you come to this consensus, change the RFC without delay. Do it NOW. Please do not wait until tomorrow. TMNN is forthcoming. Many programs of who's existence we are totally unaware are being written right now. -- These are OBVIOUSLY my opinions and no-one else's. Ted Timar tmatimar@watmath.waterloo.edu uunet!watmath!tmatimar