Section 3 of this International Standard specifies the dynamic conformance required of an implementation. This section specifies further JTM requirements. These requirements consist of
These requirements are specified in the following clauses.
4.1.1 The implementation shall either be a Basic Class JTM implementation or an extended JTM implementation. A Basic Class implementation shall process work specifications that meet the restrictions of Basic Class and shall establish application-contexts for "ISO JTM Basic Class Application-context". An extended implementation shall process all work specifications that are specified in this International Standard, and establish application contexts for both "ISO JTM Basic Class Application-context" and "ISO JTM Full Application-context".
4.1.2 The implementation shall satisfy the conformance requirements of ISO/IEC 9805 (CCR protocol), and shall maintain work specifications as bound data, as specified in that International Standard. The implementation shall satisfy the requirements of annex A (the CCR serviceŠuser rules) of ISO/IEC 9804 (CCR service).
4.1.3 A Basic Class implementation shall support the establishment of an application-context (see 2.2.5.1) for "ISO JTM Basic Class Application-context" for either outgoing transfers or for incoming transfers or for both. It shall support all means of establishing this application-context, using the mechanisms of ISO 8649 as specified in section 5 of this International Standard.
4.1.4 An extended implementation shall support the establishment of an application-context "ISO JTM Full Application-context" for either outgoing transfers or for incoming transfers or for both. It shall support the establishment of an application-context for "ISO JTM Basic Class Application-context" for the same direction of transfers. It shall support all means of establishing this application-context, using the mechanisms of ISO 8649 as specified in section 5 of this International Standard.
4.1.5 The implementation shall support the establishment of a presentation-context (see 2.2.5.2) for the "ISO JTM Abstract Syntax" (JTM presentation-context) and shall offer and accept the "Basic encoding of a single ASN.1 type" (see 2.2.5.3).
NOTE -- Offering or accepting other transfer syntaxes registered for use with the abstract syntax "ISO JTM Abstract Syntax" is not precluded, but is not required.
The implementation shall support all means of establishing this context using the mechanisms of ISO 8822 as specified in section 5 of this International Standard.
4.1.6 The implementation shall provide a means to configure the addressing information which is to be used by remote systems to establish application-associations for use in the "ISO JTM Basic Class Application-context" and, if it is an extended implementation, in the "ISO JTM Full Application-context" (MF22).
4.1.7 The implementation shall provide a means to configure the addressing information which appears in calling address fields for application-associations established for use by the JTM entity (MF23).
4.1.8 The implementation shall ensure that
4.1.9 The implementation shall support at least one JTM agency. An extended implementation shall either support at least one JTM agency, or shall support either JTM monitor point storage (see 4.2.4) or store-and-forward relaying (see 4.2.26) or both.
4.1.10 The implementation shall support both PROVIDER ACCEPTANCE and AGENCY ACCEPTANCE commitment levels for accesses to local agencies.
4.1.11 The implementation shall support the generation of all possible values of the GraphicString datatype in any field using this datatype.
NOTE -- This should be by provision for escape into hexadecimal notation for character repertoires not directly supported by the implementation.
4.1.12 The implementation shall support the display of all possible values of the GraphicString datatype when displaying fields using this datatype.
NOTE -- This should be by provision for escape into hexadecimal notation for character repertoires not directly supported by the implementation.
4.1.13 The implementation shall support the generation and display of all possible values of the OCTET STRING datatypes for fields using this datatype.
4.1.14 The implementation shall support the generation of diagnostic and status text using only the International Reference Version of ISO 646. It may optionally support the generation of such text using other character sets.
NOTE -- National Standards which are otherwise equivalent to this International Standard may vary this requirement.
4.1.15 The implementation shall consider two "GraphicString"s to be equal if the printing graphics for each are the same symbols in the same sequence.
NOTE -- Where a character (the letter 'A' for example), appears in more than one entry in the ISO Register of Character Sets (see ISO 2375) it is still to be considered the same character regardless of which register entry is in current use.
4.1.16 The following sub-clauses define the support required for ASN.1 datatypes. In these clauses, the word "support" shall be interpreted as follows:
4.1.16.1 Implementations of this International Standard shall support all "GraphicStrings" containing less than or equal to 40 characters, except were otherwise stated.
4.1.16.2 Implementations of this International Standard shall support all values of SEQUENCE OF and SET OF which include less than 10 elements, except where otherwise stated.
NOTE -- Support for other values allowed by the ASN.1 notation is permitted, but is not a conformance requirement.
4.1.16.3 An implementation shall support a "SEQUENCE OF Brief Display" in a "Work-display-doc" containing up to and including 256 elements.
The functions of a JTM implementation are related to the agencies which it supports. A JTM implementation might support only a single agency, many agencies of the same type, or many types of agency.
If JTM service primitives are issued by reference from some other standard, that standard specifies the nature of the JTM agencies and the applicability of this clause. Where this International Standard is used alone to provide a (human-level) service, this clause is applicable.
A JTM implementation shall use the terms in the table below to describe the functionality defined in the corresponding clause:
claim subclause
Support for Basic Class JTM OSI-job submission 4.2.1
Full support for JTM work OSI-job submission 4.2.2
Support for JTM monitoring 4.2.3
Support for JTM monitor point storage 4.2.4
Support for Basic Class JTM manipulation 4.2.5
Support for JTM work-manipulation processing (top-level only) 4.2.6
Full support for JTM work-manipulation processing 4.2.7
Support for report-manipulation 4.2.8
Support for transfer-control manipulation 4.2.9
Full support for JTM user OSI-job submission 4.2.10
Basic Class JTM support for a local file-store 4.2.11
JTM support for a local file-store (single file) 4.2.12
JTM support for a local file-store (transparent storage) 4.2.13
JTM support for a local file-store (multiple files) 4.2.14
Full JTM support for a local file-store 4.2.15
Basic Class JTM support for an output device 4.2.16
Full JTM support for an output device 4.2.17
Basic Class JTM support for job processing 4.2.18
Full JTM support for job processing 4.2.19
Basic Class JTM support from language xyz 4.2.20
Full JTM support from language xyz 4.2.21
Support for JTM transfer-control, without tcr-checking 4.2.22
Full support for JTM transfer-control 4.2.23
Support for JTM transfer manipulation 4.2.24
Support for a JTM process 4.2.25
Support for a store-and-forward relay 4.2.26
Complete Basic Class JTM support 4.2.27
Full Basic Class JTM support 4.2.27
4.2.1.1 The implementation provides mechanisms to permit the generation of a J-INITIATE primitive group.
4.2.1.2 The mechanisms permit the full range of Basic Class values to be used for parameters of J-INITIATE and of the J-service primitives related to CCR.
4.2.1.3 The implementation ensures that the correct sequence of primitives and restart behaviour does not depend on a human user except as stated in 4.4.13.
4.2.1.4 Where the implementation also claims JTM support for a local file-store, then it is capable of taking the data for documents in the J-INITIATE from the file-store.
4.2.1.5 The implementation supports the transfer of documents of document type "ISO ISO Simple text document" (see annex B) and enables a human user to generate all values of such documents for inclusion in J-INITIATE.
4.2.1.6 The implementation supports all JTM Basic Class commitment levels (as the CCR master).
NOTE -- This implementation need only be capable of making out-going calls, provided the monitor is set to some other open system, with a suitable authorisation element (see MF3 and MF6).
4.2.2.1 The implementation shall be an extended implementation.
4.2.2.2 The implementation shall provide support for Basic Class JTM OSI-job submission, as specified in 4.2.1.1 to 4.2.1.6.
4.2.2.3 The mechanisms for generating J-INITIATE primitive groups shall permit the full range of values to be used for the parameters of J-INITIATE and of the J-service primitives related to CCR. Mechanisms shall be provided to ensure that work specifications meeting the Basic Class restrictions can be generated.
4.2.2.4 The implementation supports all JTM commitment levels (as CCR master).
4.2.3.1 The implementation contains a sink agency to which JTM reports can be passed in a J-DISPOSE.
4.2.3.2 The reports are converted to a form intelligible to an observer, and are accessible to an observer. Both the JTM diagnostic code and the human-readable text are made available.
4.2.3.3 If the implementation is Basic Class, the above requirements apply only to reports that can be transferred within a "Basic-transfer-element". If the implementation is an extended implementation, the above requirements apply to all JTM reports.
NOTES
- The information can be placed in a file-store, a mailbox, sent to a terminal, or printed out.
- This implementation need only be capable of receiving incoming calls.
- The way in which the information is made intelligible and accessible is stated in the documentation (see 4.4.11).
4.2.4.1 The implementation shall be an extended implementation.
4.2.4.2 The implementation shall store reports as specified in 3.9.8.2.
4.2.4.3 The implementation shall respond to "report-manipulation" work specifications as specified in 3.11.
4.2.5.1 The implementation satisfies the requirements of 4.2.1.1 to 4.2.1.6 for the J-INITIATE-WORK-MAN primitive.
NOTE -- Support for J-INITIATE-WORK is not required, and the note on 4.2.1.6 does not apply in this case.
4.2.5.2 The implementation supports the transfer of documents of the "ISO JTM work-display document" document type (see annex B)
4.2.5.3 The implementation contains a sink agency to which an "ISO JTM work-display document" can be passed in a J-DISPOSE.
4.2.5.4 The document is converted to a form intelligible to an observer, and is accessible to an observer (see 4.2.3.2).
4.2.5.5 If the user requests completion commitment, the action of 4.2.5.4 occurs prior to an offer of commitment for the work display.
NOTE -- This support is expected to enable an interactive user to initiate a manipulation and, subject to availability of communications and other resources, obtain an immediate JTM display prior to commitment.
4.2.6.1 The implementation shall be an extended implementation.
4.2.6.2 The implementation shall support the procedures of 3.10 for "work-manipulation" work specifications that contain "Work-manipulation-operations" which contain a single "select" "Work-operation" in which the "Selector" contains a "selector-form" of "first-header-is".
NOTE -- Selection of work specifications by such an work-manipulation does not involve tests on proforma fields.
4.2.6.3 If the implementation supports sink or execution agencies that provide AGENCY-ACCEPTANCE commitment, J-HOLD and J-RELEASE shall be supported.
4.2.7.1 The implementation shall be an extended implementation.
4.2.7.2 The implementation shall support the procedures of 3.10 for "work-manipulation" work specifications that contain "Work-manipulation-operations" that are not "Basic-work-manipulation-operations".
4.2.7.3 If the implementation supports sink or execution agencies that provide AGENCY-ACCEPTANCE commitment, J-HOLD and J-RELEASE shall be supported.
4.2.8.1 The implementation shall be an extended implementation.
4.2.8.2 The implementation satisfies the requirements of 4.2.10 for the J-INITIATE-REPORT-MAN primitive group.
NOTE -- Support for J-INITIATE-WORK is not required.
4.2.8.3 The implementation supports the transfer of documents of the "JTM report-display document" document type (see annex C).
4.2.8.4 The implementation contains a sink agency to which documents of the "JTM report-display document" document type can be passed in a J-DISPOSE.
4.2.8.5 The document is converted to a form intelligible to an observer, and is accessible to an observer. (see 4.2.3.2)
4.2.8.6 If the user requests COMPLETION commitment, the action of 4.2.8.5 occurs for all documents prior to an offer of commitment for the manipulation.
4.2.9.1 The implementation shall be an extended implementation.
4.2.9.2 The implementation satisfies the requirements of 4.2.10 for the J-INITIATE-TCR-MAN primitive group.
NOTE -- Support for J-INITIATE-WORK is not required.
4.2.9.3 The implementation supports the transfer of documents of the "JTM tcr-display document" document type (see annex C).
4.2.9.4 The implementation contains a sink agency to which documents of the "JTM tcr-display document" document type can be passed in a J-DISPOSE.
4.2.9.5 The document is converted to a form intelligible to an observer, and is accessible to an observer. (see 4.2.3.2)
4.2.9.6 If the user requests COMPLETION commitment, the action of 4.2.9.5 occurs for all documents prior to an offer of commitment for the manipulation.
4.2.10.1 The implementation shall be an extended implementation.
4.2.10.2 The implementation shall provide support for Basic Class JTM OSI-job submission, as specified in 4.2.1.1 to 4.2.1.6.
4.2.10.3 The implementation shall provide support for full JTM work OSI-job submission, as specified in 4.2.2.3 and 4.2.2.4.
4.2.10.4 The mechanisms for generating J-INITIATE-WORK-MAN and J-INITIATE-REPORT-MAN primitive groups permit the full range of values to be used for the parameters of J-INITIATE-WORK-MAN or J-INITIATE-REPORT-MAN and of the J-service primitives related to CCR. The mechanisms for generating J-INITIATE-TCR-MAN shall permit the values of "Transfer-manipulation" with the CHOICE "display".
4.2.11.1 The implementation supports the transfer of documents of the document types "ISO JTM simple text document" and "ISO JTM simple print document" (see annex B).
4.2.11.2 The implementation provides mechanisms for the preparation and display of all values of documents with the semantics of "ISO JTM simple text document" and "ISO JTM simple print document", in support of their transfer.
4.2.11.3 The implementation contains a sink agency to which a "ISO JTM simple text document" and "ISO JTM simple print document" can be passed in a J-DISPOSE.
4.2.11.4 The documents are converted to a local format, and placed in the local file-store, using the "document-se-reference" in forming the filename.
4.2.11.5 The agency name "FILE" is used for the principal local file-store supported by the implementation.
4.2.11.6 Any existing file with the same name as the document-se-reference is overwritten, subject to adequate authorisation. If no such file exists, a new file is created.
4.2.11.7 Subclause 4.2.1.4 applies if support for Basic Class OSI-job submission is also claimed.
4.2.12.1 The implementation shall be an extended implementation.
4.2.12.2 The requirements of 4.2.11.1 to 4.2.11.5 shall apply. All access to the filestore is subject to adequate authorisation.
NOTE -- Other document types, in addition those specified in 4.2.11 may also be supported.
4.2.12.3 If the "agency-parameter" of the J-DISPOSE is "store NULL", and the conversion to local format is such that it will not be exactly reversed when a subsequent J-GIVE collects the document, the agency shall refuse the document, returning a CCR no-retry diagnostic.
4.2.12.4 The "doc-name" in the "document-se-reference" of the J-DISPOSE shall be used in forming the filename. The interactions of the "access-parameter" and the prior existence or non-existence of a file with the same name shall be as specified in Table 1.
| Se-access-parameter |
No file with name equal to <169>doc-name<170> exists |
File already exists with name equal to <169>doc-name<170> |
<169>doc-name<170> not acceptable as filename |
| NORMAL | Create | Overwrite | Create, with warning |
| NEW | Create | Error-exists | Create, with warning |
| OLD | Error-not-exist | Overwrite | Error-not-exist |
| ADD | Create | Append | Create, with warning |
| APPEND | Error-not-exist | Append | Error-not-exist |
| Action | Meaning |
|---|---|
| Create | A new file is created, with name equal to <169>doc-name<170> |
| Overwrite | The existing file is overwritten |
| Create, with warning | The procedures of 3.8.6.7 apply. |
| Append | The document is appended to the existing file |
| Error-not-exist | Refusal is given as specified in 3.8.9, with <169>code<170> <169>ue-document-does-not-exist<170> |
| Error-exist | Refusal is given as specified in 3.8.9, with <169>code<170> <169>ue-document-already-exists<170> |
4.2.12.5 The implementation contains a source agency from which documents can be collected by a J-GIVE. Mechanisms (possibly including the use of J-DISPOSE) shall exist by which a human user can generate documents which can subsequently be collected by J-GIVE as "Simple ISO text document".
NOTE -- Other document types may be supported.
4.2.12.6 The "doc-name" in the "document-source-reference" of the J-GIVE shall be used to identify the file to be collected.
4.2.12.7 If the "source-access-parameter" of the J-GIVE is "move NULL", the file shall be removed from the filestore on commitment. If the "source-access-parameter" is "copy NULL" the file shall remain in the filestore.
The requirements of 4.2.12 shall apply, except that if the "agency-parameter" on a J-DISPOSE to the agency is "store NULL", any conversion shall be exactly reversed when a subsequent J-GIVE collects the document.
4.2.14.1 The requirements of 4.2.12 shall apply.
4.2.14.2 Any source agency described in 4.2.12.5 responds to a J-ENQUIRE in which <doc-name> matches a filename such that the implementation uses a single J-GIVE to collect the file. The agency shall respond to a J-ENQUIRE that matches the name of a set of files such that the implementation collects all of them.
4.2.14.3 The agency shall be capable of accepting more than one J-DISPOSE as a result of the processing of a single work-specification. Where the <document se reference>s on the J-DISPOSEs differ only in the last elements, the documents on the J-DISPOSEs shall each be placed in the filestore.
NOTE -- This ensures that the result of resolving a <multiple-form> document block can be disposed to the filestore.
All the requirements of both 4.2.13 and of 4.2.14 shall apply.
NOTE -- This International Standard does not constrain the manner in which a file that has been created by J-DISPOSE or which may be accessed by J-GIVE is visible by other mechanisms. Such a file may appear as part of a larger entity or may have internal subdivisions when accessed by other means, or when accessed using different parameters on a J-GIVE, J-ENQUIRE or J-DISPOSE.
4.2.16.1 The implementation supports the transfer of documents of the document types "ISO JTM simple text document" and "ISO JTM simple print document" (see annex B).
4.2.16.2 The implementation contains a sink agency to which a "ISO JTM simple text document" and "ISO JTM simple print document" can be passed in a J-DISPOSE.
4.2.16.3 The documents are displayed according to the document semantics specified for the document type. The display control indicators of the "ISO JTM simple print document" document-type are supported and correctly interpreted in relation to the medium. (See also 4.4.10.)
4.2.16.4 The document might not have been displayed before AGENCY COMMITMENT has been offered, but it has have been stored as secure data. COMPLETION COMMITMENT (or J-END-SIGNAL) is only given when the document has been completely displayed.
4.2.16.5 The agency name PRINTER is used for the primary output device supported by the implementation.
4.2.16.6 The "document-se-reference" is used in forming a heading for the document. Where an authorisation element is available, the "Identification" in this element is also used in forming the heading.
4.2.16.7 Where AGENCY COMMITMENT is provided, J-STATUS, J-STOP and J-KILL are supported.
4.2.17.1 The implementation shall be an extended implementation.
4.2.17.2 The requirements of 4.2.16.1 to 4.2.16.7 apply.
NOTE -- Other document types, in addition to those specified in 4.2.16, may be supported.
4.2.18.1 The implementation supports the transfer of documents of document types "ISO JTM simple text document" and "ISO JTM simple print document" (see annex B).
4.2.18.2 The implementation contains an execution agency to which a "ISO JTM simple text document" document can be passed in a J-DISPOSE.
4.2.18.3 The document consists of an implementation-dependent description of the job processing which is required.
4.2.18.4 Additional control information (e.g. scheduling parameters) can be required at the head of the document. Additional authorisation can also be required at the head of the document.
4.2.18.5 The implementation provides for documents produced as a result of the job processing to be concatenated as a single document, and to be made available with a predictable name, as a "ISO JTM simple print document".
NOTE -- The document name can depend on the contents of the initial document, or can be fixed. It can be null.
4.2.18.6 The agency name JOBMILL is used for the primary job processing facility supported by the implementation.
4.2.18.7 J-STATUS, J-STOP and J-KILL are supported.
4.2.18.8 Where the implementation claims Basic Class JTM support for a local filestore, it supports access to that filestore as a part of the execution agency.
4.2.19.1 The implementation shall be an extended implementation.
4.2.19.2 The requirements of 4.2.18.1 to 4.2.18.3 and 4.2.18.5 to 4.2.18.7 apply.
4.2.19.3 Additional control information can be required at the head of the document or in the "Document-se-reference" on the J-DISPOSE. The name of the output document(s) can depend on the value of the "Document-se-reference".
4.2.19.4 The implementation provides for documents produced as a result of the job processing to be available with a predictable name for collection as separate documents (possibly only one) by J-ENQUIRE followed by J-GIVE.
4.2.19.5 Where the implementation claims Basic Class or Full JTM support for a local filestore, it supports access to the principal filestore as part of the principal execution agency.
4.2.20.1 In this clause, "language xyz" is any programming language specified by the implementor.
4.2.20.2 The implementation provides facilities for any program written in language xyz to perform actions which allow it to issue and to receive JTM service primitives with the full range of JTM Basic Class and CCR parameter values. The program is able to act (simultaneously) as one or more of any type of JTM agency.
4.2.20.3 The names of the agencies which the program represents can not be used by other programs, nor is the program able to use agency names allocated to other programs.
4.2.20.4 The correct behaviour of the JTM implementation does not depend on the correct behaviour of the program.
4.2.20.5 The implementation supports the transfer of at least "ISO JTM simple text document" and "ISO JTM simple print document" document types (see annex B), and enables a program in language xyz to read or to generate the full range of such documents.
NOTE -- The precise form of language binding for JTM service primitives may be subject to future International Standardisation, but is not constrained by this International Standard.
4.2.21.1 The implementation shall be an extended implementation.
4.2.21.2 The requirements of Basic Class JTM support from language xyz apply, with the additional requirement that the full range of parameters and parameters values for JTM and CCR are supported for JTM service primitives.
4.2.22.1 The implementation shall be an extended implementation.
4.2.22.2 The implementation shall follow the procedures of 3.12 for processing "transfer-manipulation" work specifications containing "Transfer-manipulation"s that are the CHOICEs "set" and "display".
4.2.22.3 The implementation shall retain transfer control records set by the procedures of 3.12 for a configurable period, and shall follow the procedures of 3.7.4 and 3.7.4.1 for scheduling the transmission of work specifications.
4.2.23.1 The requirements of 4.2.22 shall apply.
4.2.23.2 Mechanisms shall be provided to invoke the procedures of 3.21. These mechanisms shall be invoked automatically when the implementation is started after a failure or a period of inactivity.
4.2.24.1 The implementation shall be an extended implementation.
4.2.24.2 Mechanisms shall be provided to generate "Transfer-manipulation" work specifications with "Transfer-manipulation"s of the CHOICE "set". When such work specifications are sent, the "Control-specifications" within them shall also be stored by the implementation.
4.2.24.3 The implementation shall respond to "Transfer-manipulation" work specifications containing "check" "Transfer-manipulation"s as specified in 3.12.
4.2.25.1 The implementation shall be an extended implementation.
4.2.25.2 The implementation shall permit any user process to act as an execution agency.
4.2.25.3 The implementation shall provide for the automatic invocation of the process when JTM access to the agency is required.
4.2.25.4 The implementation shall support request for COMPLETION commitment for accesses to the agency.
NOTE -- It is not required that the user process can support COMPLETION commitment, but that the implementation provides mechanisms for such support.
4.2.26.1 The implementation shall be an extended implementation
4.2.26.2 The implementation shall accept receipt of work-specifications in which the first element of the "relays" is equal to the JTM-name of the implementation with a commitment level of PROVIDER-ACCEPTANCE. The implementation shall secure such work-specifications and their accompanying documents.
4.2.26.3 The implementation shall support either JTM work-manipulation processing (top-level only) or full JTM work-manipulation processing.
The implementation contains all the functionality defined in all of subclauses 4.2.1, 4.2.3, 4.2.5, 4.2.11, 4.2.16 and 4.2.18, and states which, if any, languages support JTM, as defined in 4.2.20.
NOTE -- Where an implementation supports more than one printer, filestore, jobmill, or language, JTM support for at least one of them is the only requirement specified in this International Standard. Where an implementation is being obtained from another party, details of which devices are supported should be ascertained.
4.3.1 Any local management function not referenced by the following clauses may return fixed values chosen by the implementor. This can represent a null functionality.
4.3.2 Where the following clauses require the values of a function to be configurable, the means of configuration is not specified in this International Standard, nor is the range of values which shall be supported.
4.3.3 The values of MF2 (local name), MF3 (primary monitor), MF17 (visibility), MF22 and MF23 (addressing), and, if reports are stored as specified in 3.9.8, MF27 (holding time for reports), shall be configurable.
4.3.4 If function MF8 (calling address recognition) is supported with values other than UNKNOWN, the "JTM-name" strings shall be configurable.
4.3.5 If functions MF9 (call progress list), MF11 (authorisation needed), MF13 (trusted implementations) or MF16 (authorisation to send) are supported, the "JTM-name"s they use shall be configurable.
4.3.6 Any values of "User-identification-authority" used in MF12 (recognised user identification authorities), MF15 (agency authorisation) or MF16 (authorisation to send) shall be configurable.
4.3.7 The remote addresses used in MF16 (Authorisation to send) shall be configurable.
4.3.8 Functions MF22 and MF23 are referenced in 4.1.6, 4.1.7 and 4.1.8, and are required to be configurable.
The implementation shall either satisfy the documentation requirements of a standard referencing this International Standard, which then determines the applicability of this clause, or shall satisfy all the following sub-clauses.
4.4.1 The documentation shall state whether it is a Basic Class JTM implementation, or an extended JTM implementation.
4.4.2 The documentation shall state which of the terms defined in clause 4.2 are applicable, and the devices or facilities with which the corresponding agencies are associated.
NOTE -- It is recommended that where an implementation supports a functional class but with some further restrictions, the documentation states this using the terms defined in 4.2 qualified by a statement of the limitations.
4.4.3 For each device or facility which is associated with a JTM agency, the events and states which cause JTM primitive groups to be issued, or which affect the values of parameters, shall be stated. The events and states resulting from the issue of a JTM primitive group, or affected by the value of parameters, shall be stated.
4.4.4 For each programming language which supports JTM (see 4.2.20) the interface for issue and receipt of JTM service primitives shall be stated.
4.4.5 The values returned by all the local management functions shall be stated. Where these values can be wholly or partly varied by the local management, the means of such configuration shall be stated.
4.4.6 Where 3.8.6.7 (mapping into local names) is applicable for an agency, the mapping shall be stated.
4.4.7 The queuing strategy and queue visibility for incoming calls which are waiting, and for progressing work specifications waiting for agencies or for outgoing calls shall be stated. The algorithm for future attempts after RETRY-LATER (see 3.5.3) shall be stated. The persistence of the implementation [see 3.5.2b)] shall be stated.
4.4.8 The action taken (if any) when unauthorised calls are received (see 3.3.3) shall be stated.
4.4.9 The contents of the document to be submitted to an execution agency shall be stated.
For an extended implementation, the use made of the value of "document-se-reference" shall be stated.
4.4.10 The way in which "ISO JTM simple print document" and "ISO JTM simple text document" document types (see annex B) are stored or printed locally shall be stated for any device acting as a sink agency. This statement shall include details of the treatment of lines which are too long, and of character repertoires which are not directly supported.
For an extended implementation, the permitted values of "agency-parameter" and "agency-format" and the effect of "agency-format" on the storage or printing shall be stated.
4.4.11 The way in which reports, work-display and tcr-display documents are formatted and disposed of shall be stated for any device acting as a sink agency. (See 4.2.3.2.)
4.4.12 The time of binding of data referenced by a J-INITIATE shall be stated for any device or interface supporting J-INITIATE.
4.4.13 The documentation shall state the local recovery procedures to be carried out following an application-failure.
4.4.14 The documentation shall reference this International Standard, and any Amendments and Addenda to which it conforms, stating that it is a conforming implementation.
4.4.15 The documentation shall specify the document types supported for JTM transfers, the way documents of these types are stored or printed by any device acting as a sink agency, and the way they are prepared for any device acting as a source agency. Any restrictions which prevent the display or preparation of the full range of document in the document type shall be stated.
4.4.16 The documentation shall state the range of human languages and character sets in which it is capable of generating diagnostic and status messages, in response to the CCR diagnostic code indicator.
4.4.17 For an extended implementation, for any device acting as a source agency that supports J-ENQUIRE, the form of the "GraphicString"s returned on the J-ENQUIRE response shall be stated.
4.4.18 For an extended implementation, the documentation shall state whether FTAM access is supported.
4.4.19 For an extended implementation that supports FULL WORK-MANIPULATION, the documentation shall state state what is the maximum period that may elapse, when the implementation is active, between the "release-time" specified in a "Hold-element", and the application of the procedures of 3.19.9.
4.4.20 For an extended implementation, the documentation shall state which, if any, of the addressing information specified in 4.1.6 will enable a remote system to establish application associations only in "ISO JTM Basic Class Application-context", and which are capable of "ISO JTM Full Application-context" and "ISO JTM Basic Class Application-context".
4.4.21 For an extended implementation, the documentation shall state in what cases, if any, it attempts to establish an application association in "ISO JTM Basic Class Application-context". The documentation shall also state which, if any, of the addressing information specified in 4.1.7 is used only when the implementation is attempting to establish an application association in "ISO JTM Basic Class Application-context" and which is used when it is attempting to establish an association in "ISO JTM Full Application-context".
463 done