Shmuel, I appreciate this is a serious comment from you but I hope you'll forgive a light-hearted take, at least initially.
Surely RFC 2119 is an useful contribution to the establishment of standards by means of RFCs but it's all starting to look a bit circular in the kitten chasing its tail sense. For example, when RFC 2119 says the following: Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. I noticed the "should" in the quote above wasn't in upper case but then maybe that's because this declaration had not yet taken effect in RFC 2119. Following this they provide a few examples of what I assume they consider the proper use of upper and lower case with their key words. Anyhow, I'm glad that they made sure - for the benefit of speakers of the German language - that MUST NOT was defined precisely. For readers who do not know German, ""muß nicht" translates as "need not", not "must not", in English - which caused me much confusion during my driving lessons in Vienna. (A driving test used to be required for all residents of Austria staying more than a year.) "You must stop at a T-junction where the white line is solid; you need not stop at a T-junction where the white line is not solid." Imagine that as I heard it in the original and you'll see I saw myself being required to drive in front of a tram!" Enough frivolity. The strictures you gave in your example are actually not important since the TN3270E client cannot know whether or not the TN3270E server is of the "passthrough" type, where all input and output is determined by the VTAM USS table meaning the input commands may only partly be known because the IBM default table commands may be exposed and the output messages are entirely unknown and in the hands of the system programmer who put the table together - or - the TN3270E server is of the limited type which follows the - really no better than - suggestions of RFC 2355. In fact those suggestions follow the very basic use of the IBM default table in the "logoff" command and, almost follow, in the USS message 2. Given this inability to be able to distinguish between the two cases, there is no point in regarding what RFC 2355 describes as mandatory. It's actually my whole case that the CS IP TELNET server logic SHOULD be able to pretend to be of the "passthrough" type because it CAN. Chris Mason ----- Original Message ----- From: "Shmuel Metz (Seymour J.)" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Monday, 23 January, 2006 6:46 PM Subject: Re: TN3270 Question > In <[EMAIL PROTECTED]>, on 01/20/2006 > at 08:42 PM, Chris Mason <[EMAIL PROTECTED]> said: > > >You need to read section 10.5 The SYSREQ Function of RFC 2355 in > >order to know why this discussion is taking place. > > I took a look at RFC 2355, and see several disturbing things. First, > thewre is a lot of text that uses lower case instead of RFC 2119 > language. I don't know whether "should" means "SHOULD", "MUST" or > neither. Specifically, does > > - if the user transmits anything other than LOGOFF, the server > should respond with the string "COMMAND UNRECOGNIZED" to the > client. The server should not send anything to the host > application on behalf of the client. > > Really mean > > - if the user transmits anything other than LOGOFF, the server > SHOULD respond with the string "COMMAND UNRECOGNIZED" to the > client. The server SHOULD NOT send anything to the host > application on behalf of the client. > > ? If it does, then there is some wiggle room. OTOH, there is no wiggle > room if it really means > > - if the user transmits anything other than LOGOFF, the server > MUST respond with the string "COMMAND UNRECOGNIZED" to the > client. The server MUST NOT send anything to the host > application on behalf of the client. > > IAC, it might be appropriate to submit comments to the IETF on this > and other issues, e.g., sessions whose primary size is not 24x80. > > -- > Shmuel (Seymour J.) Metz, SysProg and JOAT > ISO position; see <http://patriot.net/~shmuel/resume/brief.html> > We don't care. We don't have to care, we're Congress. > (S877: The Shut up and Eat Your spam act of 2003) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
