ISO/IEC 8824-3:2015
(Main)Information technology — Abstract Syntax Notation One (ASN.1): Constraint specification — Part 3:
Information technology — Abstract Syntax Notation One (ASN.1): Constraint specification — Part 3:
ISO/IEC 8824-3:2015 is part of Abstract Syntax Notation One (ASN.1) and provides notation for specifying user-defined constraints, table constraints, and contents constraints.
Technologies de l'information — Notation de syntaxe abstraite numéro un (ASN.1): Spécification des contraintes — Partie 3:
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 8824-3
Fifth edition
2015-11-15
Information technology — Abstract
Syntax Notation One (ASN.1): Constraint
specification
Technologies de l'information — Notation de syntaxe abstraite numéro
un (ASN.1): Spécification des contraintes
Reference number
ISO/IEC 8824-3:2015(E)
©
ISO/IEC 2015
---------------------- Page: 1 ----------------------
ISO/IEC 8824-3:2015(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2015
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any
means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission.
Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.
ISO copyright office
Case postale 56 CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2015 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 8824-3:2015(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
This fifth edition cancels and replaces the fourth edition of ISO/IEC 8824-3:2008 which has been technically
revised. It also incorporates ISO/IEC 8824-3:2008/Cor.1:2014.
ISO/IEC 8824-3 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology
Subcommittee SC 6, Telecommunications and information exchange between systems, in collaboration with
ITU-T. The identical text is published as ITU-T X.682 (08/2015).
© ISO/IEC 2015 – All rights reserved iii
---------------------- Page: 3 ----------------------
I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n
ITU-T X.682
(08/2015)
TELECOMMUNICATION
STANDARDIZATION SECTOR
OF ITU
SERIES X: DATA NETWORKS, OPEN SYSTEM
COMMUNICATIONS AND SECURITY
OSI networking and system aspects – Abstract Syntax
Notation One (ASN.1)
Information technology – Abstract Syntax
Notation One (ASN.1): Constraint specification
Recommendation ITU-T X.682
---------------------- Page: 4 ----------------------
ITU-T X-SERIES RECOMMENDATIONS
DATA NETWORKS, OPEN SYSTEM COMMUNICATIONS AND SECURITY
PUBLIC DATA NETWORKS
Services and facilities X.1–X.19
Interfaces X.20–X.49
Transmission, signalling and switching X.50–X.89
Network aspects X.90–X.149
Maintenance X.150–X.179
Administrative arrangements X.180–X.199
OPEN SYSTEMS INTERCONNECTION
Model and notation X.200–X.209
Service definitions X.210–X.219
Connection-mode protocol specifications X.220–X.229
Connectionless-mode protocol specifications X.230–X.239
PICS proformas X.240–X.259
Protocol Identification X.260–X.269
Security Protocols X.270–X.279
Layer Managed Objects X.280–X.289
Conformance testing X.290–X.299
INTERWORKING BETWEEN NETWORKS
General X.300–X.349
Satellite data transmission systems X.350–X.369
IP-based networks X.370–X.379
MESSAGE HANDLING SYSTEMS X.400–X.499
DIRECTORY X.500–X.599
OSI NETWORKING AND SYSTEM ASPECTS
Networking X.600–X.629
Efficiency X.630–X.639
Quality of service X.640–X.649
Naming, Addressing and Registration X.650–X.679
Abstract Syntax Notation One (ASN.1) X.680–X.699
OSI MANAGEMENT
Systems management framework and architecture X.700–X.709
Management communication service and protocol X.710–X.719
Structure of management information X.720–X.729
Management functions and ODMA functions X.730–X.799
SECURITY X.800–X.849
OSI APPLICATIONS
Commitment, concurrency and recovery X.850–X.859
Transaction processing X.860–X.879
Remote operations X.880–X.889
Generic applications of ASN.1 X.890–X.899
OPEN DISTRIBUTED PROCESSING X.900–X.999
INFORMATION AND NETWORK SECURITY X.1000–X.1099
SECURE APPLICATIONS AND SERVICES X.1100–X.1199
CYBERSPACE SECURITY X.1200–X.1299
SECURE APPLICATIONS AND SERVICES X.1300–X.1399
CYBERSECURITY INFORMATION EXCHANGE X.1500–X.1599
CLOUD COMPUTING SECURITY X.1600–X.1699
For further details, please refer to the list of ITU-T Recommendations.
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO/IEC 8824-3
RECOMMENDATION ITU-T X.682
Information technology – Abstract Syntax Notation One (ASN.1):
Constraint specification
Summary
Recommendation ITU-T X.682 | ISO/IEC 8824-3 provides the ASN.1 notation for the general case of constraint and
exception specification by which the data values of a structured data type can be limited. The notation also provides for
signalling if and when a constraint is violated.
History
*
Edition Recommendation Approval Study Group Unique ID
1.0 ITU-T X.682 1994-07-01 7 11.1002/1000/3044
2.0 ITU-T X.682 1997-12-12 7 11.1002/1000/4445
2.1 ITU-T X.682 (1997) Technical Cor. 1 2000-03-31 7 11.1002/1000/5047
2.2 ITU-T X.682 (1997) Technical Cor. 2 2001-02-02 7 11.1002/1000/5334
2.3 ITU-T X.682 (1997) Technical Cor. 3 2001-03-15 7 11.1002/1000/5434
3.0 ITU-T X.682 2002-07-14 17 11.1002/1000/6087
4.0 ITU-T X.682 2008-11-13 17 11.1002/1000/9606
4.1 ITU-T X.682 (2008) Cor. 1 2014-03-01 17 11.1002/1000/12145
5.0 ITU-T X.682 2015-08-13 17 11.1002/1000/12481
*
To access the Recommendation, type the URL http://handle.itu.int/ in the address field of your web browser, followed by the
Recommendation's unique ID. For example, http://handle.itu.int/11.1002/1000/11830-en.
Rec. ITU-T X.682 (08/2015) i
---------------------- Page: 6 ----------------------
FOREWORD
The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of
telecommunications, information and communication technologies (ICTs). The ITU Telecommunication
Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical,
operating and tariff questions and issuing Recommendations on them with a view to standardizing
telecommunications on a worldwide basis.
The World Telecommunication Standardization Assembly (WTSA), which meets every four years,
establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on
these topics.
The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1.
In some areas of information technology which fall within ITU-T's purview, the necessary standards are
prepared on a collaborative basis with ISO and IEC.
NOTE
In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
telecommunication administration and a recognized operating agency.
Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain
mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the
Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some
other obligatory language such as "must" and the negative equivalents are used to express requirements. The
use of such words does not suggest that compliance with the Recommendation is required of any party.
INTELLECTUAL PROPERTY RIGHTS
ITU draws attention to the possibility that the practice or implementation of this Recommendation may
involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence,
validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others
outside of the Recommendation development process.
As of the date of approval of this Recommendation, ITU had not received notice of intellectual property,
protected by patents, which may be required to implement this Recommendation. However, implementers
are cautioned that this may not represent the latest information and are therefore strongly urged to consult
the TSB patent database at http://www.itu.int/ITU-T/ipr/.
ITU 2015
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the
prior written permission of ITU.
ii Rec. ITU-T X.682 (08/2015)
---------------------- Page: 7 ----------------------
CONTENTS
Page
Introduction . iv
Information technology – Abstract Syntax Notation One (ASN.1): Constraint specification . 1
1 Scope . 1
2 Normative references . 1
2.1 Identical Recommendations | International Standards . 1
3 Definitions . 1
3.1 Specification of basic notation . 1
3.2 Information object specification . 1
3.3 Parameterization of ASN.1 specification . 1
3.4 Additional definitions . 1
4 Abbreviations . 2
5 Convention . 2
6 Notation . 2
6.1 Constraint . 2
7 ASN.1 lexical items . 2
7.1 Additional keywords . 2
8 General constraint specification . 2
9 User-defined constraints . 3
10 Table constraints, including component relation constraints . 4
11 Contents constraints . 7
Annex A – Constraining instance-of types . 8
A.4 Example . 8
Annex B – Summary of the notation . 9
Rec. ITU-T X.682 (08/2015) iii
---------------------- Page: 8 ----------------------
Introduction
Application designers require a notation to define a structured data type to convey their semantics. This is provided in
Rec. ITU-T X.680 | ISO/IEC 8824-1 and Rec. ITU-T X.681 | ISO/IEC 8824-2. A notation is also required to further
constrain the values that can appear. Examples of such constraints are restricting the range of some component(s), or
using a specified information object set to constrain an "ObjectClassFieldType" component, or using the "AtNotation"
to specify a relation between components.
This Recommendation | International Standard provides the notation for the general case of constraint specification.
NOTE 1 – For historical reasons the special case of a "subtype constraint" is specified in Rec. ITU-T X.680 | ISO/IEC 8824-1.
Constraint notation can appear (in round brackets) after any use of the syntactic construct "Type", and the purpose of
this Recommendation | International Standard is to specify the general case of what goes in the round brackets.
NOTE 2 – Multiple constraints (each inside its own round brackets) can be applied to the same "Type", as the result of
constraining a "Type" is itself formally a "Type" construct.
When a constraint is applied to the textually outermost use of a "Type" construct, it results in the creation of a new type
which is a subtype of the original (parent) type.
A subtype of a parent type can itself be used in defining other subtypes of the same parent type in other uses of the
constraint notation. Thus the subset of values constituting a subtype can be defined either by limiting the range of the
parent type, or by specifying the subtype as a union of sets of values.
NOTE 3 – The "ValueSet" notation specified in Rec. ITU-T X.680 | ISO/IEC 8824-1, 16.7, provides a further means of
specifying a subtype.
Constraints may also be used to produce a subtype of a parent type (as described above) when the notation is embedded
within another type. However, some "component relation" constraints are textually included following a "Type" (within
a set or sequence type definition), but are not used to restrict the set of possible values of the "Type" which they follow
(the referencing component). Rather, they specify a relation between the value of the referencing component and the
value of one or more other "Type"s in the same set or sequence type (called the referenced components).
Component relation constraints can be seen as subtyping the sequence type within which they are embedded, but not
necessarily the referencing type.
A constraint on an "ObjectClassFieldType" component can be applied by restricting the type or values in the component
by using an information object set. Such constraints are called table constraints, since they are specified in terms of the
"associated table" of the object set. The component relation constraints defined in this Recommendation | International
Standard are a special case of table constraints.
Finally, a "Type" may be subtyped by specifying the set of values in the subtype by human-readable text. Such a
constraint is called a user-defined constraint. For example, a user-defined constraint can be specified to constrain a BIT
STRING to the set of values produced by the encryption of a value of a specified ASN.1 type.
It is the purpose of this Recommendation | International Standard to provide the notation to be used for specifying table
constraints (including component relation constraints), and user-defined constraints.
NOTE 4 – In general, full support for the specification of constraints in a flexible way (particularly component relation
constraints, subtyping constraints, and user-defined constraints with a formally defined body) would require notation with a
power comparable to that of programming languages. Such power can only be sensibly provided by the establishment of links
from the ASN.1 notation into some other defined computer language. This version of this Recommendation | International
Standard does not provide such links, and hence supports only a small number of constraining mechanisms.
While the embedding of notation defining constraints (subtypes and relationships) will frequently be the most
convenient form of specification (particularly for the simple subtyping of primitive components of structures), separate
(external) specification will sometimes be preferred, particularly where the constraints are being imposed by a separate
group from that which defined the basic protocol.
NOTE 5 – The parameterization defined in Rec. ITU-T X.683 | ISO/IEC 8824-4 is specifically designed to enable a piece of
ASN.1 specification (and in particular, a constraint) to be parameterized, allowing the actual constraint to be imposed by some
other group that provides actual parameters for the parameterized construct.
iv Rec. ITU-T X.682 (08/2015)
---------------------- Page: 9 ----------------------
The notations for constraint specification supported here are:
– user-defined constraints (see clause 9);
– table constraints, including component relation constraints between two components which are
carrying values related to an information object, defined using the notation of Rec. ITU-T X.681 |
ISO/IEC 8824-2 (see clause 10);
– contents constraints (see clause 11).
The application of table constraints to the "InstanceOfType" construct of Rec. ITU-T X.681 | ISO/IEC 8824-2,
Annex C, is specified in Annex A.
Rec. ITU-T X.682 (08/2015) v
---------------------- Page: 10 ----------------------
ISO/IEC 8824-3:2005 (E)
INTERNATIONAL STANDARD
ITU-T RECOMMENDATION
Information technology –
Abstract Syntax Notation One (ASN.1):
Constraint specification
1 Scope
This Recommendation | International Standard is part of Abstract Syntax Notation One (ASN.1) and provides notation for
specifying user-defined constraints, table constraints, and contents constraints.
2 Normative references
The following Recommendations and International Standards contain provisions which, through reference in this text,
constitute provisions of this Recommendation | International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this
Recommendation | International Standard are encouraged to investigate the possibility of applying the most recent edition
of the Recommendations and Standards listed below. Members of IEC and ISO maintain registers of currently valid
International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of currently valid
ITU-T Recommendations.
2.1 Identical Recommendations | International Standards
– Recommendation ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, Information technology – Abstract Syntax
Notation One (ASN.1): Specification of basic notation.
– Recommendation ITU-T X.681 (2015) | ISO/IEC 8824-2:2015, Information technology – Abstract Syntax
Notation One (ASN.1): Information object specification.
– Recommendation ITU-T X.683 (2015) | ISO/IEC 8824-4:2015, Information technology – Abstract Syntax
Notation One (ASN.1): Parameterization of ASN.1 specifications.
3 Definitions
For the purposes of this Recommendation | International Standard, the following definitions apply.
3.1 Specification of basic notation
This Recommendation | International Standard uses the terms defined in Rec. ITU-T X.680 | ISO/IEC 8824-1.
3.2 Information object specification
This Recommendation | International Standard uses the terms defined in Rec. ITU-T X.681 | ISO/IEC 8824-2.
3.3 Parameterization of ASN.1 specification
This Recommendation | International Standard uses the following term defined in Rec. ITU-T X.683 | ISO/IEC 8824-4:
– parameterized type.
3.4 Additional definitions
3.4.1 component relation constraint: A constraint on the values of a set type or sequence type which is textually
associated with one of the component types (the referencing component) of the set type or sequence type, and which
specifies the relationship between the value of that component and the values of one or more other components (the
referenced components).
Rec. ITU-T X.682 (08/2015) 1
---------------------- Page: 11 ----------------------
ISO/IEC 8824-3:2005 (E)
3.4.2 constrained type: The innermost "Type" which contains the referencing component and all of the referenced
components of some component relation constraint.
3.4.3 constraining set: The information object set referenced in some component relation constraint.
3.4.4 constraining table: The associated table (see Rec. ITU-T X.681 | ISO/IEC 8824-2, clause 13) corresponding
to a constraining set.
3.4.5 referenced component: A component of a set type or sequence type identified in a component relation
constraint.
3.4.6 referencing component: A component of a set type or sequence type which has an associated component
relation constraint.
3.4.7 selected rows: Those rows of a constraining table which contain, in the appropriate columns, the values of all
of the referenced components.
3.4.8 table constraint: A constraint applied to an object class field type which demands that its values conform to
the contents of the appropriate column of some table.
3.4.9 user-defined constraint: A constraint which requires a more complicated statement than can be accommodated
by the other forms of constraint, and which must therefore involve specification by some means outside of ASN.1.
4 Abbreviations
For the purposes of this Recommendation | International Standard, the following abbreviation applies:
ASN.1 Abstract Syntax Notation One
5 Convention
This Recommendation | International Standard employs the notational convention defined in Rec. ITU-T X.680 |
ISO/IEC 8824-1, clause 5.
6 Notation
This clause summarizes the notation defined in this Recommendation | International Standard.
6.1 Constraint
The following notation which can be used as an alternative for "ConstraintSpec" (see Rec. ITU-T X.680 |
ISO/IEC 8824-1, 49.6) is defined in this Recommendation | International Standard:
– GeneralConstraint (see 8.1).
7 ASN.1 lexical items
In addition to the lexical items specified in Rec. ITU-T X.680 | ISO/IEC 8824-1, clause 12, this Recommendation |
International Standard makes use of the lexical items specified in the following subclauses. The general rules applicable
to these lexical items are as defined in Rec. ITU-T X.680 | ISO/IEC 8824-1, 12.1. These new lexical items make use of
the ASN.1 character set, as specified in Rec. ITU-T X.680 | ISO/IEC 8824-1, clause 11.
7.1 Additional keywords
The names CONSTRAINED, CONTAINING, ENCODED and BY are listed in Rec. ITU-T X.680 | ISO/IEC 8824-1, 12.38, as
reserved words.
8 General constraint specification
8.1 The notation for a "GeneralConstraint" is as follows:
GeneralConstraint ::=
UserDefinedConstraint
2 Rec. ITU-T X.682 (08/2015)
---------------------- Page: 12 ----------------------
ISO/IEC 8824-3:2005 (E)
| TableConstraint
| ContentsConstraint
8.2 The various possibilities for specification of the constraint are defined as follows:
a) "UserDefinedConstraint", in clause 9;
b) "TableConstraint", in clause 10;
c) "ContentsConstraint", in clause 11.
9 User-defined constraints
NOTE 1 – This form of constraint specification can be regarded as a special form of ASN.1 comment, since it is not fully
machine-processable. However, it would be possible for an automatic tool to use the presence of a particular user-defined
constraint to invoke user-supplied constraint checking.
NOTE 2 – Protocol designers should be aware that since the definition of a constraint in this way is not fully machine-processable,
a specification which employs this capability may be less easy to handle with automatic tools.
9.1 A user-defined constraint is specified by the syntax:
UserDefinedConstraint ::=
CONSTRAINED BY "{" UserDefinedConstraintParameter "," * "}"
9.2 It is recommended that the actual constraint be referenced by a comment anywhere inside the braces
( "{" and "}" ). This comment should clearly state what constraint is imposed by the "UserDefinedConstraint".
NOTE – If there are any "UserDefinedConstraintParameter"s within the braces (see 9.3), the comments may precede, follow, or be
interspersed among them, at the definer's convenience.
9.3 The actual constraint to be applied may depend on some parameters. For each such parameter, a
"UserDefinedConstraintParameter" shall be included in the "UserDefinedConstraint". Each
"UserDefinedConstraintParameter" shall be any "Value", "Object", "DefinedObjectSet", "Type" or
"DefinedObjectClass" which is specified by a reference name or, in the case of "Value", "Object" or "Type", can also be
defined inline.
NOTE – The reference name may be a dummy parameter if the "UserDefinedConstraint" is used within a
"ParameterizedAssignment".
UserDefinedConstraintParameter ::=
Governor ":" Value
| Governor ":" Object
| DefinedObjectSet
| Type
| DefinedObjectClass
The notation "Governor" is defined in Rec. ITU-T X.683 | ISO/IEC 8824-4, 8.3. When the first alternative is used, the
"Governor" shall be a "Type". When the second alternative is used, the "Governor" shall be a "DefinedObjectClass".
9.4 Example
If an application designer wishes to specify that certain components are to be bit strings carrying an encryption of the
value of some ASN.1 type (different for each component), then (using the parameterization of Rec. ITU-T X.683 |
ISO/IEC 8824-4) the parameterized ENCRYPTED type can be defined as follows:
ENCRYPTED {ToBeEnciphered} ::= BIT STRING
(CONSTRAINED BY
{-- must be the result of the encipherment of some BER-encoded
-- value of -- ToBeEnciphered}
! Error : securityViolation)
Error ::= ENUMERATED {securityViolation}
and a use of the ENCRYPTED parameterized subtype of BIT STRING (which is what the ENCRYPTED type is) becomes
simply:
ENCRYPTED{SecurityParameters}
or, equivalently, at the whim of the designer:
BIT STRING (ENCRYPTED{SecurityParameters})
The occurrence of a securityViolation is handled according to local security policy.
Rec. ITU-T X.682 (08/2015) 3
---------------------- Page: 13 ----------------------
ISO/IEC 8824-3:2005 (E)
10 Table constraints, including component relation constraints
NOTE 1 – Information object classes, information objects, information object sets, and the object class field type are defined in
Rec. ITU-T X.681 | ISO/IEC 8824-2. An understanding of these concepts is assumed in this clause.
NOTE 2 – This clause describes the application of the table constraint using an information object set that is identified within the
main notation defining the parent type, in other words, defined and identified by the protocol designer. This does not satisfy the
requirement for the actual information object set which is to be used as the constraint in particular abstract syntaxes to vary from
syntax to syntax. Rec. ITU-T X.683 | ISO/IEC 8824-4 provides notation which, among other things, enables the information
object set used in this constraint to be a parameter whose value is supplied at a later date by varying groups.
Example
For the purpose of illustrating the text of this clause, the following example will be used. An ErrorReturn type carries
an errorCategory and one or more errorCodes with corresponding errorInfo from that category. This is supported
by an ERROR-CLASS information object class with a specific set of objects defined in the information object set
ErrorSet that is used to constrain the fields of ErrorReturn.
We have:
ERROR-CLASS ::= CLASS
{
&category PrintableString (SIZE(1)),
&code INTEGER,
&Type
}
WITH SYNTAX {&category &code &Type}
ErrorSet ERROR-CLASS ::=
{
{"A" 1 INTEGER} |
{"A" 2 REAL} |
{"B" 1 CHARACTER STRING} |
{"B" 2 GeneralString}
}
ErrorReturn ::= SEQUENCE
{
errorCategory ERROR-CLASS.&category ({ErrorSet}) OPTIONAL,
errors SEQUENCE OF SEQUENCE
{
errorCode ERROR-CLASS.&code ({ErrorSet}{@errorCategory}),
errorInfo ERROR-CLASS.&Type ({ErrorSet}{@errorCategory,@.errorCode})
} OPTIONAL
}
The associated table of ErrorSet can be depicted as follows:
&category &code &Type
"A" 1 INTEGER
"A" 2 REAL
"B" 1 CHARACTER STRING
"B" 2 GeneralString
10.1 A table constraint can only be applied to types "ObjectClassFieldType" or an "InstanceOfType". The former
case is defined in the remainder of this clause, the latter in Annex A.
10.2 An "ObjectClassFieldType" identifies an information object class, and one of the p
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.