alb (03/01/83)
A few comments on the proposed standard. Section 2.1.1 -- ''Relay-version must always be the first in a messages; thus, all articles meeting this standard will begin with an upper case ``R''.'' <-- There is a provision later down in the text that says that an article with a Relay-version header not first will be accepted, but there is no mention made of article with no Relay-version at all. Will they be accepted? I certainly hope so, since if not, it will render all software before 2.10 unusable. Section 2.1.7 -- This suggests that message ID's be in the format: <unique@full-domain-name> This looks just like an internet address and has the potential of being confused with an internet address by some Joe who is reading the raw article (i.e. not processed by a user interface such as readnews) I propose we stick with: <site.unique> to avoid confusion. Section 2.1.8 -- This places no restrictions on the format of the Path header. I propose that the Path header be restricted to the form: sitea!siteb!sitec!etc!user and that it be used by news interfaces to generate reply addresses for non-internet mailers. Otherwise, there is no non-internet address information at all, and the article even states in section 4 that it would be ''difficult or impossible'' to reply if the site did not have an internet mailer. That is just plain non-user-friendly and people aren't going to like it at all (see my comment below on switching to standards) If the Path header is going to unrestricted, I suggest at least a REQUIRED ''Non-internet'' header which will contain the return mail address in the current a!b!c!user form so that existing mailers will continue to work. Standards are fine, but not when they break everything that is currently in existence (no, that's not my later comment on standards; that's at the end). Section 2.2.1 -- Until we all change to the internet protocol, the Reply-to field breaks most all of the existing Mailers in that they take it literally and try to reply to the exact address given. If it is an internet address and a non-internet Mailer or if the Mailer can't get to the first machine in the path, the mail will fail and the user will get frustrated. While the Reply-to field is a good concept, its use should be discouraged and it should be known that it will probably not generate acceptable addresses for most of the net. Section 2.2.6 -- The References header is currently in recent B news versions but it is never shown to the user. Why? Will it be shown in 2.10? I think it should. Otherwise, it serves no purpose (the software certainly doesn't care about what's followed up to what, only the user does, and he/she currently isn't presented with the information, though it is available.) Section 2.2.7 -- This says that any messages submitted to a group matching all.all.ctl will be taken as a control message. Why require two levels above the .ctl? I think that anything ending in .ctl should be a control message. e.g. We have a local group called 'test' which is distributed around alice and rabbit. If I want to try out a control message and cancel an article, I currently have to submit it to to.alice.ctl and to.rabbit.ctl -- why prevent me from using test.ctl? Section 4 -- Again, this states that most addresses in the new articles will be internet addresses and there will be NO (nil, none, zero) guaranteed non-internet addresses supplied. This just breaks most every mailer in existence. It is IMPERATIVE that some non-internet information be guaranteed so that current software will continue to work. Now, the moment you've all been waiting for: my comment on standards. The point of a standard is to keep everyone talking, right? Right. We are now a network with virtually no standards. We have generally accepted protocols for format, but nothing is required. We cannot make the transition from that type of network to one where things must rigidly follow one standard coldly. That is to say, there must be a smooth transition over a period of time. We cannot overnight switch to a new standard. ARPA tried it this past New Year and it seems that only now they are beginning to recover from the shock. It will be worse with us, since we have no central control (this is not to advocate central control either!) I'm saying that we must do this gradually. We must provide a means for keeping the old software working. The 2.10 and later news releases should be compatible with the old software. This includes providing both internet and non-internet address information. Granted, the emphasis should be on the new internet standard, but that does not mean we abandon the old protocol in the gutter. We have to provide users of the old systems with a new system that will not leave them out in the street. Eventually, we should all be following one standard, hopefully the internet standard; however, we cannot say today that tomorrow we will do it and that's final. Adam