WPCM 2%.B pz W"S^11>bbu"::Dg1:11bbbbbbbbbb11gggbuuuk1Xubuukuuuk111Rb:bbXbb1bb''X'bbbb:X1bXXXX;.;g:=::m:::mmmmm::::::mm:k1mubububububXubububub11111111bbbbbbbbbuXubbkbuXmmmmumububXXXXbububububbmbbbbbb:k:k::=kmmX:uXb'b:b:b:b'bmbbbb:::uXuXuXuXk:k:k:mbbbmbuXkXkXKQmmmm^b:kbbbbmbA@mmbmmbmmmmmmm:b:mmmbbmmmmmmmmmmmmXXmmmmmmmmmmmmmmmmmmcm`m`mm`m:mmmmmm}}}mjjmmmmmmmmmmmmmmm0mm}mmmmmmmmmmmmmmmmmmmmmmm}Mmmmmmmmmmmmmjmmmtmmmmmmmmm`'mmm`mmjmlWmmmmmmmmmmmmmmmmmmmW`mmmmjmM-lvetica#|x`H1`D4PkCQMS PS Jet Plus /800 II QPJPII.PRSPl`D4PkCg2W_ qr|xHelveticaCourier@ ,`H1`D4PkCmQrrr r  @C2K ` X` hp x (#%'H   x|@  3'3'Standard6'6'StandardC6QMS $=R- Xt2  ` `  <  <AP IX43E < XXt  ` `  <  <AP IX43E < X :cm (3184)  : (3184)    < ANNEX A <(to Recommendation X.290, Part 1) <Options  `  A.1HOptions are those items in a Recommendation* for which the implementor may make a choice regarding the item to suit the implementation. A.2HSuch a choice is not truly free. There are requirements which specify the conditions under which the option applies and the limitations of the choice. HConversely, there may be mandatory or conditional requirements, or prohibitions, in a Recommendation* which are dependent on the choice made or on a combination of the choices already made. A.3HThe following are examples of options and associated requirements; the list is not exhaustive: HHa)  "Boolean" options: the option is "do or do not do"; the DArequirement is "if do, then do as specified."%H  H HHb)  Mutually exclusive options: the requirement is to do just 1 of n  actions, the option is which of them to do.Ɛ$H  H`   `  HHc)  Selectable options: the option is to do any m out of n actions, L "Hwith a requirement to do at least one action (1<m<n and n>2).$H  `   ` 8 A.4HOptions may apply to anything within the scope of a Recommendation* (e.g. static or dynamic aspects, use or provision of a service, actions to be taken, presence/absence or form of parameters, etc.). A.5HAnother type of distinction is between serviceuser options and serviceprovider options. A.6HIn a wider context, the choice will be determined by conditions which lie outside the scope of the Recommendation* (e.g. other Recommendations* which apply to the implementation, the protocols used in the (N+1) and (N1) layers, the intended application, conditions of procurement, target price for the implementation, etc.). However, these have no bearing on conformance to the Recommendation* in which the option appears. "ANNEX B (to Recommendation X.290, Part 2) & Guidance for protocol Recommendations* writers to facilitate conformance testingă B.1HIntroduction  8X HThis annex gives guidance, primarily for the specifiers of new protocol Recommendations*, to facilitate conformance testing by ensuring a very clear understanding of the conformance requirements.  N*ԌB.2HGuidance on scope and field of application B.2.1HPrecision in the scope and field of application sections sets the tone for precision in the rest of the Recommendation*. The requirements stated in the Recommendation* should be consistent with the scope and field of application and vice versa. B.2.2HThe scope should distinguish clearly between the following three types of information included in the protocol Recommendation*:  X HHa)  the definition of the procedures for communication to be followed N#Jat the time of communication;%H  `   `  HHb)  requirements to be met by suppliers of implementations of the  procedures;(#H  `  HHc)  guidance on how to implement the procedures.xH  `  HGuidance on how to implement the procedures does not constitute additional requirements nor does it have any bearing on conformance. If such guidance is included, the scope should make these points and indicate how guidance can be distinguished from the requirements of the Recommendation*. This distinction is much easier to make if guidance is separated from requirements. The recommended method of such separation in the ISO Directives is to place guidance in notes and annexes. B.2.3HIt should be clear to whom the Recommendation* applies. B.2.4HIt should be clear at what time the Recommendation* applies.  X HProtocol procedures apply between pairs of communicating parties at the time of communication. If there might be any ambiguity over which communicating parties are involved, this should be resolved in the scope. HIt is best if protocol Recommendations* are written in such a way that the requirements are to be met by a single communicating party (the "first" communicating party for this purpose) for the benefit of one or more other communicating parties (the "second" communicating parties). Then when two (or more) communicating parties are all expected to communicate in conformance with the Recommendation*, the Recommendation* is first applied to one party, treating it as the "first" one, and then to the other(s) in turn. This ensures that if the procedures are violated, it is clear which party is at fault. B.2.5HIf any guidance is given about factors which are not standardized definitively, the scope should make it clear that any such guidance can be ignored without affecting conformance. B.2.6HThe aspects which are excluded from the scope should be identified clearly. HNot all factors relevant to the procedures or to products which implement them need to be standardized; indeed it is often desirable to leave some implementor freedom. For instance, it may be desirable to omit in a protocol Recommendation* any requirements for explicit values of timeouts, but to give guidance instead. HThe scope should make it clear which aspects are standardized definitively, which are covered by guidance but not by any requirements, and which are excluded from consideration by the Recommendation*. Any aspects which one might think would be covered, on the basis that they are closely related to aspects which are N* standardized, need explicit mention. B.2.7HAll options should, if possible, be identified clearly in the scope. HOptions are one of the most troublesome, but unfortunately necessary parts of protocol Recommendations*. They fall somewhere between what is standardized and what is not. They will be covered in greater depth below. At this point, what is important is that options are not buried deep inside the Recommendation* but are declared clearly at the beginning. If the number and detailed nature of the options makes this impractical, one should seriously ask whether such complexity is really necessary. Can detailed options be grouped together in some way (e.g. classes) to simplify the Recommendation*? B.2.8HThe scope and field of application should be reviewed after considering the rest of the Recommendation*. HIt is often not possible to satisfy some of the above suggestions until the rest of the Recommendation* has been considered. Therefore, it is generally necessary to return to the scope, to check that it really does agree with the contents of the Recommendation*. It is common to find that sections quite outside the scope have found their way in. B.3HGuidance on references B.3.1HOSI protocol Recommendations* should refer to the OSI reference model, the relevant service Recommendations* and to any relevant Recommendations* for protocol conventions, guidelines, or formal description techniques. B.3.2HIt should be made clear whether conformance to the protocol Recommendation* requires conformance to any part of any other Recommendation*. B.3.3HIt should be made clear whether each reference is to a particular version of the referenced Recommendation* or to each successive version. HNormally, the latest version is required, but this can cause problems as changes to the other Recommendation* might affect conformance to this Recommendation*. B.4HGuidance on requirements and options B.4.1HThe status of every requirement should be unambiguous. HSince optional and conditional requirements are so common, there is a tendency to interpret everything which can be interpreted as optional as being optional. B.4.2HIt should be possible for an instance of communication to conform with all the mandatory dynamic conformance requirements. B.4.3HThe conditions under which conditional requirements apply should be spelt out clearly. B.4.4HIt should not be impossible for the implementor or supplier to know what these conditions are. B.4.5HThere should be no possibility of confusion between what is optional dynamically and what is optional statically.  N*ԌHThere may be mandatory static conformance requirements for the support of features whose use at the time of communication is optional. Conversely, a message whose use is mandatory in a given context at the time of communication may be part of a protocol mechanism whose support is optional statically. B.4.6HIf the Recommendation* contains a "shopping list" of options, and there are restrictions on the allowed combinations of such options, then the restrictions should be specified clearly. These should include identification of any mutual exclusions and any minimum and maximum limits to the allowed range of options. B.4.7HIf the Recommendation* does not give any rules for selection of options, it should be made clear in the scope that only the total range and individual options are standardized, but not the selection. B.4.8HLegitimizing options should be avoided. These are options which allow alternative and incompatible versions of the same thing to claim conformance to the same Recommendation*. While they do not of themselves prevent an objective understanding of conformance, they may frustrate the aims of OSI. B.4.9HThere should be no options which give the implementor permission to ignore important requirements of the Recommendation*. Such options devalue the Recommendation* and the meaning of conformance to it. B.4.10HIf there are prohibitions in the Recommendation*, they should be sufficiently precise to be meaningful. HMany Recommendations* have sections which say in effect "do all of this and nothing else". Such prohibitions may be meaningless, because every protocol conveys some information which is not standardized, the socalled "user data", and every standardized product has attributes which are not standardized, e.g. weight. It may be difficult to draw a clear objective line between things the Recommendation* cannot forbid and those which the writers of the Recommendation* want to forbid, unless the prohibitions are stated explicitly. B.5HGuidance on Protocol Data Units B.5.1HThe permitted set of PDU types and parameter encodings should be stated clearly. B.5.2HThe permitted range of values should be stated clearly for each parameter. B.5.3HAll values, which fall outside the stated permitted range, should be stated explicitly to be invalid. HIf not, some people will argue that such values are undefined but allowed, whilst others will argue that they are invalid. B.5.4HIt should be clear whether or not undefined PDU types are allowed. HIt is safer if all undefined PDU types are declared to be invalid. B.5.5HCritical undefined values should be mentioned explicitly in the scope as being undefined. B.5.6HThere should be a defined procedure to be followed by the first communicating party in each case of it receiving an invalid or undefined PDU type or parameter.  N*ԌB.5.7HIt should be possible to detect whether the defined procedure has been followed in such cases. If it is not, then it should be because it does not matter. HSometimes the procedure to be followed upon receipt of an invalid PDU is intentionally the same as when some valid PDUs are received in the same circumstances. For example, the procedure might be to do nothing until one specific type of PDU is received, everything else being ignored. In such cases, it probably does not matter that the error has apparently gone undetected. In some other cases, the intention may be that error cases should be given special treatment, but that the procedure has been poorly chosen with the result that it cannot be distinguished from the action in nonerror cases. B.5.8HIf, in the encoding of PDUs, there are any fields declared to be reserved, then there should be a clear statement of what values, if any, are allowed or disallowed in these fields. B.5.9HIf interrelated parameters can be carried on separate PDUs, then the set of permitted relationships between the values of these parameters should be precisely and clearly defined.  Xx B.5.10HIf the parameter encoding allows for parameters to be specified in any order, and the PDU format places restrictions on the permitted orders, then these restrictions should be clearly stated. It should be recognized that if many different orders are permitted, then a large representative sample of different orders ought to be tested. The added complexity of testing conformance should, therefore, be adequately compensated by some advantage in allowing this freedom. B.5.11HThe order in which the bits, octets, etc. should be carried in the underlying protocol should be stated clearly. HFor example, should a two octet integer travel most or least significant octet first? It is surprising how often such simple causes of ambiguity are overlooked. B.5.12HThe relationship between SDUs and PDUs should be defined clearly. B.6HGuidance on states B.6.1HProtocol procedures are often defined using a finite state approach, whether formalized or not. The specification of these states is often incomplete. B.6.2HEach state should be defined clearly. B.6.3HIf there are events which can only occur in a subset of the possible states, then possible occurrence of an event should be distinguished from valid occurrence. B.6.4HThe required actions and state transitions should be defined for each possible state/event pair. In particular, they should be defined for possible but invalid state/event pairs. B.7HGuidance on Formal Description Techniques B.7.1HThe following requirements apply only to those Recommendations* which include a formal description. Precise, unambiguous Recommendations* can be written without the aid of a formal description technique (FDT), but in complex Recommendations* such as protocols formal descriptions are highly recommended. It should, however, be realized that they can create problems themselves in relation to conformance. B.7.2HIt should be clear whether the formal description forms an essential part of the Recommendation* or is provided only for guidance. N*Ԍ HIt is very important to have a clear understanding of the status of the formal description. Ideally there should be no discrepancies between the text and the formal description, but because this is very difficult to achieve in practice it is important that the reader knows which takes precedence. If the formal description is provided only for guidance, it cannot define conformance requirements. B.7.3HThe FDT should be welldefined, stable and properly referenced. B.7.4HIf the formal description defines requirements, but not all the requirements of the Recommendation*, then it should be stated clearly that the text includes requirements which are not covered by the formal description and these additional requirements should be identified clearly. B.7.5HIf the formal description defines requirements, and it also defines an allowed way of implementing some aspects of the protocol, but there is intended to be freedom for the implementor to implement those aspects in some other way, then this constitutes overdefinition. This is all too common in formal descriptions, and creates difficulties in relation to conformance. If the formal description is an essential part of the Recommendation*, then text should be provided to qualify it, indicating where such overdefinition exists and what the real requirements are.  HThe problem usually arises because the formal description describes the internal behaviour of an idealized implementation, rather than the observable external behaviour that is required. It is only the observable external behaviour which can be tested, and therefore it is only this which should constitute requirements for conformance purposes. It may well be that a different FDT should be used for defining the requirements from that used to provide guidance to implementors. B.8HMiscellaneous guidance B.8.1HInformation which may appear obvious should nevertheless be stated. HIf something is omitted because it is "obvious", some readers will assume it is required because it is "obvious", but others will assume that it is omitted to provide freedom for implementors. For example, does the existence of a checksum imply that it has to be checked? 'ANNEX C (to Recommendation X.290, Part 2) Incomplete static conformance requirements C.1HAs a matter of historical record, the development of protocol Recommendations* has been undertaken in parallel with the determination of the meaning of conformance, and in particular with the gaining of understanding of the distinction between static and dynamic conformance. C.2HTherefore, some early protocol Recommendations* will not give a complete specification of the requirements for static conformance. Typical of the incompleteness is the requirement to support a particular function without saying whether this applies to sending, receiving or both; or the absence of precise conditions of detection of protocol errors in received incoming messages. C.3HAccordingly, there may be different interpretations of what a conforming implementation is. C.4HIn future Recommendations* or at the time of revision of existing Recommendations* it will be necessary to provide a thorough specification of static conformance requirements. This would include the specification of conditions applicable to the implementation or nonimplementation of everything that is neither always mandatory nor always optional. C.5HIn the short term, it is essential that, at very least, current drafts are modified to clarify the present situation: it is not considered acceptable that Recommendations* should be issued in a form in which implementation requirements suffer from extensive ambiguity. Consideration also needs to be given to what should be done where the protocols have already reached the status of ISO International Standard or CCITT Recommendation. C.6HNo other shortterm solution is seen other than to accept and state clearly that all capabilities not covered explicitly in the static conformance requirements are optional; and to minimize the potential problems that this may cause by specifying that: Ha)  only implementations which  N*ԌH 1)implement everything that is explicitly specified as Hmandatory; and H 2)do not omit anything unless it is explicitly stated to be K!Hoptional, even though there may be a general clause of the =r:sort "if not specified, then optional";`' Hare to be designated as "conforming" without qualification; Hb)  any implementation which `' H 1)implements everything that is explicitly specified as G Dmandatory; and`' H 2)omits things which are not explicitly stated to be DAoptional, perhaps because of a general clause of the sort 4p2"if not specified then optional";`' Hshall be described as conforming to a subset. C.7HImplementations which omit anything that is mandatory do not conform at all. Note A system conforming without qualification will not necessarily interwork with another system, nor will it necessarily work better than a system conforming to a subset. The "perfect" system may refuse from other systems PDUs which it would consider as incorrect or incomplete. Thus, it may reject or abort connections. HTherefore, special consideration should be given to conformance with respect to the detection of protocol errors, especially when this detection can be explicitly or implicitly optional.  N*Ԍ 9:;? (3184) CCITT\APIX\DOC\043E5.TXS 98:&H(3184) CCITT\APIX\DOC\043E5.TXS 8    + Ԍ