Minimum OSI Functionality (CAE Specification)

General

Rationale for using XTI-mOSI

XTI-mOSI is designed specifically for Basic Communication Applications that are in one of these categories:

• applications that are to be migrated from the Internet world (TCP or UDP) or from a NetBIOS environment to OSI

• applications accessing the OSI transport service that wish to migrate to an OSI seven-layer, conformant environment

• applications that require a simple octet-stream connection between peer processes. The benefit of XTI-mOSI to these applications is that it extends the family of transport services that are available via a single, protocol independent, API.

Migrant Applications

In addition to applications already using XTI, the X Window System (X) and Internet Protocol Suite applications (in general) are examples of potential Migrant applications.

OSI Functionality

• ACSE Kernel functional unit

• Presentation Kernel functional unit

• Session Kernel and Full Duplex functional units.

The XTI-mOSI interface provides access to OSI ACSE and Presentation services. With mOSI, the optional parameters available to the application have been selected with the intent of facilitating interoperability and diagnostic of problems. They are described later in this section.

Most applications only need the Kernel functionality. This is even true for most of the OSI standard applications: Remote Database Access (RDA), Directory (X.500), FTAM without recovery, OSI Distributed Transaction Processing (TP) without 2-phase commitment, OSI Management.

mOSI API versus XAP

XTI-mOSI has been developed to support migrant transport applications, and also applications which require a simple octet stream connection between peers.

Application designers should consider which API is most appropriate to their needs.

Applications which are being ported from other transport providers, or require a simple octet string connection, should use XTI-mOSI.

Applications which require session function units outside kernel, or which require multiple presentation contexts, or which may require additional session/presentation by mOSI in the future, should use XAP.

When only minimal OSI support is required, the user should consider the availability of XTI-mOSI and XAP on target hardware platforms when selecting an interface.

Upper Layers Functionality Exposed via mOSI

Naming and Addressing Information used by mOSI

The address part is a Presentation Address. The calling and called addresses are required parameters, while the use of a responding address is optional.

The name part (Application Process (AP) Title, Application Entity (AE) Qualifier and the AP and AE invocation-identifiers) is always optional.

ISO Directory facilities, when available, can relate the name parts (identifying specific applications) to the addresses of the real locations where they can be accessed.

The general format of the addr structure can be found in Option Data Types and Structures , while its precise structure is implementation dependent.

XTI Options Specific to mOSI

• Application Context Name

  An application context name identifies a set of tasks to be performed by an application. It is exchanged during association establishment with the purpose of conveying a common understanding of the work to be done.

  This parameter is exposed to offer some negotiation capabilities to the application and to increase the chances of interoperability.

  When receiving a non suitable or unknown value from a peer application, the application may propose an alternate value or decide to terminate prematurely the association.

  A default value (in the form of an Object Identifier) is provided, identifying a generic XTI-mOSI application. Its value can be found in Option Data Types and Structures .

• Presentation Contexts

  A presentation context is the association of an abstract syntax with a transfer syntax. The presentation context is used by the application to identify how the data is structured and by the OSI Application Layer to identify how the data should be encoded/decoded.

  A generic presentation context is defined for a stream-oriented, unstructured, data transfer service with null encoding:

  abstract syntax: The single data type of this abstract syntax is a sequence of octets that are defined in the application protocol specification as being consecutive octets on a stream-oriented transport mechanism, without regard for any semantic or other boundaries.

  transfer syntax: The data value shall be represented as an octet-aligned presentation data value. If two or more data values are concatenated together they are considered to be a single (longer) data value. (This is the null encoding rule).

  The value of the Object Identifiers for this generic presentation context can be found in Option Data Types and Structures .

• Presentation Context Definition and Result List, Defined Context Set

  As negotiation occurs between the peer OSI Application layers, the presentation context(s) proposed by the application may not be accepted.

  The Presentation Context Definition and Result List indicates, for each of the proposed presentation context, if it is accepted or, if not, provides a reason code; the application may choose to terminate the association prematurely if it does not suit its requirements.

Options

An explanation of when an application may benefit from using the XTI options specific to mOSI can be found in General .

ACSE/Presentation Connection-mode Service

