Over the last couple of weeks there have been discussions in several mailinglists on the interpretation of some of the ASN.1 in H.450.1. One of the discussions is about the "inheritance of extension markers". The following definitions are from H.450.1: InvokeIdSet INTEGER ::= {InvokeIDs,...} InvokeIDs ::= INTEGER (0..65535) InvokeId ::= INTEGER Invoke {InvokeId:InvokeIdSet, OPERATION:Operations} ::= SEQUENCE { invokeId InvokeId (InvokeIdSet) (CONSTRAINED BY {-- must be unambiguous --} ! RejectProblem : invoke-duplicateInvocation), linkedId InvokeId (CONSTRAINED BY {-- must identify an outstanding operation --} ! RejectProblem : invoke-unrecognizedLinkedId) (CONSTRAINED BY {-- which has one or more linked operations--} ! RejectProblem : invoke-linkedResponseUnexpected) OPTIONAL, opcode OPERATION.&operationCode ({Operations} ! RejectProblem : invoke-unrecognizedOperation), argument OPERATION.&ArgumentType ({Operations} {@opcode} ! RejectProblem : invoke-mistypedArgument) OPTIONAL } In the above, invokeId is defined as being of the type InvokeId, but constrained by InvokeIdSet. InvokeIdSet, however has an extension marker in its definition and it is not clear whether this extension marker is inherited by the definition of invokeId. I.e. could the definition of invokedId be replaced by a) "invokeId INTEGER (0..65535)" or by b) "invokeId INTEGER (0..65535, ...)" 47.4/X.680 (12/97 version) states: "If a type defined with an extensible constraint is referenced in a "ContainedSubtype", the newly defined type does not inherit the extension marker or any of its extension additions. If the newly defined type is meant to be extensible, then an extension marker shall be explicitly added to its "ElementSetSpecs"." Applying this rule to the definition of invokeId would now first seem to raise the question as to whether this definition should be treated as a type definition or not. If so, the extension marker is not inherited. Otherwise, the situation is still unclear. Regards, Frank Derks