Technical Committee Implementation Conformance Statement (ICS) Proforma Style Guide AF-TEST-0137.000 February, 2000 Copyright Version 000 February 2000 (c) 2000 by The ATM Forum. This specification/document may be reproduced and distributed in whole, but (except as provided in the next sentence) not in part, for internal and informational use only and not for commercial distribution. Notwithstanding the foregoing sentence, any protocol implementation conformance statements (PICS) or implementation conformance statements (ICS) contained in this specification/document may be separately reproduced and distributed provided that it is reproduced and distributed in whole, but not in part, for uses other than commercial distribution. All other rights reserved. Except as expressly stated in this notice, no part of this specification/document may be reproduced or transmitted in any form or by any means, or stored in any information storage and retrieval system, without the prior written permission of The ATM Forum. The information in this publication is believed to be accurate as of its publication date. Such information is subject to change without notice and The ATM Forum is not responsible for any errors. The ATM Forum does not assume any responsibility to update or correct any information in this publication. Notwithstanding anything to the contrary, neither The ATM Forum nor the publisher make any representation or warranty, expressed or implied, concerning the completeness, accuracy, or applicability of any information contained in this publication. No liability of any kind shall be assumed by The ATM Forum or the publisher as a result of reliance upon any information contained in this publication. The receipt or any use of this document or its contents does not in any way create by implication or otherwise: • Any express or implied license or right to or under any ATM Forum member company's patent, copyright, trademark or trade secret rights which are or may be associated with the ideas, techniques, concepts or expressions contained herein; nor • Any warranty or representation that any ATM Forum member companies will announce any product(s) and/or service(s) related thereto, or if such announcements are made, that such announced product(s) and/or service(s) embody any or all of the ideas, technologies, or concepts contained herein; nor • Any form of relationship between any ATM Forum member companies and the recipient or user of this document. Implementation or use of specific ATM standards or recommendations and ATM Forum specifications will be voluntary, and no company shall agree or be obliged to implement them by virtue of participation in The ATM Forum. The ATM Forum is a non-profit international organization accelerating industry cooperation on ATM technology. The ATM Forum does not, expressly or otherwise, endorse or promote any specific products or services. NOTE: The user's attention is called to the possibility that implementation of the ATM interoperability specification contained herein may require use of an invention covered by patent rights held by ATM Forum Member companies or others. By publication of this ATM interoperability specification, no position is taken by The ATM Forum with respect to validity of any patent claims or of any patent rights related thereto or the ability to obtain the license to use such rights. ATM Forum Member companies agree to grant licenses under the relevant patents they own on reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain such a license. For additional information contact: The ATM Forum Worldwide Headquarters 2570 West El Camino Real, Suite 304 Mountain View, CA 94040-1313 Tel: +1-650-949-6700 Fax: +1-650-949-6705 Fax: +1-650-949-6705 Contents Copyright i 1 Scope 1 2 References 2 3 Definitions and abbreviations 2 3.1 Definitions 2 3.2 Abbreviations 3 4 Prerequisites 3 4.1 Definition of ICS proforma and basic rules 4 5 Structure of this style guide 4 6 How to write an ICS proforma 4 7 General guidelines 4 7.1 Why this style guide should be followed 4 7.2 Which questions and how to structure them 5 7.2.1 MEANINGFUL, UNAMBIGUOUS AND USEFUL QUESTIONS 5 7.2.2 AVOIDING COMPLEX QUESTIONS 5 7.2.3 STRUCTURE AND LEVEL OF DETAIL 6 7.3 How to choose a status 8 7.3.1 M: MANDATORY 8 7.3.2 O: OPTIONAL 8 7.3.3 N/A: NOT APPLICABLE 9 7.3.4 X: PROHIBITED (EXCLUDED) 9 7.3.5 C : CONDITIONAL 9 7.3.6 O.: QUALIFIED OPTIONAL 10 7.4 How to deal with two main roles 11 8 Guidelines on ICS proforma tables 11 8.1 Table columns 12 8.2 Table types 14 9 Guidelines on references to items 15 10 Guidelines on conditional items 15 10.1 Condition number 16 10.2 Conditional expression 17 10.3 Predicate applying to a whole clause or a whole table 17 11 Guidelines on qualified optional items 17 12 Guidelines on the use Microsoft(r) Word for Windows(tm) 18 12.1 How to use the electronic version of the template 18 12.2 How to use sequences, bookmarks in ICS proforma tables 19 12.2.1 TABLE AND ITEM NUMBERS 19 12.2.2 CONDITIONAL ITEMS 19 12.2.3 QUALIFIED OPTIONAL ITEMS 21 12.2.4 SUMMARY 21 13 Maintenance aspects 21 Annex A: Template of an ICS proforma specification 24 A.1 Conventions 24 A.2 The Template 24 1 Introduction 27 1.1 Scope 27 1.2 References 27 1.3 Definitions 27 1.4 Abbreviations 28 1.5 Conformance 28 2 Identification of the Implementation 28 1.6 Date of the statement 1 1.7 Implementation Under Test (IUT) identification 29 1.8 System Under Test (SUT) identification 29 1.9 Product supplier 29 1.10 Client (if different from product supplier) 29 1.11 ICS contact person 30 1.12 Identification of the 30 3 The ICS Proforma 30 1.13 Global statement of conformance 30 1.14 Instructions for completing the ICS proforma 31 4 History 31 Foreword This ICS proforma style guide was produced by the ATM Forum TEST Working Group to assist ATM Forum in producing high quality ICS proformas. The guide is based on EG 201 058 v1.2.3 (1998-04) [1] ICS Style Guide of the ETSI Technical Committee on Methods for Testing and Specification (MTS) and on the material currently in use for the development of ATM Forum ICS proforma. Introduction An Implementation Conformance Statement (ICS) proforma is a document in the form of a questionnaire. When filled in by the supplier of an implementation, it becomes an ICS. The objective of the ICS is to provide a statement by the supplier stating which capabilities of the specification have been implemented. It is used to: - check the conformance of the implementation at functional capabilities level; - select relevant tests from the test suite; - provide parameters for the test suite; - provide a list of the implemented capabilities and options; - find errors and ambiguities in the specification when preparing the ICS proforma. The questions in an ICS proforma are presented in the form of tables. EXAMPLE: Table A.1: Call directions Item Call direction Reference Status Conditions for status Support 1 Incoming call 1.1, 5.4.3 m 2 Outgoing call 1.2, 7.1.2.1 o With the following conventions: - "Incoming call" stands for "Is incoming call supported?"; - "Outgoing call" stands for "Is outgoing call supported?"; - "m" in the status column stands for "it is mandatory to support it"; - "o" in the status column stands for "it is optional to support it"; - the supplier of the implementation needs to answer "Yes" or "No" in the support column. The present document has been developed to harmonize the ICS proforma produced by the different groups in the ATM Forum and elsewhere. Scope The present document is intended to be used by specifiers of Implementation Conformance Statement (ICS) proforma. It provides practical guidance in order to produce basic ICS proformas. It contains a template of an ICS proforma with instructions on how to use it. ICS proforma can be used with implementations other than protocol implementations. Examples of the possible ICS include, information object ICS, profile ICS and the Protocol ICS or the PICS proforma. This Guide does not include the additional material required to addres the profile ICS proforma. The present document gives specific guidance on the use of the template, in this particular context. The electronic version of the template is available. The electronic version of the template should be used as the physical basis of an actual ICS proforma, with minimum modifications. The present document should be applied in the ATM Forum for the development of new ICS proforma. Existing ICS proformas need not be modified. References [1] EG 201 058 V1.2.3 (1998-04): "Methods for Testing and Specification (MTS); Implementation Conformance Statement (ICS) Proforma Style Guide ". [2] ISO/IEC 9646-1: 1994, Information technology - Open Systems interconnection - Conformance testing methodology and framework - Part 1: General concepts (see also ITU-T Recommendation X.290 (1995)). [3] ISO/IEC 9646-7: 1995, Information technology - Open Systems interconnection - Conformance testing methodology and framework - Part 7: Implementation Conformance Statements (see aslo ITU-T Recommendation X.296 (1995)). [4] ISO/IEC 9646-3: 1998, Information technology - Open Systems interconnection - Conformance testing methodology and framework - Part 3: The Tree and Tabular Combined Notation (TTCN) (see also ITU-T Recommendation X.292 (1998)). Definitions and abbreviations 1.1 Definitions For the purposes of the present document, the following definitions apply: Abstract test suite (ATS): A test suite composed of abstract test cases each of which is a complete and independent specification of the actions required to achieve a specific test purpose, defined at the level of abstraction of a particular abstract test method, starting in a stable testing state and ending in a stable testing state. Implementation: An implementation of the specification. ICS template: A template which can be used as the basis for developing an ICS proforma. Implementation conformance statement (ICS): a statement made by the supplier of an implementation claimed to conform to a given specification, stating which capabilities have been implemented. Implementation conformance statement (ICS) proforma: a document in a form of a questionnaire, which when completed for an implementation becomes an ICS. Protocol Implementation Conformance Statement (PICS): a protocol ICS. Protocol Implementation Conformance Statement (PICS) proforma: protocol ICS proforma. Specification: A specification is an approved document or a standard for which the ICS proforma and test specifications are written. Test purpose: A purpose description of a well defined objective of testing, focusing on a single conformance requirement or a set of related conformance requirements as specified in the appropriate specification. NOTE 4: Annex A of the present document contains an ICS proforma template. 1.2 Abbreviations For the purposes of the present document, the following abbreviations apply: ASN.1 Abstract Syntax Notation One ATS Abstract Test Suite ETSI European Telelcommunications Standards Institute IUT Implementation Under Test MTS Methods for Testing and Specification (ETSI committee) PDU Protocol Data Unit ICS Protocol Implementation Conformance Statement TTCN Tree and Tabular Combined Notation Prerequisites The use of the present document to write an ICS proforma assumes some initial knowledge, as indicated below. 1.3 Definition of ICS proforma and basic rules In particular, the present document does not provide the basic concepts of what an ICS proforma is, and the context in which it applies. To obtain this important information, please refer to ISO/IEC 9646-1 [2] and ISO/IEC 9646-7 [3]. Word processor knowledgeWithin the ATM Forum ICS proforma are written using Microsoft(r) Word for Windows(tm). Because there are many tables in ICS proforma with cross-references, a knowledge of the use of sequences and bookmarks in Word is strongly recommended. Structure of this style guide The main body of the guide provides rules and guidance in order to produce an ICS proforma. All subclauses deal with the production of a base specification ICS proforma. Annex A provides an ICS proforma specification template for a base specification. It is an application of the guidelines defined in the body of this style guide, and a template which can be used as a basis for producing ICS proforma specifications. Annex A contains text blocks which are intended to be incorporated into ICS proforma specifications according to the included instructions. How to write an ICS proforma An ICS proforma specification may be a part of a multi-part specification, one part containing the protocol specification and another part the ICS proforma specification. It may also be a stand alone document. If the ICS is included in the specification when specification is being written it is an annex When the ICS is developed separately, at a later date, it would be an annex added by an addendum to the specification. Annex A provides the template of an ICS proforma specification. To create an ICS proforma specification, copy the electronic version of the template into your working document, and follow the instructions. General guidelines This clause provides general guidance for ICS proforma specifiers. It summarizes the most critical rules and recommendations about ICS proforma, mainly extracted from ISO/IEC 9646-7 [3] and adds practical clarification. 1.4 Why this style guide should be followed From the point of view of an ICS proforma specifier, this style guide should be seen as a means of making the task easier and of producing a good quality ICS proforma. It is essential to harmonize the styles of the ICS proforma produced by different groups within the ATM Forum. As a consequence, the use of common notations is a very important quality criterion for an ICS proforma. The adoption of these common notations is essential to achieve good quality. 1.5 Which questions and how to structure them The purpose of an ICS proforma is to ask relevant questions. This requires a good knowledge of the reference specification and of its practical use. Producing an ICS proforma should not be seen as a totally systematic task. It may begin as a systematic search of all occurrences of "shall" to identify the mandatory capabilities and all occurrences of "should" or "may" to identify the optional capabilities which should appear in the ICS proforma. However, the occurrences of these may themselves be in error or be ambiguous. 1.5.1 Meaningful, unambiguous and useful questions Meaningful questions All questions should be meaningful, and should have one and only one meaning (i.e. no double question).. The number of questions addressing a capability should reflect its complexity. For a complex capability, more than one question is appropriate. Useful questions A useful question is a question which is in line with the objective of an ICS. The aims of an ICS are to give information for: 1) conformance testing - high-level conformance overview, test selection and test parameterization; 2) interoperability checking - what optional features were implemented. For the purpose of the conformance review, test selection and parameterization it is necessary to list mandatory capabilities, in order to check if the implementation supports them. For interoperability checking, it is important to concentrate on the optional capabilities, in order to know which ones are implemented. The objective of the ICS proforma specifier is to find a balance between these different purposes, and to be able to identify which questions are useful, and which ones are not. The next subclause gives some guidelines on the matter. The ICS specifier should be concerned about the person who is required to complete the ICS proforma and interpret the ICS. The tables produced should be useful and meaningful, in order to make the best possible use of the ICS proforma. 1.5.2 Avoiding complex questions ICS proforma questions reflecting conformance requirements in the reference standard may be simple (high-level) or complex (detailed). A well chosen set of simple questions can provide an initial level of confidence regarding likelihood of interoperability between implementations from different vendors. To make the ICS useful in this regard, ICS proforma questions should address mainly simple conformance requirements. Detailed, complex questions that require testing to answer should not appear in the ICS proforma but expressed as one or more test purposes in the corresponding Abstract Test Suite. Simple questions roughly correspond to answering: - What capabilities, messages and parameters, mandatory or optional, stated in the standard have been implemented? EXAMPLE 1: Using point-to-multipoint procedures on the UNI 3.1 network side as an example, the ICS proforma might ask the following questions: 1. Does the implementation support the SETUP message? 2. Does the implementation support SETUP Endpoint Reference Information Element? 3. Does the implementation support SETUP Broadband Bearer Capability Information Element? To formulate more complex questions it is necessary to address the behaviour of the implementation in the instance of testing. A complex question roughly corresponds to answering: - How will the implementation respond to a given stimulus? - What messages and parameters are exchanged as part of the behaviour of the implementation in support of a capability? EXAMPLE 2: Using the point-to-multipoint procedures of EXAMPLE 1, a complex question may be devised as follows: Does the IUT reject a SETUP request with cause #100 and includes both the Endpoint Reference Information Element and the Broadband Bearer Capability Information Element identifiers in the diagnostic field on receipt of a SETUP message which does not indicate point-to-multipoint in the user plane connection configuration field? Such a question is too detailed to answer without testing and is better suited for inclusion with the test purposes in the corresponding Abstract Test Suite. 1.5.3 Structure and level of detail An ICS proforma should be structured in a hierarchical manner, from general to more detailed questions. For a protocol, the structure should be: - roles; - major capabilities; - PDUs; - PDU parameters; - timers; - negotiation capabilities; - protocol error handling; - multi-specification dependencies; - other conditions. ICS proforma questions regarding PDU parameters require extra care. The two frequent mistakes are: * confusion between the absence of a parameter in a given behaviour instance and the capability to support it in other instances; * asking a global question about a parameter which can be used differently in different instances. No presence, but capability to support it. When a protocol specification defines a PDU with a number of fields, not all of these fields will be used in every behaviour scenario. However, ICS questions must ask if the implementation supports each and every field by providing a separate question for each field. A question which asks if a given field is used in a specific protocol behaviour scenario is a test purpose to be answered on execution of the corresponding behaviour test. Such a question is included in test purposes in the ATS but not in the ICS proforma. For example, in the sending direction, the support of a parameter means that the implementation is able to send this parameter but it does not mean that the implementation always sends it. In the receiving direction, it means that the implementation supports the whole semantic of the parameter including the ability to parse the PDU to extract the parameter. As a consequence, PDU parameter tables in an ICS proforma should not be the same as those in the reference specification. It is not rare to see a parameter which is optional in the syntax but mandatory in the ICS proforma. A typical example is given in subclause 8.3.1. No global questions ICS items should not reflect the capability to support the parameter globally, but should differentiate between the capability to support the parameter in each PDU, and in each direction (i.e. send/receive). A question such as "Does the implementation support the parameter "reason"?" has no meaning. Several questions need to be asked: "Does the implementation support the sending of parameter "reason" in PDU Connect?" and "Does the implementation support the receipt of parameter "reason" in PDU Connect?". NOTE1: It may happen that a PDU parameter is used on the same PDU with different semantics, in order to implement several functionalities. For such parameters, it may be clearer to have a distinct ICS question for each semantic of the parameter in the PDU. NOTE2: support for a received PDU requires the ability to parse all valid parameters of that PDU. Supporting a PDU while having no ability to parse a valid parameter is non-conformant. Support for a parameter on a PDU means that the semantics of that parameter are supported. 1.6 How to choose a status One of the difficulties in selecting the status entry arises from the fact that the reference specification itself is often ambiguous, and does not indicate directly if the implementation of a feature is mandatory, conditional or optional. Very often, the support of a feature needs to be deduced from the behaviour description in the reference specification. NOTE: The ICS proforma cannot add conformance requirements to the reference specification. The status of an item is often not determined by only one "sentence" in the reference specification. For example, to find the status of a parameter in a PDU, it is necessary to check all sections which contain a requirement related to this parameter. The different possibilities for the status are given in subclauses 8.3.1 to 8.3.7. 1.6.1 m: mandatory m: Mandatory - the capability shall be supported. EXAMPLE 1: Sentence in the reference specification: "The parameter CalledAddress shall be provided by the user in the Connect PDU if it was provided by the network." ICS proforma item: Support of CalledAddress parameter in the Connect PDU sent by the user. ICS proforma status: "mandatory" Here, an implementation is obliged to send the parameter even though the sending depends on the network behaviour. Thus the status is mandatory. 1.6.2 o: optional o: Optional - the capability may or may not be supported. It is an implementation choice. EXAMPLE: Sentence in the reference specification: "It is allowed to provide or to not provide the parameter CalledAddress in the Connect PDU." ICS proforma item: Support of CalledAddress parameter in the Connect PDU sent. ICS proforma status: "optional". 1.6.3 n/a: not applicable n/a: Not applicable - it is impossible to use the capability. No answer in the support column is required. EXAMPLE: Sentence in the reference specification: "The parameter CalledAddress in the Connect PDU is only sent by the network side, to a user destination. It is never sent to another network." ICS proforma item: Support by the network of CalledAddress parameter in the Connect received PDU. ICS proforma status: "n/a". 1.6.4 x: prohibited (excluded) x: Prohibited (excluded) - It is not allowed to use the capability. EXAMPLE: Sentence in the reference specification: "The parameter Status in the Connect PDU is only sent by the network side. It is not allowed for the user to send this parameter" ICS proforma item: Support by the user of Status parameter in the Connect sent PDU. ICS proforma status: "x". 1.6.5 c : conditional c: Conditional - the requirement on the capability ("m", "o", "n/a" or "x") depends on the support of other optional or conditional items. is the identifier of the conditional expression. EXAMPLE: Sentences in the reference specification: "The procedures related to the initiation of an outgoing call are an optional part of this specification" and later "Sending a Connect PDU is the only way to initiate an outgoing call. This PDU is only sent to initiate an outgoing call". ICS proforma item: Capability to send a Connect PDU. ICS proforma status: "c1". c1 is the identifier of the following conditional expression (for the purpose of this example, it does not exactly follow the recommended syntax): IF "outgoing call supported" THEN m ELSE n/a. NOTE: In this example, if "outgoing call" was a mandatory capability, the status of "capability to send a Connect PDU" would not be conditional, but mandatory. For more details about conditional items, refer to clause 11. 1.6.6 o.: qualified optional o. Qualified optional - for mutually exclusive or selectable options from a set. is the identifier of the group of options, and the logic of selection of the options. EXAMPLE 1: Sentence in the reference specification: "To indicate that the numbering is completed, one of the following two options shall be used: - add the "*" character at the end of the numbering; - add the "#" character at the end of the numbering." ICS proforma items: Indication of the numbering completion using "*". Indication of the numbering completion using "#". ICS proforma status of both items: "o.1: It is mandatory to support at least one of these options". The status and the logic of the option should reflect a capability and not a behaviour requirement: EXAMPLE 2: Sentence in the reference specification: "It is mandatory for an implementation to be able to clear a call. (...) To clear a call, either procedure 1 or procedure 2 shall be used." ICS proforma items: procedure 1. procedure 2. ICS proforma status of both items: "o.1: It is mandatory to support at least one of these options". In EXAMPLE 2, the reference specification does not require that the same option is chosen for all call clearings. Thus, the too restrictive requirement "It is mandatory to support exactly one of these options" should not be used in this case. Even if both procedures may not be active at the same time(dynamic requirement), it is conformant to choose procedure 1 for some calls, and procedure 2 for others. For more details about qualified optional items, refer to clause 12. 1.7 How to deal with two main roles Some reference specifications can be implemented in different roles. The choice of the ICS structure mainly depends on whether it is likely that an implementation will support only one role. In that case, it is recommended to structure the ICS proforma in two different parts, two different subclauses, each one dealing with one role. The suppliers of the implementations of the two roles are often different, belonging to different disciplines. Thus it is preferable not to complicate ICS proforma tables with the requirements of both roles. Guidelines on ICS proforma tables ICS proforma items are grouped into tables. Most ICS proforma specifications can be met using the following table format: Table A.3: Item Reference Status Conditions for status Support Does the implementation support ... 1 2 3 4 The tables are grouped into clauses and subclauses following a hierarchical structure, from general questions to detailed. Each subclause may contain one or more tables. It is recommended to accompany the tables with specific explanations when deemed useful. Explanatory text, if any, should appear before the table to which it relates. To structure items in a subclause, it is recommended to create several tables, each table dealing with a specific issue. The tables should not contain too many items (20 items should be a maximum). It will limit the re-numbering problem in case of the addition of an item. It will also ease the maintenance (refer to clause 14), because it will be more sensible to add an item at the end (all the items belong to the same topic). To allow the supplier to provide conditional answers or comments, space is provided at the bottom of the tables, after the possible conditional or optional expressions. 1.8 Table columns All tables should contain at least the following columns: item, item description, reference, status, support. All table cells should be completed by the ICS proforma specifier, except the support and supported values columns, which need to be completed by the supplier of the implementation. If deemed useful, it is possible to provide a comment in all types of cells, using a note provided at the bottom of the table. It may be used, for example, for providing an explanation about the status. Item column The item column contains an integer which identifies the item in the table. The first item of each table is "1". The numbering should be in whole integers: "1, 2, 3, 4 ..." (not "1, 1.2 , 1.3 ..."). Item description column The item description column describes each respective item. The header of this column should be meaningful, such as "Service", "Call direction", "PDU parameter" etc., and should not be only "item description" or "feature". In each row, the item description is just the name of a capability (e.g. "File directory service"), and implies the question "Does the implementation support ?" (e.g. "Does the implementation support the file directory service?"). It is not recommended to write long questions. However, each question should be complete so that an answer of "yes" is not ambiguous. Reference column The reference column contains the references to the appropriate clauses (generally of a single reference specification), which were used to determine the status of the question. It is essential to justify the value of the status, by providing all references of clauses which were used to determine it. NOTE 2: When this column contains a reference to a single reference specification standard, it is not necessary to state it explicitly (i.e. [..] is not necessary). Status column The status column specifies the status value for the item (e.g. mandatory, optional, conditional), reflecting what the support should be for conformance. Refer to subclause 8.3 "How to choose a status" for more details. Support column The support column will contain the answer made by the supplier of the implementation to indicate whether or not the implementation supports the item. The possible answers are Yes, No, N/A or Conditional.tick boxes As an aid to indicating the possible answers, the proforma shall include tick boxes. Depending on whether or not the status is conditional, the tick boxes supplied should one of the following: N/A__ Yes__ No__ or Yes__ No__ Condition for status column Conditional items are indicated in the status column by listing the relevant conditions in symbolic form. When more than one condition is listed, the choice between conditions shall be indicated by explicitly separating them by one or more "OR"; when two or more conditions are to be satisfied, the conditions shall be separated by commas, ",", with the final pair separated by an "AND". Values allowed column Values allowed may be added in the same table to reduce the total number of tables in the ICS proforma. This column contains the values, the ranges of values, the type or the length allowed by the reference specification. Figure X illustrates the technique. Table X:
Item Reference Status Conditions for status Support Does the implementation support ... A.2/3 narrowband interfaces? 2.1 m Yes__ No__ If yes, list narrowband physical layer interface types supported. 2.1.1 1. 2. 3. If yes, list narrowband CAS systems supported. 2.1.2.1 1. 2. 3. If yes, list narrowband CCS systems supported. 2.1.2.2 1. 2. 3. Note that the status value is linked to the support of the capability indicated in the item description column, and not to the values allowed. If, within the list of values, some values are mandatory while others are optional or conditional, then an extra table is required, listing each category of parameters with their status. If no extra table is provided, this means that all values are optional. There should be no questions regarding default values. Questions about default values are irrelevant in an ICS proforma. Values supported column In those cases in which it is necessary to list the values supported by the implementation, the format of Table XX can be used to list them. The value entries in the support column would be provided by the supplier of the implementation. Table XX:
Item Reference Status Conditions for status Support Does the implementation support ... 2/4 other rates? 4 m Yes__ No__ If yes, list which of the following allowed values are supported: * 1200 * 2400 * 4800 * 9600 4.1 1. 2. 3. 4. 1.9 Table types All tables of an ICS proforma should be in accordance with one basic table type specified below. For this table type, an empty model is presented, with an example to assist understanding. The column widths may be changed, but in that case, it should be done for all tables, in order to achieve a certain consistency in the style of the whole ICS proforma. When specifying an ICS proforma, one of the keys to success is "simplicity". For this reason it is recommended to use one table type, even if it will increase the number of pages of the proforma. Often, a good way to make things more simple is to split and to structure the document. Table type : EMPTY MODEL: Table A.1: Item Reference Status Conditions for status Support 1 2 3 4 EXAMPLE 1: Table A.1: Service elements Item Service Reference Status Conditions for status Support 1 T_ASSOCIATE 4.1, 6.7, 4.5 o 2 T_RELEASE 4.2, 6.7, 4.5 m 3 T_U_ABORT 4.3, 6.7, 4.5 o Guidelines on references to items For each possible answer in the support column within the ICS proforma, a unique reference exists. It may be used, for example, in the conditional expressions in the ICS proforma, or in the selection expressions of test cases in the abstract test suite (ATS). The item reference is defined as the table identifier, followed by a solidus character "/", followed by the item number in the table. EXAMPLE: A.5/4 is the reference to the answer to item 4 in table 5 of Annex A. Guidelines on conditional items Conditional items are items whose status value depends on the support of another item, optional or conditional itself. To reflect such a requirement, a simple conditional expression notation shall be used in the Conditions for Status column. Table A.6: ConnectAck sent parameters Item Parameter Reference Status Conditions for Status Support 1 RespNumber 4.5 m A, B AND C 2 Display 4.6 m A OR B OR C In the case of more complex conditions, conditional expressions may be given below the table and referenced in the Conditions for Status column. The next table is an example of the use of conditional expressions to deal with complex conditional items: EXAMPLE: Table A.6: ConnectAck sent parameters Item Parameter Reference Status Conditions for Status Support 1 RespNumber 4.5 c601 2 Display 4.6 c602 c601: IF (A.3/2 AND A.3/1) THEN m ELSE n/a -- Connect and Release c602: IF (A.3/2 OR A.3/1) THEN o ELSE n/a -- Connect or Release The condition number (in this example "601") identifies a unique conditional expression. It is recommended that the conditional expression be defined immediately following the table, in order to ease readability. However, if the same condition applies to many items of several tables (i.e. a global condition), it is possible to define the conditional expression once, at the end of the ICS proforma in a "global conditions and predicates" subclause. The numbering rule for the condition number in both cases is presented in the next subclause. 1.10 Condition number This number shall be unique in all the ICS proforma. It allows identification of a unique conditional expression. The condition number is an integer containing 2 fields:
. -
: is the number of the table in which the condition appears. - : is a unique reference of the condition in the table, of 2 digits. It has no order meaning. EXAMPLE 1: c2101 is the conditional expression "1" of table A.21. EXAMPLE 2: c211 is the conditional expression "11" of table A.2. If the conditional expression is not local to one table, but applies to several tables the numbering rule is: -
: "0" - THEN ... ELSE ... The predicate expression is a Boolean expression following the TTCN syntax (refer to ISO/IEC 9646-3 [4]), where the predicates are item references (refer to clause 10) or, only if necessary, names of predicate expressions defined at the end of the ICS proforma, in a "global conditions and predicates" subclause. 1.12 Predicate applying to a whole clause or a whole table If a whole table or all the tables of an entire clause/subclause are not applicable because some capabilities are not supported, readability is improved by a global indication that it is not required to answer the related questions, instead of using a condition for each item. In that case a prerequisite line may be used. This prerequisite line is written just below the title of the table or the clause to which it applies. This approach is useful, for example, for a PDU parameter table that is applicable only if the PDU is supported. EXAMPLE: Table A.1: ConnectAck parameters Prerequisite: A.3/2 -- ConnectAck Reference Status Conditions for Status Support 1 RespNumber 4.3, 7.3.2, 9.1 m 2 Display 4.3, 7.3.2, 9.1 o Guidelines on qualified optional items Qualified optional items allow the definition of selectable options among a set, using the notation o. (refer to subclause 8.3). EXAMPLE: Table A.2: Call directions Item Call direction Reference Status Conditions for Status Support 1 incoming call 1.2, 4.6 o.2 2 outgoing call 1.4, 4.7 o.2 o.2: It is mandatory to support at least one of these items. The recommended wording for the most common requirements is: - "It is mandatory to support at least one of these options"; - "It is mandatory to support exactly one of these options". However, other requirements are possible, for example: "It is mandatory to support exactly 3 of these 5 options". NOTE: When the word "options" is not found suitable, it may be replaced by "items". When the group of optional items belong to the same table, the logic is defined below the table. Otherwise, it should be defined at the end of the ICS proforma. In that case, the references to items which belong to the set of options should be indicated, as a comment. Each new integer identifies a new group of items of the ICS proforma, and does not only identify the logic of the option. This integer cannot be structured in the same manner as condition numbers (i.e.
), because the items may belong to different tables. Thus it follows a sequential numbering over the entire ICS proforma (1, 2, 3, 4, etc.). Guidelines on the use Microsoft(r) Word for Windows(tm) Within the ATM Forum, ICS proforma should be written using Word. One of the most critical aspects is that an ICS proforma contains many tables with many cross-references. This clause provides guidance on the use of Word to produce ICS proforma. However, it supposes a knowledge of the use of sequences and bookmarks. 1.13 How to use the electronic version of the template To ease the production of ICS proforma, the electronic version of the template contained in Annex A accompanies the present document. It is also available from http://www... The ICS proforma template should be used as a basis for producing actual ICS proforma, with the minimum set of modifications. It eases the task of ICS proforma specifiers, and harmonizes the ICS proforma produced. What to do? - get the electronic version of the template; - leave the normal text as it is, but replace "" with text specific to the actual ICS proforma, and follow the explanations and recommendations in italics; - remove the text in italics; - the table provided in the template (empty table) should be copied and pasted as required in order to create as many tables as required; - number and complete the tables in accordance with this guide. Maintenance aspects The table identifiers and item numbers should not be changed after publication of the document, because some other documents will refer to them (e.g. ATS). For this reason, the sequences and bookmarks used in the tables should be "hard coded" just before the publication, during the final editing phase. It should not be done before, because if a defect is detected before (e.g. a table is missing), the sequences and bookmarks should be still there in order to ease the correction. NOTE 2: "Hard coding" of the ICS proforma tables is normally only carried out by the publishing editor in the ATM Forum Secretariat. 1.14 How to use sequences, bookmarks in ICS proforma tables Sequences and bookmarks are useful during the production phase of an ICS proforma. They avoid tedious updating of the numbering, in case of the addition or the suppression of a table. However, to avoid unnecessary complexity, the use of sequences and bookmarks should be limited to cases where it is helpful. Excessive use of sequences and bookmarks in a document make it too complex to be managed by the ICS proforma specifier, and the limits of Word may be quickly reached. 1.14.1 Table and item numbers The table numbers are generated using a sequence field named "tab". The item numbers are generated using a sequence field named "item" and reset to one in the first row of each table. EXAMPLE: Table A.{seq tab}: Call directions Item Call direction Reference Status Conditions for Status Support {seq item \r1} incoming call 1.2, 4.6 m {seq item} outgoing call 1.4, 4.7 m 1.14.2 Conditional items Two aspects have to be considered: the condition number (i.e. c102), and the conditional expression. Condition number For a local condition number (i.e. c
): - the
part is generated using the feature "insertion of the closest sequence number" (i.e. {seq tab \c}); - because there is no order notion for the , this number does not need to be updated if a new condition is added. Thus it is not recommended to use a sequence to generate it. EXAMPLE 1: c{seq tab \c}03 Conditional expression Item references used as predicates in the conditional expressions follow the notation: A.
/.
is generated automatically, using a bookmark on the table number. should be managed manually, because the use of bookmarks would result in a large number of bookmarks which are difficult to manage and increase the size of the file. Moreover, the number in the table is more stable than the table number. The naming rule for bookmarks on tables is "tab_". EXAMPLE 2: A bookmark called "tab_Calldir" is created on {seq tab} of the Call directions table. Table A.{seq tab}: Call directions Item Call direction Reference Status Conditions for Status Support {seq item \r1} incoming call 1.2, 4.6 o {seq item} outgoing call 1.4, 4.7 o This bookmark is used in the reference to items 1 and 2 (incoming and outgoing call) in the two conditional expressions of the table below. Table A.{seq tab}: Type A PDUs Item PDU Reference Status Conditions for Status Support {seq item \r1} Connect 1.1.1 c{seq tab \c}01 {seq item} ConnectAck 1.1.2 c{seq tab \c}02 c{seq tab \c}01: IF A.{seq tab tab_Calldir}/1 THEN m ELSE n/a -- if incoming call supported then mandatory c{seq tab \c}02: IF A.{seq tab tab_Calldir}/2 THEN m ELSE n/a -- if outgoing call supported then mandatory 1.14.3 Qualified optional items The qualified optional numbers are generated using a sequence field named "opt". To refer to this number in the status column, a reference to a bookmark which is defined on the qualified number part of the option is used. The naming rule is: "opt_". EXAMPLE: A bookmark named "opt_Calldir" has been created on {seq opt} of the option below and is referred to in the status column. Item Call direction Reference Status Conditions for Status Support {seq item \r1} incoming call 1.2, 4.6 o.{seq opt opt_Calldir} {seq item} outgoing call 1.4, 4.7 o.{seq opt opt_Calldir} o.{seq opt}: It is mandatory to support at least one of these items. 1.14.4 Summary Three sequences are used: - to generate the table numbers: named "tab"; - to generate the item numbers: named "item"; - to generate the qualified optional items: named "opt". Two types of bookmarks are used: - table identifiers for item references in a conditional expression: named "tab_"; - qualified optional item references in the status column: named "opt_". NOTE: To see actual uses of sequences and bookmarks, refer to the electronic version of Annex A, using the visualization of field codes. Maintenance aspects All the previous clauses of this style guide deal with the production of an ICS proforma. However, it is important to think about the future of the ICS proforma that has been produced, and in particular about maintenance aspects. Because other documents, such as ATS and profile requirement lists, refer to items of ICS proforma, it is necessary to keep these references unchanged, from one version to another. The item references contain the identifier of the table, therefore the table identifiers should not be modified after publication of the ICS proforma. See clause 14 to know the impact on sequences and bookmarks. The following maintenance rules are commonly adopted by the ATM Forum: a) if tables are added between two existing tables, the table identifiers of the new tables should be a, b, c etc. (see example 1); b) if a table is deleted, then it should replaced by the following text: "Deleted table" (see example 2); c) if an item is added, it should be added at the end of the table (because a, b, c notation is already used for referring to the different support columns in case of multiple support columns); d) if an item is removed, the row should stay, with "item deleted" in "item description" column. EXAMPLE 1: ConnectAck and ConnectRej are new tables. Table A.1: Connect Item Parameter Reference Status Conditions for Status Support 1 par1 o 2 par2 o Table A.1a: ConnectAck Item Parameter Reference Status Conditions for Status Support 1 par1 o 2 par2 m Table A.1b: ConnectRej Item Parameter Reference Status Conditions for Status Support 1 par1 m 2 par2 o Table A.2: Release Item Reference Status Conditions for Status Support 1 par1 o 2 par2 o EXAMPLE 2: Table 2 has been deleted. Table A.1: Connect Item Parameter Reference Status Conditions for Status Support 1 par1 o 2 par2 o Table A.2: Table deleted Table A.3: Release Item Parameter Reference Status Conditions for Status Support 1 par1 o 2 par2 m Annex A: Template of an ICS proforma specification A.1 Conventions Conventions used in this template: - the text provided for guidance for the ICS proforma specifier is in italics. It should not be included in the actual ICS proforma; - the text provided in brackets i.e. , should be replaced by the relevant text in the actual ICS proforma: EXAMPLE: "This provides the Protocol Implementation Conformance Statement" might be replaced by "This AF provides the Protocol Implementation Conformance Statement ...". stands for the specification for conformance against which the ICS proforma is written (i.e. the protocol). In particular: - is the protocol; - is the identifier of the reference specification; - is the entire title of the reference specification; - is the reworded title of the reference specification. For example, in the case of an ICS proforma, contained in a stand-alone specification, and written for the protocol described in AF-SIG-0061.000 whose title is "The ATM Forum Technical Committee; ATM User-Network Interface (UNI) Signalling Specification; User Side; Version 4.0": - is "protocol"; - is "AF-SIG-0061-000"; - is "The ATM Forum Technical Committee; ATM User-Network Interface (UNI) Signalling Specification; User Side protocol; Version 4.0 "; - is "ATM UNI 4.0 Signalling (User Side)". A.2 The Template The remaining pages are the ICS proforma template. Protocol Implementation Conformance Statement (ICS) Proforma Specification Copyright release for ICS proforma: This ICS proforma may be freely reproduced, so that it may be used for its intended purpose. ICS Proforma for (c) 1999 by The ATM Forum. This specification/document may be reproduced and distributed in whole, but (except as provided in the next sentence) not in part, for internal and informational use only and not for commercial distribution. Notwithstanding the foregoing sentence, any protocol implementation conformance statements (PICS) or implementation conformance statements (ICS) contained in this specification/document may be separately reproduced and distributed provided that it is reproduced and distributed in whole, but not in part, for uses other than commercial distribution. All other rights reserved. Except as expressly stated in this notice, no part of this specification/document may be reproduced or transmitted in any form or by any means, or stored in any information storage and retrieval system, without the prior written permission of The ATM Forum. The information in this publication is believed to be accurate as of its publication date. Such information is subject to change without notice and The ATM Forum is not responsible for any errors. The ATM Forum does not assume any responsibility to update or correct any information in this publication. Notwithstanding anything to the contrary, neither The ATM Forum nor the publisher make any representation or warranty, expressed or implied, concerning the completeness, accuracy, or applicability of any information contained in this publication. No liability of any kind shall be assumed by The ATM Forum or the publisher as a result of reliance upon any information contained in this publication. The receipt or any use of this document or its contents does not in any way create by implication or otherwise: • Any express or implied license or right to or under any ATM Forum member company's patent, copyright, trademark or trade secret rights which are or may be associated with the ideas, techniques, concepts or expressions contained herein; nor • Any warranty or representation that any ATM Forum member companies will announce any product(s) and/or service(s) related thereto, or if such announcements are made, that such announced product(s) and/or service(s) embody any or all of the ideas, technologies, or concepts contained herein; nor • Any form of relationship between any ATM Forum member companies and the recipient or user of this document. Implementation or use of specific ATM standards or recommendations and ATM Forum specifications will be voluntary, and no company shall agree or be obliged to implement them by virtue of participation in The ATM Forum. The ATM Forum is a non-profit international organization accelerating industry cooperation on ATM technology. The ATM Forum does not, expressly or otherwise, endorse or promote any specific products or services. NOTE: The user's attention is called to the possibility that implementation of the ATM interoperability specification contained herein may require use of an invention covered by patent rights held by ATM Forum Member companies or others. By publication of this ATM interoperability specification, no position is taken by The ATM Forum with respect to validity of any patent claims or of any patent rights related thereto or the ability to obtain the license to use such rights. ATM Forum Member companies agree to grant licenses under the relevant patents they own on reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain such a license. For additional information contact: The ATM Forum Worldwide Headquarters 2570 West El Camino Real, Suite 304 Mountain View, CA 94040-1313 Tel: +1-650-949-6700 Fax: +1-650-949-6705 1 Introduction An Introduction clause shall be present and shall contain at least the following text: To evaluate conformance of a particular implementation, it is necessary to have a statement of which capabilities and options have been implemented for a telecommunication specification. Such a statement is called an Implementation Conformance Statement (ICS). 1.1 Scope In addition to the text according to the skeleton, the following text shall be included: The present document provides the Implementation Conformance Statement (ICS) proforma for the defined in in compliance with the relevant requirements, and in accordance with the relevant guidance given in ISO/IEC 9646-7. 1.2 References Include the following normative references: [1] . [2] ISO/IEC 9646-1: 1994, Information technology - Open Systems interconnection - Conformance testing methodology and framework - Part 1: General concepts (see also ITU-T Recommendation X.290 (1995)). [3] ISO/IEC 9646-7: 1995, Information technology - Open Systems interconnection - Conformance testing methodology and framework - Part 7: Implementation Conformance Statements (see aslo ITU-T Recommendation X.296 (1995)). [4] ISO/IEC 9646-3: 1998, Information technology - Open Systems interconnection - Conformance testing methodology and framework - Part 3: The Tree and Tabular Combined Notation (TTCN) (see also ITU-T Recommendation X.292 (1998)). 1.3 Definitions Include the following text and definitions: - terms defined in ; - terms defined in ISO/IEC 9646-1 and in ISO/IEC 9646-7 . In particular, the following terms defined in ISO/IEC 9646-1 apply: Implementation Conformance Statement (ICS): A statement made by the supplier of an implementation or system claimed to conform to a given specification, stating which capabilities have been implemented. ICS proforma: A document, in the form of a questionnaire, which when completed for an implementation or system becomes an ICS. 1.4 Abbreviations The abbreviations subclause shall contain at least the following entries: ASN.1 Abstract Syntax Notation One ATS Abstract Test Suite IUT Implementation Under Test SUT System Under Test ICS Implementation Conformance Statement 1.5 Conformance The conformance clause is a clause which concerns the ICS proforma and completed ICS themselves and not the implementation. This clause restricts what is allowed to be an ICS proforma which conforms to this ICS proforma specification. According to ISO/IEC 9646-7 [3], this clause shall not restrict natural language (an ICS proforma with questions translated into another language is still compliant with the ICS proforma specification), or pagination. If no special reason exists, it is not recommended to add restrictions to the following text. The conformance clause shall contain at least (and probably only) the following text: This ICS does not modify any of the requirements detailed in . In case of apparent conflict between the statements in the base specification and the annotations of "M" (mandatory) and "O" (optional) in this ICS, the text of the base specification takes precedence. For each protocol implementation for which conformance is claimed to the ATM Forum , the supplier is required to complete a copy of the ICS proforma provided in this document and is required to provide the information necessary to identify both the supplier and the implementation. 2 Identification of the Implementation Identification of the Implementation Under Test (IUT) and the system in which it resides (the System Under Test (SUT)) should be filled in so as to provide as much detail as possible regarding version numbers and configuration options. The product supplier information and client information should both be filled in if they are different. A person who can answer queries regarding information supplied in the ICS should be named as the contact person. 2.1 Date of the statement 2.2 Implementation Under Test (IUT) identification IUT name: IUT version: 2.3 System Under Test (SUT) identification SUT name: Hardware configuration: Operating system: 2.4 Product supplier Name: Address: Telephone number: Facsimile number: E-mail address: Additional information: 2.5 Client (if different from product supplier) Name: Address: Telephone number: Facsimile number: E-mail address: Additional information: 2.6 ICS contact person (A person to contact if there are any queries concerning the content of the ICS) Name: Telephone number: Facsimile number: E-mail address: Additional information: 2.7 Identification of the This ICS proforma applies to the following standard: (): "". If the ICS proforma applies for amendments of the reference specification, this fact should be reflected here. 3 The ICS Proforma 3.1 Global statement of conformance Are all mandatory capabilities implemented? (Yes/No) NOTE: Answering "No" to this question indicates non-conformance to the specification. Non-supported mandatory capabilities are to be identified in the ICS, with an explanation of why the implementation is non-conforming, on pages attached to the ICS proforma. 3.2 Instructions for completing the ICS proforma The supplier of the implementation shall complete the ICS proforma in each of the spaces provided. In particular, an explicit answer shall be entered, in each of the support column boxes provided, using the specified notation. The support column shall be filled in by the supplier of the implementation. The following notations, defined in ISO/IEC 9646-7 , are used for the support column: Y or y supported by the implementation. N or n not supported by the implementation. N/A, n/a or - no answer required (allowed only if the status is n/a, directly or after evaluation of a conditional status). The following notations, defined in ISO/IEC 9646-7, are used for the status column: m mandatory - the capability is required to be supported. o optional - the capability may be supported or not. n/a not applicable - in the context, it is impossible to use the capability. x prohibited - there is a requirement not to use the capability in the given context. o.i qualified optional - for mutually exclusive or selectable options from a set. "i" is an integer which identifies an unique group of related optional items and the logic of their selection which is defined immediately following the table. The following table should be copied and pasted required number of times when developing the ICS proforma. Table A.1: Item Reference Status Conditions for Support Support 1 Yes__ No__ N/A__ 2 Yes__ No__ N/A__ 3 Yes__ No__ N/A__ 4 Yes__ No__ N/A__ 4 History INDEX abbreviations iii, 4, 5, 35 Abstract Test Suite 5, 8, 35 ASN.1 5, 35 ATM i, ii, 1, 2, 5, 6, 22, 26, 28, 32, 33, 36 ATS 4, 5, 9, 18, 22, 25, 35 basic rules iii, 5 bookmarks iv, 5, 22, 23, 24, 25 CCS 16 Condition for status column 16 condition number 19, 20, 21, 23 Condition number iv, 19, 23 conditional expressions 18, 19, 23, 24 conditional items iv, 12, 18, 19 definitions 4, 35 ETSI 1, 5 ICS template 4 implementation i, 2, 4, 7, 8, 9, 10, 11, 13, 14, 15, 16, 17, 32, 34, 35, 36, 39 Implementation Conformance Statement i, 2, 3, 4, 5, 28, 31, 34, 35 ISO 3, 5, 6, 20, 34, 35, 36, 39 item column 15 Item column 15 item description column 15, 17 Item description column 15 ITU-T Recommendation 3, 34 IUT iv, 5, 8, 35, 36, 37 level of detail iii, 8 maintenance aspects 25 PICS i, 2, 4 predicate 20 Protocol Implementation Conformance Statement 1, 4, 5, 28, 31, 34, 35 qualified optional items iv, 13, 21, 25 reference column 15 Reference column 15 sequences iv, 5, 22, 23, 25 specification i, iv, 1, 4, 6, 7, 9, 10, 11, 12, 13, 15, 16, 28, 31, 32, 34, 35, 36, 38, 39 Specification 1, 3, 4, 5, 28, 31 status column 2, 15, 16, 24, 25, 39 Status column 15, 18, 19 style guide iii, 1, 6, 25 Table column iii, 14 Template of an ICS proforma iv, 28 test purpose 4, 8, 9 too many items 14 TTCN 3, 5, 20, 34 useful questions iii, 7 user i, 8, 10, 11, 12, 32 User i, 8, 10, 11, 12, 28, 32 Values allowed column 16 Values supported column 17 32 ATM Forum Technical Committee af-test-0137.000 ICS Proforma Style Guide ICS Proforma Style Guide af-test-0137.000 5 ATM Forum Technical Committee