All options have end-to-end significance (see The Use of Options in XTI . They may be negotiated in the XTI states T_IDLE and T_INCON, and are read-only in all other states except T_UNINIT. The structures referenced are specified in Option Data Types and Structures .

Further Remarks

• Application Context Name

  A default value (for a generic XTI-mOSI application) is provided. It is defined in Option Data Types and Structures .

  The application may choose to propose, through this option, a value different from the default one. The application may also use this option to check the value returned by the peer application and decide if the association should be kept or terminated.

• Presentation Context Definition and Result List

  A default is provided: a list with one presentation context (the stream oriented, unstructured, data transfer service with null encoding - this is described in section General . The abstract syntax is the default abstract syntax and the transfer syntax is the default transfer syntax, as specified in Option Data Types and Structures .

  The codes for the result of negotiation and reason for rejection are defined in Option Data Types and Structures . The responding application, after reading this option, may choose to continue or terminate the association.

  Only a single abstract syntax and transfer syntax can be used by XTI-mOSI. On t_accept(), this is assumed to be the first usable abstract syntax and the first transfer syntax for that abstract syntax.

Negotiation of Abstract and Transfer Syntax

If the connection is accepted, the Presentation Context Definition and Result List is updated to reflect the results of negotiation for each element of the context list, and a single presentation context is selected.

Note:

If the responder accepts multiple presentation contexts, the XTI-mOSI provider aborts the connection on receipt of the A-ASSOCIATE confirm.

When responding to a remote connect, the application can specifically mark presentation contexts as rejected using the res field, and can re-order the syntax array to select a single transfer syntax.

On calling t_accept(), the first presentation context marked as accepted is selected, and all other contexts omitted or not marked rejected-user are marked as by the provider as rejected (T_PCL_PREJ_LMT_DCS_EXCEED). In an accepted context, the provider will accept the first (or only remaining) transfer syntax.

Note:

On return to the application from t_listen(), all supportable presentation contexts are marked as accepted in the T_AP_PCL option, and all unsupportable contexts are marked as rejected-provider. This permits the application to return the same option value on t_accept() (or leave it unchanged) to select the first available abstract syntax and transfer syntax.

Management Options

No management options are defined.

ACSE/Presentation Connectionless-mode Service

All options have end-to-end significance (see The Use of Options in XTI ). They may be negotiated in all XTI states except T_UNINIT. The structures referenced are specified in Option Data Types and Structures .

Further Remarks

• Application Context Name

  A default value (for a generic XTI-mOSI application) is provided. It is defined in Option Data Types and Structures .

  The application may choose to propose, through this option, a value different from the default one. The application may also use this option to check the value returned by the peer application and decide if the datagram should be kept or discarded.

• Presentation Context Definition and Result List

  In connectionless mode, the transfer syntaxes are not negotiated. Their use is determined by the sending application entity, and must be acceptable by the receiving application entity. A default value is provided by XTI: a list with one element, the generic presentation context (the stream-oriented, unstructured, data transfer service with null encoding described in General ). The corresponding abstract and transfer syntaxes are specified in Option Data Types and Structures .

  Only a single abstract syntax and transfer syntax can be used by connectionless-mode XTI-mOSI. If more than one presentation context is present in the options list for t_sndudata(), the first is used.

Management Options

No management options are defined.

Transport Service Options

These Options are defined in Options for Quality of Service and Expedited Data and Options for Quality of Service . The Quality of Service parameters are passed directly by the OSI Upper Layers to the Transport Layer. These options can thus be used to specify OSI Upper Layers quality of service parameters via XTI.

This facility is implementation dependent. An attempt to specify an unsupported option will return with the status field set to T_NOTSUPPORT.

None of these options are available with an ISO-over-TCP transport provider.

Functions

t_accept()

If fd is not equal to resfd, resfd should either be in state T_UNBND or be in state T_IDLE with the qlen parameter set to 0.

The addr parameter passed to/returned from t_bind() when resfd is bound may be different from the addr parameter corresponding to fd.

The opt parameter may be used to change the Application Context Name received.

t_alloc()

No special considerations for mOSI providers.

t_bind()

The addr field of the t_bind structure represents the local presentation address and optionally the local AP Title, AE Qualifier, AP and AE invocation-identifiers (see General and Option Data Types and Structures for more details).

This local addr field is used, depending on the XTI primitive, as the calling, called or responding address, the called address being different from the responding address only when two different file descriptors (fd, resfd), bound to different addresses, are used.

t_close()

Any connections that are still active at the endpoint are abnormally terminated. The peer applications will be informed of the disconnection by a [T_DISCONNECT] event. The value of the disconnection reason will be T_AC_ABRT_NSPEC.

t_connect()

The sndcall->addr structure specifies the Called Presentation Address. The rcvcall->addr structure specifies the Responding Presentation Address. The structure may also be used to assign values for the Called AP Title, Called AE Qualifier, Called AP invocation-identifier and Called AE invocation-identifier.

Before the call, the sndcall->opt structure may be used to request an Application Context name or Presentation Context different from the default value.

t_error()

No special considerations for mOSI providers.

t_free()

No special considerations for mOSI providers.

t_getinfo()

The information supported by t_getinfo() reflects the characteristics of the transport connection, or if no connection is established, the default characteristics of the underlying OSI layers. In all possible states except T_DATAXFER, the function t_getinfo() returns in the parameter info the same information as was returned by t_open(). In state T_DATAXFER, however, the information returned in info->connect and info->discon may differ.

---

The parameters of the t_getinfo() function are summarised in the table below.

Parameters	Before call	After call
		_
		Connection-mode	Connectionless-mode
fd	x	/	/
info->addr	/	x	x
info->options	/	x	x
info->tsdu	/	T_INFINITE (-1)	T_INFINITE (-1)
info->etsdu	/	(T_INVALID (-2)	T_INVALID (-2)
info->connect	/	x	T_INVALID (-2)
info->discon	/	x	T_INVALID (-2)
info->servtype	/	T_COTS_ORD	T_CLTS
info->flags	/	0	0

x equals an integral number greater than 0.

The values of the parameters in the t_info structure for the t_getinfo() function reflect the mOSI provider particularities.

• connect, discon

  The values returned in info->connect and info->discon in state T_DATAXFER may differ from the values returned by t_open(): negotiation takes place during association establishment and, as a result, these values may be reduced. For info->connect, this change of value may be indicated by the provider, but is of little use to the application.

• flags

  mOSI does not support sending of TSDU of zero length, so this value equals 0.

t_getprotaddr()

The protocol addresses are naming and addressing parameters as defined in General and Option Data Types and Structures .

t_getstate()

No special considerations for mOSI providers.

t_listen()

The call->addr structure contains the remote Calling Presentation Address and the remote Calling AP Title, AE Qualifier, and AP and AE invocation identifiers if received.

Incoming user data encoded as multiple presentation data values will cause the TBADDATA error to be returned.

t_look()

Since expedited data is not supported for a mOSI provider, T_EXDATA and T_GOEXDATA events cannot occur.

t_open()

t_open() is called as the first step in the initialisation of a transport endpoint. This function returns various default characteristics of the underlying OSI layers.

---

The parameters of the t_open() function are summarised in the table below.

Parameters	Before call	After call
		_
		Connection-mode	Connectionless-mode
name	x	/	/
oflag		/	/
info->addr	/	x	x
info->options	/	x	x
info->tsdu	/	T_INFINITE (-1)	T_INFINITE (-1)
info->etsdu	/	T_INVALID (-2)	T_INVALID (-2)
info->connect	/	x	T_INVALID (-2)
info->discon	/	x	T_INVALID (-2)
info->servtype	/	T_COTS_ORD	T_CLTS
info->flags	/	0	0

x equals an integral number greater than 0.

The values of the parameters in the t_info structure reflect mOSI limitations as follows:

• connect, discon

  These values are limited by the version of the session supported by the mOSI provider, and are generally much larger than those supported by an ISO Transport or TCP provider.

• flags

  mOSI does not support sending of TSDU of zero length, so this value equals 0.

Note:

The name (device file) parameter passed to t_open() will differ when the application accesses an mOSI provider or an ISO Transport provider.

t_optmgt()

The options available with mOSI providers are described in section Options .

t_rcv()

The flags parameter will never be set to [T_EXPEDITED], as expedited data transfer is not supported.

t_rcvconnect()

The call->addr structure specifies the remote Responding Presentation Address, and the remote responding AP Title, AE Qualifier, and AP and AE invocation identifiers if received.

The call->opt structure may also contain an Application Context Name and/or Presentation Context Definition Result List.

t_rcvdis()

Possible values for disconnection reason codes are specified in Option Data Types and Structures .

t_rcvrel()

With this primitive, user data cannot be received on normal release: any user data in the received flow is discarded (see t_rcvreldata ).

t_rcvudata()

The unitdata->addr structure specifies the remote Presentation address, and optionally the remote AP Title, AE Qualifier, AP and AE invocation-identifiers. If the T_MORE flag is set, an additional t_rcvudata() call is needed to retrieve the entire A-UNIT-DATA service unit. Only normal data is returned via the t_rcvudata() call.

t_rcvuderr()

This function is not supported by a mOSI provider since badly formed A-UNIT-DATA APDUs are discarded.

t_snd()

Zero-length TSDUs are not supported.

Since expedited data transfer is not supported for a mOSI provider, the parameter flags shall not have [T_EXPEDITED] set.

t_snddis()

No special considerations for mOSI providers.

t_sndrel()

With this primitive, user data cannot be sent on normal release (see t_sndreldata ).

t_sndudata()

The unitdata->addr structure specifies the remote Presentation address, and optionally the remote AP Title, AE Qualifier, AP and AE invocation-identifiers. Only normal data is sent via the t_sndudata() call.

t_strerror()

No special considerations for mOSI providers.

t_sync()

No special considerations for mOSI providers.

t_unbind()

No special considerations for mOSI providers.

Implementors Notes

Upper Layers FUs, Versions and Protocol Mechanisms

Session:

Kernel, Full Duplex, version 2, or version 1 if version 2 not supported, no segmentation.

Other session protocol mechanisms are out of scope, except Basic Concatenation which is mandatory and transparent to the application.

Presentation:

Kernel, Normal Mode

ACSE:

Kernel

If invalid (non-negotiable) options are requested by the peer and detected by the provider once the association is already established (such as the ACSE presentation context missing in the Defined Context Set), the association is rejected via an A-(P)-ABORT generated by the implementation.

Mandatory and Optional Parameters

• If the Local Presentation Address is not passed to t_bind() in req->addr, then it is returned in ret->addr.

• The remote (called) Presentation Address (in t_connect(), sndcall->addr) parameter must be explicitly set by the application.

• The following parameters are mandatory for the protocol machine, but default values are provided. If the application does not wish to set the corresponding parameter, the default value will be used. The default value may be changed through t_optmgt (see Options ):

  • Application Context Name (opt parameter)

  • Presentation Context List (opt parameter).

    The presentation context of ACSE is required and used. The user should not request it as the implementation will insert it automatically in the context list.

    If the user does not specifically request an Application Context name via the opt parameter of t_accept() (that is, for the A-Associate response), the implementation uses the Application Context name that was received in the A-Associate indication.

• The following parameters are optional for the protocol and default values of null are defined. If the application does not set them otherwise, they are omitted from the outgoing protocol stream.

  • local AP-title (in t_bind(), req->addr)

  • called AP-title (in t_connect(), sndcall->addr)

  • responding AP-title (if t_accept() specifies a new accepting endpoint resfd, in the protocol address bound to resfd)

  • local AE-qualifier (in t_bind)(), req->addr)

  • called AE-qualifier (in t_connect(), sndcall->addr)

  • responding AE-qualifier (if t_accept() specifies a new accepting endpoint resfd, in the protocol address bound to resfd).

  • local AP and AE invocation-identifiers (in t_bind(), req->addr)

  • called AP and AE invocation-identifiers (in t_connect(), sndcall->addr)

  • responding AP and AE invocation-identifiers (if t_accept() specifies a new accepting endpoint resfd, in the protocol address bound to resfd).

• The following parameters are optional for the protocol machine and not supported through the XTI interface. Their handling is implementation-defined. Received values in the incoming protocol stream, if any, are discarded:

  • ACSE Protocol Version (default= version 1)

  • Presentation Protocol Version (default= version 1)

  • ACSE Implementation Information

  • Session connection identifiers.

  During association establishment (that is, before the XTI-mOSI provider negotiates acceptance of a single abstract syntax/transfer syntax pair), an XTI-mOSI application initiating the association will only send a single presentation data value in the user information parameter. The XTI-mOSI provider will insure that the first abstract syntax and transfer syntax pair being negotiated is the one required for its encoding.

Mapping XTI Functions to ACSE/Presentation Services

Connection-mode Services

Association Establishment (successful, unsuccessful)

Note:

XTI does not support the concept of a negative association establishment; that is, the equivalent of a negative A-ASSOCIATE response. That is, an XTI-mOSI implementation does not generate an AARE- APDU.

To reject an association request, the responding application issues t_snddis(), which is mapped to a A-ABORT.

However, a negative A-ASSOCIATE confirm (AARE- APDU) may be received from a non-XTI OSI peer. The negative A-ASSOCIATE confirm event is mapped to t_rcvdis().

Notes:

1. if either the AP title or AE qualifier is selected for sending, the other must be selected.

2. sndcall->opt or, if no option specified, default value

3. sndcall->opt or, if no option specified, default value, with ACSE added by provider

4. call->opt with ACSE context removed from the list passed to user

5. combines Result and Result Source-diagnostic

Notes:

1. unitdata->opt or, if no option specified, default value

2. unitdata->opt or, if no option specified, default value, with ACSE added by provider

3. unitdata->opt with ACSE context removed from the list passed to user

Option Data Types and Structures

SPECIFIC ISO ACSE/PRESENTATION OPTIONS

Naming and Addressing Datatype

The buf[] part of the addr structure is an mosiaddr structure defined in the following way:

 

struct t_mosiaddr {
    t_uscalar_t     flags;
    t_scalar_t      osi_ap_inv_id;
    t_scalar_t      osi_ae_inv_id;
    unsigned int    osi_apt_len;
    unsigned int    osi_aeq_len;
    unsigned int    osi_paddr_len;
    unsigned char   osi_addr[T_AP_MAX_ADDR];
};

where:

• the flags field indicates the validity of the contents of the invocation identifier fields within the structure. One or more of the following bits may be set:

  T_OSI_AP_IID_BIT	The contents of the osi_ap_inv_id field is valid
  T_OSI_AE_IID_BIT	The contents of the osi_ae_inv_id field is valid

  Unused bit in flags must be set zero by the user when creating a t_mosiaddr structure for sending, and should be ignore by the user on receipt.

  In a t_mosiaddr structure, a bit set in flags indicates the presence of the corresponding invocation identifier in the PDU. Similarly a bit not set indicates absence of the corresponding invocation identifier in the PDU.

• the AP Title starts at

  osi_addr[0]
  
  

• the AE Qualifier starts at

  osi_addr[T_ALIGN(osi_apt_len)]
  
  

• the Presentation Address is at

  osi_addr[T_ALIGN(osi_apt_len)+T_ALIGN(osi_aeq_len)]
  
  

• T_AP_MAX_ADDR is an implementation-defined constant.

The application is responsible for encoding/decoding the AP title and AE qualifier; alternatively, a lookup routine may be provided (outside the scope of this specification).

ACSE/Presentation Option Levels and Names

#define T_ISO_APCO      0x0200
#define T_ISO_APCL      0x0300
#define T_AP_CNTX_NAME  0x1
#define T_AP_PCL        0x2

Object Identifier Representation within Options

The application context, abstract syntax and transfer syntax all utilise object identifiers. An object identifier is held in the BER encoded form as a variable length item, whose length can be inferred from the length of the option, as in the following macro:

 

#define T_OPT_VALEN(opt) (opt->len - sizeof(struct t_opthdr)).

The application is responsible for encoding/decoding the object identifier value. Alternatively, a lookup routine may be provided (outside the scope of this specification).

Application Context Name Option

The application context name option consists of an object identifier item as defined above.

Presentation Context Definition and Result List Option

The Presentation Context Definition and Result List option is used to propose a presentation context, giving its abstract and transfer syntax, and to hold the result of negotiation of a presentation context.

The presentation context definition and result list option is a variable sized option consisting of a t_scalar_t giving the number of presentation contexts followed by an array of that number of presentation context item offset elements. Each element is defined as:

 

struct t_ap_pco_el  {
    t_scalar_t    count;
    t_scalar_t    offset;
}

Each presentation context items offset element gives: the count of syntax entries in the presentation context item (including the abstract syntax entry) and the offset of the presentation context item from the beginning of the Presentation Context Definition and Result List option value.

Each presentation context item consists of a header followed by an array.

The header is defined as:

 

struct t_ap_pc_item  {
    t_scalar_t     pci;
    t_scalar_t     res;
}

where pci is a unique odd integer (if this is zero in the sndcall argument of t_connect(), the provider will substitute an appropriate value), and res is the result of negotiation. The array of syntax offset elements immediately follows the header. Each element is defined as:

 

struct t_ap_syn_off  {
    t_scalar_t    size;
    t_scalar_t    offset;
}

where size is the length of the syntax object identifier contents, and offset is the offset of the object identifier for the syntax from the beginning of the Presentation Context Definition and Result List option value.

The first element in the array of syntax offset elements refers to the abstract syntax the second to the first transfer syntax, and so on.

The following values are used in the res field of a presentation context item:

 

#define  T_PCL_ACCEPT                0x0000
                    /*pres. context accepted                     */
#define  T_PCL_USER_REJ              0x0100
                    /*pres. context rejected by peer application */
#define  T_PCL_PREJ_RSN_NSPEC        0x0200
                    /*prov. reject: no reason specified          */
#define  T_PCL_PREJ_A_SYTX_NSUP      0x0201
                    /*prov. reject: abstract syntax not supported*/
#define  T_PCL_PREJ_T_SYTX_NSUP      0x0202
                    /*prov. reject:transfer syntax not supported */
#define  T_PCL_PREJ_LMT_DCS_EXCEED   0x0203
                    /*prov. reject: local limit on DCS exceeded  */

For the default abstract syntax, transfer syntax and application context, this Appendix uses object identifiers which are specified in the profile (ISO/IEC pDISP 11188 - Common Upper Layer Requirements (CULR), Part 3: Minimal OSI upper layer facilities - OIW/EWOS working document). Thus the descriptions provided in this Appendix are informative only.

Default Abstract Syntax for mOSI

The following OBJECT IDENTIFIER have been defined in CULR part 3:

 

{iso(1) standard(0) curl(11188) mosi(3) default-abstract-syntax(1) version(1)}

This object identifier can be used as the abstract syntax when the application protocol (above ACSE) can be treated as single presentation data values (PDVs). Each PDV is a sequence of consecutive octets without regard for semantic or other boundaries. The object identifier may also be used when, for pragmatic reasons, the actual abstract syntax of the application is not identified in Presentation Layer negotiation.

Notes:

1. Applications specified using ASN.1 should not use the default abstract syntax.

2. As this object identifier is used by all applications using the default abstract syntax for mOSI, it cannot be used to differentiate between applications. One of the ACSE parameters; for example, AE Title or Presentation address, may be used to differentiate between applications.

Default Transfer Syntax for mOSI

If the default transfer syntax and the abstract syntax are identical, the OBJECT IDENTIFIER for the default abstract syntax is used. If they are not identical, the OBJECT identifier for the default transfer syntax is:

 

{iso(1) standard(0) curl(11188) mosi(3) default-transfer-syntax(2) version(1)}

Note:

In the presentation data value of the PDV list of Presentation Protocol or in the encoding of User Information of ACSE Protocol, only octet-aligned or arbitrary can be used for default transfer syntax for mOSI. Single-ASN1-type cannot be used for default transfer syntax for mOSI.

Default Application Context for mOSI

The following OBJECT IDENTIFIER has been defined in Common Upper Layer Requirements (CULR) part 3:

 

{iso(1) standard(0) curl(11188) mosi(3) default-application-context(3) version(1)}

This application context supports the execution of any application using the default abstract syntax for mOSI.

Reason Codes for Disconnections

#define T_AC_U_AARE__NONE  0x0001     /* connection rejected by      */
                                      /* peer user: no reason given  */
#define T_AC_U_AARE_ACN    0x0002     /* connection rejected:        */
                                      /* application context name    */
                                      /* not supported               */
#define T_AC_U_AARE_APT    0x0003     /* connection rejected:        */
                                      /* AP title not recognised     */
#define T_AC_U_AARE_AEQ    0x0005     /* connection rejected:        */
                                      /* AE qualifier not recognised */
#define T_AC_U_AARE_PEER_AUTH 0x000e  /* connection rejected:        */
                                      /* authentication required     */
#define T_AC_P_ABRT_NSPEC  0x0011     /* aborted by peer provider:   */
                                      /* no reason given             */
#define T_AC_P_AARE_VERSION 0x0012    /* connection rejected:        */
                                      /* no common version           */

Other reason codes may be specified as implementation defined constants. In order to be portable, an application should not interpret such information, which should only be used for troubleshooting purposes.

<xti_mosi.h> Header File

This section presents the additional header file information for XTI-mOSI.

Implementations supporting XTI-mOSI will provide equivalent definitions in <xti_mosi.h>. XTI-mOSI programs should include <xti_mosi.h> as well as <xti.h>.

/* mosi address structure */

struct t_mosiaddr {
    t_uscalar_t     flags;
    t_scalar_t      osi_ap_inv_id;
    t_scalar_t      osi_ae_inv_id;
    unsigned int    osi_apt_len;
    unsigned int    osi_aeq_len;
    unsigned int    osi_paddr_len;
    unsigned char   osi_addr[MAX_ADDR];
};

#define T_ISO_APCO      0x0200
#define T_ISO_APCL      0x0300
#define T_AP_CNTX_NAME  0x1
#define T_AP_PCL        0x2

#define T_OPT_VALEN(opt) (opt->len - sizeof(struct t_opthdr)).

/* presentation context definition and result list option */

struct t_ap_pco_el {
    t_scalar_t count;
    t_scalar_t offset;
}

/* presentation context item header */

struct t_ap_pc_item {
    t_scalar_t pci;      /* unique odd integer    */
    t_scalar_t res;      /* result of negotiation */
}
 
/* presentation context item element */

struct t_ap_syn_off {
    t_scalar_t size;   /* length of syntax object identifier contents */
    t_scalar_t offset; /* offset of object identifier for the syntax  */
}

/* values for res of a presentation context item */

#define T_PCL_ACCEPT              0x0000 /* pres. context accepted */
#define T_PCL_USER_REJ            0x0100 /* pres. context rejected */
                                         /* by peer application    */
#define T_PCL_PREJ_RSN_NSPEC      0x0200 /* prov. reject:          */
                                         /* no reason specified    */
#define T_PCL_PREJ_A_SYTX_NSUP    0x0201 /* prov. reject: abstract */
                                         /* syntax not supported   */
#define T_PCL_PREJ_T_SYTX_NSUP    0x0202 /* prov. reject: transfer */
                                         /* syntax not supported   */


#define T_PCL_PREJ_LMT_DCS_EXCEED 0x0203 /* prov. reject: local    */
                                         /* limit on DCS exceeded  */

/* Reason Codes for Disconnections */

#define T_AC_U_AARE__NONE     0x0001 /*connection rejected by      */
                                     /*peer user: no reason given  */
#define T_AT_C_U_AARE_ACN     0x0002 /*connection rejected:        */
                                     /*application context name    */
                                     /*not supported               */
#define T_AC_U_AARE_APT       0x0003 /*connection rejected:        */
                                     /*AP title not recognised     */
#define T_AC_U_AARE_AEQ       0x0005 /*connection rejected:        */
                                     /*AE qualifier not recognised */
#define T_AC_U_AARE_PEER_AUTH 0x000e /*connection rejected:        */
                                     /*authentication required     */
#define T_AC_P_ABRT_NSPEC     0x0011 /*aborted by peer provider:   */
                                     /*no reason given             */
#define T_AC_P_AARE_VERSION   0x0012 /*connection rejected:        */
                                     /*no common version           */

---

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents

Next section

Index