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

The Open Brand -- Problem Reporting and Interpretations System


Problem Report 2012 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 2012.


Report 2012 Actions


    Problem Report Number 2012
    Submitter's Classification Specification problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0244
    Raised 1998-03-18 08:00
    Updated 2003-03-13 08:00
    Published 1998-05-06 08:00
    Product Standard Transport Service XTI V2
    Certification Program The Open Brand certification program
    Test Suite VST version 5.2.3
    Test Identification unk/unk/xti.h unk
    Specification Networking Services Issue 5
    Location in Spec See Problem Text
    Problem Summary PINT5.001 We have a difference of interpretation of the following normative definition of legacy from XNS5 chapter 1 , section 1.1 Terminology: "legacy Certain features are legacy, which means that they are bei...
    Problem Text
    We have a difference of interpretation of the following normative
    definition of legacy from XNS5 chapter 1 , section 1.1 Terminology:

    "legacy

    Certain features are legacy, which means that they are being retained for
    compatibility with older applications, but have limitations which make them
    inappropriate for developing portable applications. New applications should use
    alternative means of obtaining equivalent functionality. Legacy features are
    marked LEGACY."

    This wording is also used in appendix F when describing the
    xti.h header contents.

    We interpret this wording to mean that the LEGACY symbols
    are "retained only when _XOPEN_SOURCE < 500". The test
    suite assumes they are also "retained when _XOPEN_SOURCE == 500".

    Can an application assume that the symbols in xti.h marked
    LEGACY are visible when _XOPEN_SOURCE == 500 ?

    Test Output
    Not applicable, this is a request for interpretation
    of the specification.

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    The suggested interpretation seems to conflict with the following text
    from section 1.3:

    "Applications should ensure that the feature test macro _XOPEN_SOURCE
    is defined with the value 500 before inclusion of any header. This
    is needed to enable the functionality described in this document"

    If the intention was for the legacy symbols not to be visible when
    _XOPEN_SOURCE is 500 then they should not appear in the spec at all.
    (At least not in the normative text; they could be mentioned in some
    historical commentary or advice to application writers.)

    If the legacy symbols are not required to be visible in <xti.h> on XNS5
    implementations this would create a major portability problem for XNS4
    applications to systems which only implement XNS5. There may not be any
    such systems initially, as XNS5 is presumably being implemented first on
    systems that already implement XNS4, but the problem should not be
    ignored just because it may be some time before it will be encountered.

    There is also the possibility that application writers may wish to update
    their XNS4 applications to take advantage of some features of XNS5 where
    they are available (e.g. the scatter-gather send/receive functions).
    In order to use these features the application would have to be compiled
    with _XOPEN_SOURCE=500. If this meant that the legacy symbols would no
    longer be visible in <xti.h>, then this would generate additional work to
    be done as part of the update that would otherwise be unnecessary.

    We believe the specification is clear that the legacy symbols must be
    visible in <xti.h> when _XOPEN_SOURCE is 500. However, since this issue
    is already the subject of debate on the XNET working group, this
    interpretation request should be forwarded to them for review.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This request should go for a 14 day review.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    RESOLUTION XNET53-1

    XNET has considered a number of issues relating to the behaviour
    of various headers under different values of _XOPEN_SOURCE.
    XNET resolves to produce detailed change requests in the form of
    corrigenda which will give effect to the following decisions in
    XNS Issue 5.

    1. Any text that relates to behaviour of the implementation
    when _XOPEN_SOURCE is less than 500 is informative, not normative.
    This behaviour is specified normatively in earlier issues of XNS.

    2. Conformant systems are not required to provide the OPT_NEXTHDR
    macro.

    3. Protocol-specific symbols defined in <xti_inet.h> or <xti_osi.h>
    are not required to be available when <xti.h> is included by the
    application but <xti_inet.h> or <xti_osi.h> (respectively) is not
    included by the application.
    :
    4. An implementation is only required to provide protocol-specific
    headers for those protocols that it supports.

    5. An implementation need not make available symbols marked in XNS5
    as "LEGACY".

    6. Although identifiers marked as "LEGACY" are not specified as
    being reserved for any use by the implementation, implementations
    may make them available.

    XNET is aware that this may mean that XNS5 applications will have to
    be changed if they are to remain portable, but XNET believes that
    few, if any, such applications have yet been written, that these
    changes are necessary, and that they should therefore be made now.

    In view of 4. and 5. above.

    A Permanent Interpretation is recommended.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Permanent Interpretation (PIN)
    Review Conclusion
    A Permanent Interpretation is granted.

    Problem Reporting System Options:

     

    Back   


Contact the Certification Authority