Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop The Open Brand -- Problem Reporting and Interpretations System

Problem Report 2004 Details

Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 2004.

---

Report 2004 Actions Problem Report Number 2004 Submitter's Classification Specification problem State Resolved Resolution Rejected (REJ) Problem Resolution ID REJ.X.0590 Raised 1996-09-20 08:00 Updated 2003-03-13 08:00 Published null Product Standard Transport Service XTI Certification Program The Open Brand certification program Test Suite VST version 4.1.4 Test Identification XTI.os/util/error 3 Problem Summary PGT4R.019 In addition to error test 3, strerror test 2 has the same problem. The t_error() specification states the following about the error message: "If it is in English, the error message string describing t... Problem Text In addition to error test 3, strerror test 2 has the same problem. The t_error() specification states the following about the error message: "If it is in English, the error message string describing the value in t_errno is identical to the comments following the t_errno codes in xti.h" The t_strerror() specification states the following about the error message: "If it is English, the error message string describing the value in t_errno is identical to the comments following the t_errno codes defined in <xti.h>" The test expects these error strings to be similar to the CONTENTS of the comments (NOT identical to the comments, that would include the "/*" and "*/" of C language) to the C implementation of xti.h contained in Appendix F. We interpret the specification to require that matching error messages to comments in our header implementation (and not the contents of comments in Appendix F) is allowed. We also interpret that our header file <xti.h> need not have C comments identical to the C comments in header in Appendix F. The "Networking Services, Issue 4" specification man pages for t_*() interfaces do refer sometimes to text elsewhere in the specification by use of explicit reference. Examples of these are - CAVEATS section of t_accept() refers to Appendix A & B and page numbers - DESCRIPTION section of t_look() refers to Section 5.6 with associated page number. - DESCRIPTION section ("flags" description) of t_open refers to Appendix A with explicit page number reference. - DESCRIPTION section of t_optmgmt() (for exact OPT_NEXTHDR definition) points explicitly to Appendix F with page number. - DESCRIPTION section of t_optmgmt() explicitly references Chapter 6 (on use of options) for detailed description about use of options. In stark contrast to these, the t_error() and t_strerror() DESCRIPTION does not refer at all to Appendix F or its page number. Therefore we interpret that it is sufficient for error strings to match the contents of comments in error code definitions in our implementation of <xti.h>. Moreover, the Appendix F refers section 7.1 page 47 for the normative requirements. Section 7.1 on page 47 states that "XTI structures and constants are all defined in Appendix F on page 253". It does not place a normative requirement on C language comments contained in that header. In our implementation, the error messages DO match the comments in the implementation of our header. Our shipped man pages match the language as in XTI spec and they refer the the xti.h header found in the implementation. There are other troubling issues raised by this area of the specification. - The error messages in Appendix F are short, cryptic, 80-column delimited C language comments probably constrained by the C coding style in a particular reference implementation. They are not, in some cases informative in terms of their contents as error message strings for application programmers. It would only be subjecting English language customers to cryptic C language comments while other language customers are free to receive helpful error messages. While some of the failures in our implementation are trivial because of uppercase-lowercase mismatch which we will not have problems changing, there are others which or of substantive nature since the C language comments in Appendix do not contain meaningful and useful error information. - This error message requirement is specified in terms of "language" whereas the practice in the industry for emitting error messages based on "locales". The localization and internationalization practices are specific to a locale and not instantiated based on "language" which can be ambiguous. In VST , the default userintf.c shipped picks C language locale and assumes it provides English language messages. This is not required by the specification. - While never recognized in the XTI specification, there are other issues that are related to the error messages. The t_errno namespace is also used by other specifications which have to be supported by vendors such as TLI interfaces and the Streams TPI message based interface (in the T_ERROR_ACK message). It is in fact evolved into a fairly generic transport protocol error namespace. It is therefore best to render these messages in terms of generic transport endpoints primitives which is another motivation to choose the text of the error messages to be generic. That is the motivation for a different error message string for TPROTO error in our implementation for instance (and some other error codes also). Since these error namespace can be in one common place in an implementation, the error messages that follow in comments tend to be generic in such implementations. - In the Posix draft specification, the error messages are not identical to what is in the C language comments in Appendix F. While they also refer the to the comments following the error codes defined in the xti.h, they are also subject to same interpretation. In their equivalent rendering of the comments, they have felt free to change the comments different from C language xti.h such as changes from "couldn't" to "could not" "ord rel" to orderly release" "discon ind" to "disconnect indication" etc. The test as written will make it impossible to match to those strings either. That should be a factor in not having this test assertion in its current form. Since the test suites requires specific error strings whose definitions is not clear in the specification, we request that these test cases be dropped from the branding requirements. Further information for consideration and request for appeal ------------------------------------------------------------ The consultant's initial response observes. "Because the specification cannot rely on the existence of comments in Appendix F provided by the implementation, the only logical conclusion is that it must refer to the sample header file provided in Appendix F" We would like to observe that since this is the ONLY exception to the practice of using the Appendix F cross reference in XTI interface manual pages, it also logical to conclude that it is a reference to the <xti.h> implementation, even though it is ambiguous enough to refer to Appendix F. The response further states "The commentary states that to be identical to the comment in Appendix F, the preceding /* and trailing */ need to be included. This would be a reasonable argument if this were the difference between between the system under test and the test requirements, but this is not the case and so this point has little merit for the case in question." The point of that argument was not a serious suggestion that "/*" and "*/" were implied. It was just to observe that an even more literal (and not practical) interpretation of the word "identical" is possible. We would like to be interpreted in a looser manner. The response further states "It is recognized that the system under test has not made significant variations in the meaning of error messages produced. However if a Permanent Interpretation is granted, this can be quoted by other system vendors to allow systems which make no attempt to provide reasonable error text in the English language" We would like to observe that while the concern about a Permanent Interpretation is valid, there are natural market pressures for vendors to not have unreasonable error messages. Even with this enforcement, there is nothing against unreasonable error messages from appearing on other languages, or even in C locale, so this does not accomplish much. We would also like to observe that the similar strerror() interface for "errno" variable also does not enforce these concerns. "There are clear deficiencies in the specification concerning the text being output in the English language and the point about the POSIX C locale is well made. However, the grant of a Permanent Interpretation seems too wide an option because of the latitude that it would provide to other system vendors. If the reasonable latitude is to be accepted, then the best option would be for the test to indicate a FIP result and for the results to be checked by the testing agency during the certification process." We notice that the consultant does agree that there are deficiencies in the specification. Therefore we do not understand a refusal and would have expected a change to require a FIP result but perhaps a formal request for that change is required. We would therefore like to explicitly request in this appeal that the tests require a FIP result and would request that this be classified as a test suite deficiency and tested instead as a FIP. We do realize the specification problems are a big contributing factor and it is not primarily only a test suite problem, but enforcing this in a manner that does not synchronize and interferes with the Internationalization framework from XBD is not in the best interest of the X/Open specifications interoperating and customers. If the result of the re-evaluation on appeal is still a refusal, only in that case we would like the request to be forwarded to the XNET specification working group for further consideration. Test Output /tset/XTI.os/util/error/T.error 3 Failed Test Information: with t_errno = 1, t_error("t_error arg") produced incorrect message Expected string "t_error arg: incorrect addr format\n" Actual string "t_error arg: Incorrect address format\n" with t_errno = 2, t_error("t_error arg") produced incorrect message Expected string "t_error arg: incorrect option format\n" Actual string "t_error arg: Incorrect options format\n" with t_errno = 3, t_error("t_error arg") produced incorrect message Expected string "t_error arg: incorrect permissions\n" Actual string "t_error arg: Illegal permissions\n" with t_errno = 4, t_error("t_error arg") produced incorrect message Expected string "t_error arg: illegal transport fd\n" Actual string "t_error arg: Illegal file descriptor\n" with t_errno = 5, t_error("t_error arg") produced incorrect message Expected string "t_error arg: couldn't allocate addr\n" Actual string "t_error arg: Couldn't allocate address\n" with t_errno = 6, t_error("t_error arg") produced incorrect message Expected string "t_error arg: out of state\n" Actual string "t_error arg: Routine will place interface out of state\n" with t_errno = 7, t_error("t_error arg") produced incorrect message Expected string "t_error arg: bad call sequence number\n" Actual string "t_error arg: Illegal called/calling sequence number\n" with t_errno = 9, t_error("t_error arg") produced incorrect message Expected string "t_error arg: event requires attention\n" Actual string "t_error arg: An event requires attention\n" with t_errno = 10, t_error("t_error arg") produced incorrect message Expected string "t_error arg: illegal amount of data\n" Actual string "t_error arg: Illegal amount of data\n" with t_errno = 11, t_error("t_error arg") produced incorrect message Expected string "t_error arg: buffer not large enough\n" Actual string "t_error arg: Buffer not large enough\n" with t_errno = 12, t_error("t_error arg") produced incorrect message Expected string "t_error arg: flow control\n" Actual string "t_error arg: Can't send message - (blocked)\n" with t_errno = 13, t_error("t_error arg") produced incorrect message Expected string "t_error arg: no data\n" Actual string "t_error arg: No message currently available\n" with t_errno = 14, t_error("t_error arg") produced incorrect message Expected string "t_error arg: discon_ind not found on queue\n" Actual string "t_error arg: Disconnect message not found\n" with t_errno = 15, t_error("t_error arg") produced incorrect message Expected string "t_error arg: unitdata error not found\n" Actual string "t_error arg: Unitdata error message not found\n" with t_errno = 16, t_error("t_error arg") produced incorrect message Expected string "t_error arg: bad flags\n" Actual string "t_error arg: Incorrect flags specified\n" with t_errno = 17, t_error("t_error arg") produced incorrect message Expected string "t_error arg: no ord rel found on queue\n" Actual string "t_error arg: Orderly release message not found\n" with t_errno = 18, t_error("t_error arg") produced incorrect message Expected string "t_error arg: primitive/action not supported\n" Actual string "t_error arg: Primitive not supported by provider\n" with t_errno = 19, t_error("t_error arg") produced incorrect message Expected string "t_error arg: state is in process of changing\n" Actual string "t_error arg: State is in process of changing\n" with t_errno = 20, t_error("t_error arg") produced incorrect message Expected string "t_error arg: unsupported struct-type requested\n" Actual string "t_error arg: Unsupported structure type requested\n" with t_errno = 21, t_error("t_error arg") produced incorrect message Expected string "t_error arg: invalid transport provider name\n" Actual string "t_error arg: Invalid transport provider name\n" with t_errno = 22, t_error("t_error arg") produced incorrect message Expected string "t_error arg: qlen is zero\n" Actual string "t_error arg: Listener queue length limit is zero\n" with t_errno = 23, t_error("t_error arg") produced incorrect message Expected string "t_error arg: address in use\n" Actual string "t_error arg: Transport address is in use\n" with t_errno = 24, t_error("t_error arg") produced incorrect message Expected string "t_error arg: outstanding connection indications\n" Actual string "t_error arg: Outstanding connection indications\n" with t_errno = 25, t_error("t_error arg") produced incorrect message Expected string "t_error arg: transport provider mismatch\n" Actual string "t_error arg: Listener-acceptor transport provider mismatch\n" with t_errno = 26, t_error("t_error arg") produced incorrect message Expected string "t_error arg: resfd specified to accept w/qlen >0\n" Actual string "t_error arg: Connection acceptor has listen queue length limit greater than zero\n" with t_errno = 27, t_error("t_error arg") produced incorrect message Expected string "t_error arg: resfd not bound to same addr as fd\n" Actual string "t_error arg: Connection acceptor-listener address not same but required by transport\n" with t_errno = 28, t_error("t_error arg") produced incorrect message Expected string "t_error arg: incoming connection queue full\n" Actual string "t_error arg: Incoming connection queue is full\n" with t_errno = 29, t_error("t_error arg") produced incorrect message Expected string "t_error arg: XTI protocol error\n" Actual string "t_error arg: Protocol error on transport primitive\n" /tset/XTI.os/util/strerror/T.strerror 2 Failed Test Information: t_strerror(1) returned incorrect string Expected string "incorrect addr format" Actual string "Incorrect address format" t_strerror(2) returned incorrect string Expected string "incorrect option format" Actual string "Incorrect options format" t_strerror(3) returned incorrect string Expected string "incorrect permissions" Actual string "Illegal permissions" t_strerror(4) returned incorrect string Expected string "illegal transport fd" Actual string "Illegal file descriptor" t_strerror(5) returned incorrect string Expected string "couldn't allocate addr" Actual string "Couldn't allocate address" t_strerror(6) returned incorrect string Expected string "out of state" Actual string "Routine will place interface out of state" t_strerror(7) returned incorrect string Expected string "bad call sequence number" Actual string "Illegal called/calling sequence number" t_strerror(9) returned incorrect string Expected string "event requires attention" Actual string "An event requires attention" t_strerror(10) returned incorrect string Expected string "illegal amount of data" Actual string "Illegal amount of data" t_strerror(11) returned incorrect string Expected string "buffer not large enough" Actual string "Buffer not large enough" t_strerror(12) returned incorrect string Expected string "flow control" Actual string "Can't send message - (blocked)" t_strerror(13) returned incorrect string Expected string "no data" Actual string "No message currently available" t_strerror(14) returned incorrect string Expected string "discon_ind not found on queue" Actual string "Disconnect message not found" t_strerror(15) returned incorrect string Expected string "unitdata error not found" Actual string "Unitdata error message not found" t_strerror(16) returned incorrect string Expected string "bad flags" Actual string "Incorrect flags specified" t_strerror(17) returned incorrect string Expected string "no ord rel found on queue" Actual string "Orderly release message not found" t_strerror(18) returned incorrect string Expected string "primitive/action not supported" Actual string "Primitive not supported by provider" t_strerror(19) returned incorrect string Expected string "state is in process of changing" Actual string "State is in process of changing" t_strerror(20) returned incorrect string Expected string "unsupported struct-type requested" Actual string "Unsupported structure type requested" t_strerror(21) returned incorrect string Expected string "invalid transport provider name" Actual string "Invalid transport provider name" t_strerror(22) returned incorrect string Expected string "qlen is zero" Actual string "Listener queue length limit is zero" t_strerror(23) returned incorrect string Expected string "address in use" Actual string "Transport address is in use" t_strerror(24) returned incorrect string Expected string "outstanding connection indications" Actual string "Outstanding connection indications" t_strerror(25) returned incorrect string Expected string "transport provider mismatch" Actual string "Listener-acceptor transport provider mismatch" t_strerror(26) returned incorrect string Expected string "resfd specified to accept w/qlen >0" Actual string "Connection acceptor has listen queue length limit greater than zero" t_strerror(27) returned incorrect string Expected string "resfd not bound to same addr as fd" Actual string "Connection acceptor-listener address not same but required by transport" t_strerror(28) returned incorrect string Expected string "incoming connection queue full" Actual string "Incoming connection queue is full" t_strerror(29) returned incorrect string Expected string "XTI protocol error" Actual string "Protocol error on transport primitive" Review Information Review Type TSMA Review Start Date null Completed null Status Complete Review Recommendation No Resolution Given Review Response It is believed that the rationale for the error message content in English is to ensure that a meaningful description is provided for each error condition. If the logic provided above is followed, then there is no requirement for an implementation to provide any text for error messages, since there is no requirement that the <xti.h> header file provided on an implementation should contain comments associated with the error conditions. Indeed, it is not even required that the header information is stored in an ASCII readable file. Because the specification cannot rely on the existence of comments in the <xti.h> provided by the implementation, the only logical conclusion is that it must refer to the sample header file provided in Appendix F. The commentary states that to be identical to the comment in Appendix F the preceding /* and trailing */ need to be included. This would be a reasonable argument if this were the difference between the system under test and the test requirements, but this is not the case and so this point has little merit for the case in question. It is recognized that the system under test has not made significant variations in the meaning of the error messages produced. However, if a Permanent Interpretation is granted, this can be quoted by other system vendors to allow systems which make no attempt to provide reasonable error text in the English language. There are clearly deficiencies in the specification concerning the text being output in the English language and the point about the POSIX C locale is well made. However, the grant of a Permanent Interpretation seems too wide an option because of the latitude that it would provide to other system vendors. If reasonable latitude is to be accepted, then the best option would be for the test to indicate a FIP result and for the results to be checked by the testing agency during the certification process. Review Type Expert Group Review Start Date null Completed null Status Complete Review Resolution No Resolution Given Review Conclusion It is not clear from the specification whether the comments that are to be re-produced in error messages are those in the specification or those in the implementor's header file. There are also other points (such as precisely which locales are in question) that are not entirely clear. In the opinion of the working group, these areas of the specification are sufficiently imprecise that it is not reasonable to require implementations to generate the text of the header file contained in the specification. Rather, there should be a check that the text generated is reasonable. The test suite, VST, will be changed so that in these circumstances a FIP result will be produced which can be inspected and signed off. A patch is being produced immediately so a TSD is considered unnecessary and therefore this request is refused. Review Type SA Review Start Date null Completed null Status Complete Review Resolution Rejected (REJ) Review Conclusion This request is refused. Problem Reporting System Options: View Report 2004 List All PRs Search Reports Email the System Administrator View the The Open Brand Interpretations Database User Manual
Contact the Certification Authority