HomeAbout Us A-Z IndexSearch * Contact Us Register LoginPress Shop

The Open Brand -- Problem Reporting and Interpretations System


Problem Report 0545 Details

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

This page provides all information on Problem Report 0545.


Report 0545 Actions


    Problem Report Number 0545
    Submitter's Classification Specification problem
    State Resolved
    Resolution Minor System Fault (MSF)
    Problem Resolution ID MSF.X.0036
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published 1995-10-13 08:00
    Expiry Date null
    Product Standard Commands and Utilities V2 (UNIX 95)
    Certification Program The Open Brand certification program
    Test Suite VSC version 4.1.4
    Test Identification POSIX.upe/uucp/uucp.ex 0
    Problem Summary MSF4C.00002 Uucp must be present for branding, but is only required to support a local connection.
    Problem Text
    We have received your refusal response to our waiver request for 'uucp'.

    Originator Reference: VSC1157
    X/Open Reference: req.4.C.00017
    Waiver Reason: Grey Area in the XPG

    We are now requesting an "anonymous review" of this waiver request.

    We believe that the Application Usage section for uucp, in the
    "X/Open CAE Specification (1994) Commands and Utilities Issue 4,
    Version 2", paragraph 3, sentence 2:

    "On systems where there are no available communications means
    (either temporarily or permanently), this utility will write
    an error message describing the problem and exit with a non-zero
    exit status."

    should be considered NORMATIVE text.

    There is no requirement in the Standard that a communications
    channel be available and no requirement for proper inter-
    operability with arbitrary XPG4 branded systems. There is no
    format specified for communications with a remote XPG4 branded
    system.

    In support of our belief that the presence of a communications
    channel in not mandated by the normative text of the
    specification, the change history for the UUCP command for Issue
    4 of XPG states that the "presence of the utility is mandated,
    even on systems where no communications are available." Although
    this text is most definitely not normative, it is a strong
    indication of the intent of the authors of the specification.
    Test Output
    X/Open Commands and Utilities, Issue 4, section 1.7.1, Codes states
    for code UN "Possibly unsupportable feature.
    It need not be possible to implement the required
    functionality (as defined) on all XSI-conformant systems
    and the functionality need not be present. This may, for
    example, be the case where the XSI-conformant system is
    hosted and the underlying system provides the service in
    an alternative way."

    The uucp utility, entire SYNOPSIS section, is marked with the UN code.
    However, this same utility is not listed in the Table of Possibly
    Unsupportable utilities in section 1.3.4. And, in the CHANGE HISTORY
    section of uucp, in the specification, under Issue 4, the last
    sentence states "Presence of the utility mandated, even on systems
    where no communications are available."
    Our implementation contains a binary for uucp but it is merely
    a stub and does not perform the uucp functionality.
    Instead we have implemented the behavior which is described
    under APPLICATION USAGE it states:
    ... "On systems where there are no available communications means
    (either temporarily or permanently), this utility will write
    an error message describing the problem and exit with a non-
    zero exit status."

    We believe that there is a contradiction in the standard because
    uuto is also "mandated" according to its CHANGE HISTORY and its
    SYNOPSIS is also marked with the UN code. HOWEVER, it IS listed in the
    Table of Possibly Unsupportable utilities. This makes it possible
    for the VSC4 test suite implementers to use a variable in the uuto
    test cases to identify those test cases as UNSUPPORTED rather
    than as FAIL, UNRESOLVED, or UNINITIATED. Without the table entry the
    test suite implementers cannot use the variable to specify
    the UNSUPPORTED code.
    uucp should be listed in the Table in section 1.3.4 allowing it to
    be UNSUPPORTED in test suite.

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    We recommend this request be refused.

    Our logic is as follows...

    The uucp utility, entire SYNOPSIS section, is marked with the UN code.

    The uucp utility is marked with both the UN and EX codes. We
    believe the entire synopsis is marked because of the EX code.
    Section 1.7.1 of the XCU spec states

    If an entire SYNOPSIS section is shaded and marked with one EX,
    all the functionality described in that entry is an extension.

    We believe the UN code refers to the several uucp options which are
    labeled as UNs. If the EX code were not present only these options
    would be marked in the SYNOPSIS.

    However, this same utility is not listed in the Table of Possibly
    Unsupportable utilities in section 1.3.4. And, in the CHANGE HISTORY
    section of uucp, in the specification, under Issue 4, the last
    sentence states "Presence of the utility mandated, even on systems
    where no communications are available."

    The fact that uucp is not listed in the table of possibly unsupported
    utilities supports our assertion. If the entire utility were unsupported
    it should be listed there. The CHANGE HISTORY is not a normative part
    of the spec (see below).

    under APPLICATION USAGE it states:
    ... "On systems where there are no available communications means
    (either temporarily or permanently), this utility will write
    an error message describing the problem and exit with a non-
    zero exit status."

    Although we can find no explicit statement anywhere in the spec. We
    believe through previous experience that the APPLICATION USAGE
    section, which this statement is quoted from, is not normative.
    It exists only to provide

    "advice to the application programmer about the way the
    utility should be used"

    We believe the APPLICATION USAGE paragraph quoted is advising
    programmers how to handle situations where no communication
    channels are configured on a machine, nothing more.

    Furthermore, we believe that all spec sections following APPLICATION
    USAGE are not normative either. This is the logic behind our
    deprecating the CHANGE HISTORY section reference above.

    Once we eliminate the non-normative portions of the spec from
    consideration there is no discrepency in the spec.

    uucp must be supported.

    The functionality mandated of the IUT can then be found in the
    uucp DESCRIPTION section, This states

    The uucp utility copies files named by the source- file arguments
    to the destination-file argument. The files named can be on
    local or remote systems.

    We believe this requires IUTs to provide a working uucp which
    supports both a local and a remote system communications means.

    We believe that there is a contradiction in the standard because
    uuto is also "mandated" according to its CHANGE HISTORY and its
    SYNOPSIS is also marked with the UN code. HOWEVER, it IS listed
    in the Table of Possibly Unsupportable utilities. This makes it
    possible for the VSC4 test suite implementers to use a variable
    in the uuto test cases to identify those test cases as
    UNSUPPORTED rather than as FAIL, UNRESOLVED, or UNINITIATED.
    Without the table entry the test suite implementers cannot use
    the variable to specify the UNSUPPORTED code.

    Once the CHANGE HISTORY is deprecated there is no discrepency. Both
    the Table of Possibly Unsupportable Utilities and the uuto spec
    are in agreement. uuto is Possibly Unsupportable.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    In an attempt to summarise, it looks as if we are agreeing that uucp
    may be legitimately be required to perform as specified purely on a
    local system. The implication is that they need not be required to operate
    on a remote system. This seems to be consistent with our failure to define
    any protocol for use by these commands.

    Based on this, the recommendation is that we grant a Temporary Waiver.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Minor System Fault (MSF)
    Review Conclusion
    A Temporary Waiver is granted.

    Problem Reporting System Options:

     

    Back   


Contact the Certification Authority