Corrigendum: U038
Date:
5 February 1999
Document: Networking Services (XNS), Issue 4
Open Group CAE Specification, 09/94, C438
Code: 02/99 C438/U038
Contents: This Corrigendum publishes new item:
U038/XNS4-999
and incorporates existing published Corrigenda:
U024:
U024/XNS-009
U024/XNS-010
U008:
U008/XNS-1.1
U008/XNS-1.2
U003:
U003/XTI-1.1
U003/XTI-1.2
U003/XTI-1.3
U003/XTI-1.4
U003/XTI-1.5
U003/XTI-1.6
U003/XTI-1.7
U003/XTI-1.8
U003/XTI-1.9
U003/XTI-1.10
U003/XTI-1.11
This Corrigendum therefore supersedes U024, U008 and U003.
Change Number: U038/XNS-999
Title: Clarify
usage of the long data types to enable systems simultaneously to conform
to XNS4 and XNS5
Qualifier: Major technical
Rationale: Add text clarifying the usage the long data types in a
way that will enable systems
simultaneously to conform to XNS4 and XNS5.
Change: Add a new Section 1.6 (on page 7)
To assist portability to 64-bit systems, all references in this specification
to the types long and unsigned long may be taken to refer to integral types
(signed and unsigned respectively) of at least 32 bits in length.
Corrigendum U024 (July 1997)
Change Number: U024/XNS-009
Title: In UNIX 95 XTI,
t_getprotaddr() legal states are incorrect for orderly release transports.
Qualifier: Major technical
Rationale: The current XTI t_getprotaddr() specification for UNIX 95 is
broken for transports
that support orderly release. It specifies that the peeraddr should not be returned except
in
T_DATAXFER states. However, such transports can function with half-open connections
indefinitely
in states T_INREL and T_OUTREL, and there needs to be a way to find out the remote
endpoint
address in these states.
This specific change is also aligned with the future direction taken by evolution of XTI
interface
specification in Networking Services Issue 5 (UNIX 98).
See also related CR XO-XNS-010, below.
Change:
Change the last sentence in the description fort_getprotoaddr() on Page 66, from
If the transport endpoint is not in T_DATAXFER state, zero is returned in the len field of
peeraddr.
to
If the transport endpoint is not in T_DATAXFER, T_INREL or T_OUTREL states,
zero is returned in the len field of peeraddr.
Change Number: U024/XNS-010
Title: In UNIX 95 XTI,
allow t_getprotaddr() in T_OUTCON state
Qualifier: Minor technical
Rationale: In the XTI specification for UNIX 95, t_getprotoaddr() is
limited to allowing the ability
to retrieve the remote address in only the T_DATAXFER state.
The first change in this Corrigendum addresses also allowing this in T_INCON and T_OUTCON
states.
This change (XO-XNS-010) adds allowing it in T_OUTCON state, because there is no reason
to restrict it (since while the association is not established in this state, nevertheless
the address
of the remote endpoint to which connection request is made is known to the interface).
This specific change is also aligned with the future direction taken by evolution of XTI
interface
specification in Networking Services Issue 5 (UNIX 98).
Change: In the last sentence in the description fort_getprotoaddr() on
Page 66, add T_OUTCON
as one of the states where zero is not required to be returned in the len field of
peeraddr (alongside
T_INREL and T_OUTREL, as prescribed by change XO-XNS-009 of this Corrigendum).
===========================================================================
Corrigendum U008 (May 1995)
Change number: U008/XNS-1.1
Title: X/Open Networking Services Issue 4, X/Open CAE Specification,
09/94, C438:
XTI headers and definitions <xti.h> binary values.
Qualifier: Major Technical
Rationale: The <xti.h> header file specifies binary values for
symbolic constants. It also includes
protocol specific symbolicconstants. Some of these constants defined values can conflict
with
values already defined on a vendors platform in other header files and can therefore cause
name space
and binary compatibility problems. This is manifest by XTI as part of the Single UNIX
specification.
The XNET-36 meeting addressed this problem as a matter of urgency, with the aim of
recommending
a solution which would avoid delaying development of the Single UNIX test suite. Leaving
aside
considerations of binary portability, and also argument over how it came about that the
developers
of the earlier XTI specification came to specify binary values in the first place, the
arguments for the two
opposing positions expressed during XNET-36 (on the numerical values assigned to symbolic
constants in the XPG4 <xti.h> file) were:
XNET-36 captured its majority position in Resolution 36-8:
"XNET recommends that regarding the mandatory character of the current XTI header
definition, specifically the binary values specified therein, the values as specified in the list
to be agreed should not be mandatory for the purposes of the UNIX brand, while they
should remain mandatory for branding in other environments."
In recommending this solution, XNET recognised it was proposing introducing a slight
difference
in the meaning of the XTI brand obtained for Single UNIX and that obtained for other
environments:
existing and new XTI applications written for non-UNIX environments will not be fully
portable
to the Single UNIX environment (there is no problem in the opposite direction).
Regarding the scale and context of this problem, it is important to note that only
applications relying
on specific numerical values of the symbolic constants would have to be modified when
ported to XTI implementations providing different values. Of course, the purpose of
symbolic constants is to
remove numerical values from programs, and textbooks on programming generally advise
against
a style making programs dependent on numerical values. It is therefore to be hoped that
the problem
is limited to only a rather small number of applications written in questionable style,
and therefore
in practice this should not be a major technical issue.
The whole matter is significant because of its branding implications. The compromise
expressed
in XNET resolution 36-8, namely a single XTI brand with different conformance requirements
in UNIX and XPG4 environments, proved not acceptable.
As a result, X/Open proposed that the Appendix on the XTI header file is modified so that
some
or all of the values included therein are declared as "recommended but not
mandatory" for
compliance with the XTI specification. In a preliminary poll of XNET representatives, this
solution
was accepted, with a slight preference for making "recommended but not
mandatory" only those
values which cause contention.
The change proposed here does this. If accepted, it will be issued as a Corrigendum to
ensure
immediate effect.
Change: In the Networking Services Issue 4 CAE Specification, Appendix F:
Headers and
Definitions for XTI:
Values specified for some of the symbolic constants in this XTI header definition
are designated as not mandatory for conformance purposes. These are identified
by the comment
/* value is recommended only, not mandatory */
on the same line as that constant.
Change number: U008/XNS-1.2
Title: Conformance Statement Questionnaire (CSQ)
for the XPG4 Transport Service (XTI)
component Version 2: new question on whether recommended header values are used.
Qualifier: Major Technical
Rationale: Change XNS-1.1 in this Corrigendum gives the rationale and
detailed change
information for changing certain XTI header values from mandatory to recommended.
Consequent on change XNS-1.1, it is valuable to add a further question to the XTI
component
CSQ to ask whether the recommended values have been implemented or not. This CR proposes
adding that question.
Change: In the Conformance Statement Questionnaire (CSQ) for the XPG4
Transport Service
(XTI) component Version 2, add a further question to the end of the CSQ, after
"Optional
Support for Protocols or Protocol Profiles", formulated in the following style to
conform
to the CSQ format:
.H 2 "Recommended XTI Header Values Implemented"
\f4Question 13: Does your implementation use all the
recommended values identified in the XTI specification
as "recommended only, not mandatory for conformance"?\fP
.DS I
.\" ANSWER "YES" OR "NO" ON THE LINE BELOW
Yes/No
.DE
.DS I F
If "No", list all those which deviate from the
recommended values. If necessary, use a separate sheet.
.\" LIST ALL THOSE WHICH ARE DIFFERENT, AND GIVE THE
.\" ACTUAL VALUE USED.
Rationale:
.DE
.DS I F
An XTI transport provider does not have to implement
these recommended values in order to be compliant.
However, it is valuable to know this so that users
can easily check whether an XTI application which
relies on these values will be portable to this XTI
implementation: if the answer is "Yes" then such
an XTI application will be portable to this
implementation; if "No" then it will not.
.DE
.P
Reference:
.DS I F
X/Open Corrigendum U008 to Networking Services Issue 4
(X/Open Document Number C438). This Corrigendum revises
Networking Services Appendix F "XTI Headers and
Definitions" to define certain values assigned to
constants as "recommended, not mandatory."
.DE
=============================================================================
Corrigendum U003 (June 1994)
Change number: U003/XTI-1.1
Title: t_accept() address binding for resfd in state T_IDLE
Qualifier: Major Technical
Rationale: Although some transport implementations (e.g., ISO)
support multiple endpoints binding to the same protocol
address, most TCP implementations do not. This
limitation has led to the following widespread practice.
A user calls t_bind() to bind resfd to an arbitrary
port on the local host, then calls t_accept() (with
fd != resfd) which binds resfd the same address as fd.
For resfd, a change of address takes place. Thus this
behavior is called "the magic address switch".
Appendix B.3, t_accept(), second paragraph, second
sentence, states that "Also, resfd must be bound to the
same address as fd." This requirement is not true for
most TCP implementations. Moreover, this requirement
makes the implementation of a compliant XTI interface
over these TCP providers very difficult, if not
impossible. Finally, the current practice based on the
magic address switch works and applications are using
it.
In order to allow implementations that perform the magic
address switch to comply with XTI, the following change
is needed.
Change: In Appendix B section B.3 (page 113), t_accept(), second
paragraph:
Remove second sentence:
"Also, resfd must be bound to the same address as fd."
Add the following text at the end of the same paragraph:
"If such a restriction exists, a user has the
following alternatives for accepting a connection
on a different endpoint (resfd != fd): (1) call
t_accept() while resfd is in state T_UNBND; or
(2) bind to an arbitrary unused local address,
and then call t_accept() in the T_IDLE state. In
the second case, t_accept() will change the resfd
address to be the same as that of fd. For
portability, the first alternative is recommended.
On page 113, t_bind(), second paragraph change the
beginning of the first sentence from:
"In connection-oriented mode, ..."
to:
"In some implementations, in connection-oriented
mode,..."
Branding: Branding should require that a vendor state if multiple
binds of an endpoint to the same address are allowed,
and if not, whether the implementation performs the
magic address during t_accept().
Testing: An XTI implementation can and should be tested for
allowing multiple binds of an endpoint to the same
address and for performing the magic address switch.
Change number: U003/XTI-1.2
Title: Add t_close() semantics to appendix C.4.
Qualifier: Major Technical
Rationale: Appendix C of the XTI spec. needs to be modified
to alert application writers they can not always
depend on the behavior of the t_close().
Change: At the end of Appendix C section C.4, add the following
text:
11. The semantics of closing a connection may be
different across transport providers. For example,
closing a connection to ISO is abortive while
closing a connection to TCP is orderly. A portable
application should not assume either facility is
available. If the service provider is of type
COTS_ORD, a portable application should use the
t_sndrel()/t_rcvrel() prior to calling t_close().
Change number: U003/XTI-1.3
Title: Add t_close() semantics to Appendix B.
Qualifier: Major Technical
Rationale: Appendix B of the XTI spec. needs to clarify Internet
transport protocol TCP action on t_close().
Change: Insert the following text in the alphabetically
appropriate place in Section "B.3 Functions" (after
t_bind() description and before t_connect() description):
t_close()
The t_close() call will result in close() call to be made
on the descriptor of this XTI communication endpoint.
If there are no other descriptors in this process or any
other process which reference this communication endpoint,
the close() call will perform an orderly connection
termination according to the rules of a TCP CLOSE call on
this connection endpoint as specified in standards RFC 793
and RFC 1122. If the XTI_LINGER option is supported and is
used to enable the linger option, the linger time will
affect the time an implementation lingers in the
execution of t_close() or close(). A linger time of 0
specified with XTI_LINGER option may cause an abortive
release of a TCP connection resulting in lost data.
Change number: U003/XTI-1.4
Title: Add t_close() semantics to Appendix A.
Qualifier: Major Technical
Rationale: Appendix A of the XTI spec. needs to clarify ISO transport
protocol action on t_close(); this clarification needs
to take into account that:
1. ISO transport does not support the orderly release
function.
2. without orderly release, the XTI_LINGER option has no
meaning for an ISO transport provider.
Change: Insert the following text in the alphabetically
appropriate place in Section "A.3 Functions" (after
t_bind() description and before t_connect() description):
t_close()
The t_close() call will cause a close() call to be made
on the descriptor of this XTI communication endpoint.
If there are no other descriptors in this process or any
other process which reference this communication
endpoint, the close() call will perform an abortive
release on any connection associated with this endpoint.
Change number: U003/XTI-1.5
Title: Add t_close() semantics to Appendix I.
Qualifier: Major Technical
Rationale: Change the semantics of mapping a t_close() to being
an orderly close. t_close() can map to the close
semantics of the underlying provider. Since SNA provides
an orderly close, and since mapping to an orderly close
makes it easier to map XTI applications to an SNA
transport, mapping t_close() to an orderly SNA close
makes more sense.
Appendix I of the XTI Specification needs to be modified
to alert application writers of the t_close() semantics
for the SNA Transport Provider.
Change 1. Replace section I.2.1, item 6 "Orderly release",
with the following text:
"6. t_close()
The semantics of t_close() on an SNA Transport
Provider is simplex orderly, that is, the send
pipe of the XTI application issuing the
t_close() is closed, but the receive pipe
remains open. Any data sent prior to the
t_close() will be delivered to the partner."
2. In table I-5, page 216, t_close() entry:
- Replace "DEALLOCATE TYPE(ABEND)"
with "DEALLOCATE TYPE(FLUSH)"
- Remove sentence that says "May be a delay if
XTI_LINGER ooption activated with non-zero
linger value."
3. In table I-9, page 221, change "TYPE(ABEND_PROG)"
to "TYPE(FLUSH)"
Change number: U003/XTI-1.6
Title: RT_UNUSED not used. so delete its definition.
Qualifier: Minor Technical
Rationale: With regard to the "General purpose defines",
T_UNUSED
is not used elsewhere in the document.
Change: In Appendix F page 164, remove its definition.
Change number: U003/XTI-1.7
Title: Zero value of maxlen
Qualifier: Minor Technical
Rationale: With regard to the sentence "If maxlen is not large
enough to hold the returned address, an error will result"
in the description of t_bind() on page 54, and to similar
text in the descriptions of functions t_connect(),
t_getprotaddr(), t_listen(), t_rcvconnect(), t_optmgmt(),
t_rcvdis(), t_rcvudata(), t_rcvuderr(): if the maxlen
value of an output parameter is too small, the function
fails with [TBUFOVFLW] only if maxlen > 0, but not if
maxlen=0 (see the description for [TBUFOVFLW] in the
Errors section. The idea was that a user is allowed to
selectively discard output information by setting the
maxlen field of the appropriate output parameter to zero.
(Setting the complete output structure to NULL would
result in a total information loss.) Unfortunately,
the behaviour of the call in case that maxlen = 0 was
only implicitly described in the decription of [TBUFOVFLW].
This change removes conflicting statements from the XTI
specification. Applications and implementations that
follow the descriptions of the TBUFOVFLW error will be
unaffected by this change. Applications and implementations
that follow the function descriptions could be affected.
There could be implications for testing and branding
if the test suite follows the function descriptions rather
than the TBUFOVFLW error descriptions.
Change: 1. In the description of t_bind(), replace the sentence
"If maxlen is not ..."
by
"If maxlen equals zero, no address is returned. If
maxlen is greater than zero and less than the length
of the address, t_bind() fails."
2. In the description of t_connect(), replace
"However, rcvcall may be a null . . t_connect()"
by
"However, maxlen can be set to zero, in which case no
information to this specific argument is given to
the user on the return from t_connect(). If rcvcall
is set to NULL, no information at all is returned."
3. At the end of the description of t_getprotaddr(),
add "If the maxlen field of boundaddr
or peeraddr is set to zero, no address is returned."
4. In the description of t_listen(), after " . . maximum
size of the buffer for each" (page 71), add "If the
maxlen field of call->addr, call->opt, or call->udata
is set to zero, no information is returned for this
parameter."
5. In the description of t_optmgmt(), after the sentence
ending ".. options are to be placed." add
the sentence: "If maxlen in ret is set to zero, no
options values are returned.".
6. In the description of t_rcvconnect(),
replace the sentence "However, call may be a null
pointer,.." by "However, maxlen can be set to zero,
in which case no information to this specific argument
is given to the user on the return from t_rcvconnect().
If call is set to NULL, no information at all is
returned.".
7. In the description of t_rcvdis(), replace
the sentence "If a user does not care..." by "The
maxlen field of udata may be set to zero, if the user
does not care about incoming data. If, in addition,
the user does not need to know the value of reason
or sequence, discon may be set to NULL and any user
data associated with the disconnect indication shall
be discarded."
8. In the descriptions of t_rcvudata() (page 92) and
rcvvudata() (TBA), after " . . maximum size of the
buffer for each", add "If the maxlen field of addr
or opt is set to zero, no information is returned
in the buf field of this parameter."
9. In the description of t_rcvuderr(), after
" . . maximum size of the buffer for each" (page 92),
add "If this field is set to zero for addr or opt,
no information is returned in the buf field of this
Change number: U003/XTI-1.8
Title: System error on t_close()
Qualifier: Minor Technical
Rationale: t_close is eventually mapped to close(). A close could
fail with EINTR. Consequently, one should allow for a
system error.
Change: Add
"[TSYSERR] A system error has occurred during execution
of this function."
to the list of errors of t_close() on page 48.
Change number: U003/XTI-1.9
Title: TOUTSTATE and t_optmgmt()
Qualifier: Minor Technical
Rationale: t_optmgmt() is valid in all states and so cannot generate
[TOUTSTATE].
Change: Remove the TOUTSTATE entry from the list of ERRORS for
t_optmgmt() on page 73.
Change number: U003/XTI-1.10
Title: TACCes and t_optmgmt()
Qualifier: Minor Technical
Rationale: The description for the T_NEGOTIATE flag on page 69 says
that the status T_NOTSUPPORT is returned is the status
field, if the user attempts to negotiate a privileged
option. Thus, [TACCES] can not be generated by t_optmgmt().
This change should not affect existing applications (if
there are any that test for return of TACCES by
t_optmgmt(), then they can continue to do so, but the
test will of course always fail). It will only affect
implementations if there are any that actually generate
TACCES from t_optmgmt(). Similarly, it will not affect
the test suite unless this actually tests that TACCES
is returned by t_optmgmt() under certain conditions
(in which case, it would be interesting to know what
those condidtions are).
Change: Remove [TACCES] from the list on page 73.
Change number: U003/XTI-1.11
Title: Expedited data and RFC 1006
Qualifier: Minor Technical
Rationale: This text is not in the XTI CAE Specification, but is
probably intended to be added in order to describe support
for RFC 1006. In the text in the table in Appendix A
section A.3 on page 105, for "ISO over TCP", it should
be made clear that the value of info->etsdu depends on
the negotiation of expedited data transfer.
As this relates to a possible future change, rather to the
existing specification, there is no effect on existing
applications or implementations, or on testing or branding.
Change: Ensure that the relevant entry is annotated "(3)" when
describing support for RFC 1006.