I don't actually think my experience in this area is broad enough to have an informed opinion on what is "exact and complete". I have implemented several RFC's, but these are of varying quality, in some cases a DECnet specification being undoubtedly better.
That being said, I think what was in the back of my mind were the
SMTP and FTP specifications, RFC959 being paradigmatic,
5.3. COMMANDS
The commands are Telnet character strings transmitted over the control connections as described in the Section on FTP Commands.
[...]
The commands begin with a command code followed by an argument field. The command codes are four or fewer alphabetic characters. Upper and lower case alphabetic characters are to be treated identically. Thus, any of the following may represent the retrieve command:
RETR Retr retr ReTr rETr
This also applies to any symbols representing parameter values, such as A or a for ASCII TYPE. The command codes and the argument fields are separated by one or more spaces.
I hasten to add that Johnny has had to repeatedly pound into my
head that FTP and DAP are most emphatically not the same
thing. So, have to stop thinking apples as oranges.
On 11/22/22 1:46 PM, Paul Koning wrote: For RSTS/E at least, that's often true in the later versions, not so much in the early ones. And it requires work to do case-insensitive matching, which was made easier in a later RSTS/E version (V5 or V6 I think) with a string transformation function in Basic-Plus. Before then, e.g., in RSTS V4, being case insensitive was a major hassle and unlikely to be practiced consistently. As for protocols, that's different from user interfaces. If there is a list of values you should assume that's the list, and not rely on fuzzy matching unless explicitly mentioned in the document. Unlike RFCs, DECnet specs should be treated as exact and complete, because by and large they are. paul
On Nov 22, 2022, at 12:25 PM, Thomas DeBellis <tommytimesharing@gmail.com> wrote: Well... Yes, it is a true statement that DAP V5.6 is showing the list of months in upper case (pages 63 and 64), so no disagreement there. On the other hand, nowhere in the specification do I find any mention of either an UPPER or lower case requirement for any character string and that is something I would have expected if it were an explicit requirement. Historically the DEC systems that I used (OS-8, RSTS/E, RSX, VMS, Tops-%0, Etc.) were largely case insensitive and that was my expectation.