Information technology - ASN.1 encoding rules: Specification of Packed Encoding Rules (PER)

Technologies de l'information — Règles de codage ASN.1: Spécification des règles de codage compact (PER)

General Information

Status
Withdrawn
Publication Date
31-Jul-1996
Withdrawal Date
31-Jul-1996
Current Stage
9599 - Withdrawal of International Standard
Start Date
09-Dec-1999
Completion Date
30-Oct-2025
Ref Project

Relations

Standard
ISO/IEC 8825-2:1996 - Information technology -- ASN.1 encoding rules: Specification of Packed Encoding Rules (PER)
English language
42 pages
sale 15% off
Preview
sale 15% off
Preview
Standard
ISO/IEC 8825-2:1996 - Technologies de l'information -- Regles de codage ASN.1: Spécification des regles de codage compact (PER)
French language
45 pages
sale 15% off
Preview
sale 15% off
Preview

Frequently Asked Questions

ISO/IEC 8825-2:1996 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information technology - ASN.1 encoding rules: Specification of Packed Encoding Rules (PER)". This standard covers: Information technology - ASN.1 encoding rules: Specification of Packed Encoding Rules (PER)

Information technology - ASN.1 encoding rules: Specification of Packed Encoding Rules (PER)

ISO/IEC 8825-2:1996 is classified under the following ICS (International Classification for Standards) categories: 35.100.60 - Presentation layer. The ICS classification helps identify the subject area and facilitates finding related standards.

ISO/IEC 8825-2:1996 has the following relationships with other standards: It is inter standard links to ISO/IEC 8825-2:1998. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.

You can purchase ISO/IEC 8825-2:1996 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.

Standards Content (Sample)


lSO/IEC
INTERNATIONAL
8825-2
STANDARD
First edition
1996-08-01
Information technology - ASN.l encoding
rules: Specification of Packed Encoding
Rules (PER)
Technologies de I’in forma tion - R&g/es de codage ASN. I: Spkification des
r&g/es de codage condens6es (PER)
Reference number
&O/l EC 8825-2: 1996(E)
ISO/IEC 88252 : 1996 (E)
Contents
Page
..............................................................................................................................................................
1 Scope
Normative references .
........................................................................
2.1 Identical Recommendations I International Standards
Additional references .
2.2
Definitions .
.................................................................................................
Basic Presentation Service Definition
3.1
Specification of Basic Notation .
3.2
............................................................................................................................
3.3 ASN. 1 Extensibility
Information Object Specification .
3.4
......................................................................................................................
3.5 Constraint Specification
...........................................................................................
3.6 Parameterization of ASN. 1 Specification
.........................................................................................................................
37 Basic Encoding Rules
3:8 Additional definitions .
.
Abbreviations .
.....................................................
Notation .
Convention .
.....................................................
Encoding rules defined in this Recommendation I International Standard
Conformance .
........................................................................................................
The approach to encoding used for PER
......................................................................................................................
9.1 Use of the type notation
.............................................................................................
Use of tags to provide a canonical order
9:3 PER-visible constraints .
...........................................................................................
9 4 Type and value model used for encoding
Structure of an encoding .
9:5
............................................................................................................................
9.6 Types to be encoded
......................................................................................................................................
10 Encoding procedures
..................................................................................................
10.1 Production of the complete encoding
..................................................................................................................................
10.2 Open type fields
........................................................................................
10.3 Encoding as a non-negative-binary-integer
...................................................................................
10.4 Encoding as a 2’s-complement-binary-integer
...........................................................................................
10.5 Encoding of a constrained whole number
...............................................................
10.6 Encoding of a normally small non-negative whole number
..................................................................................
10.7 Encoding of a semi-constrained whole number
.....................................................................................
10.8 Encoding of an unconstrained whole number
................................................................................
10.9 General rules for encoding a length determinant
11 Encoding the boolean type .
...............................................................................................................................
12 Encoding the integer type
Encoding the enumerated type .
0 ISO/IEC 1996
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or
utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office l Case postale 56 l CH-1211 Gen&ve 20 l Switzerland
Printed in Switzerland
ii
0 ISO/IEC ISO/IEC 88252 : 1996 (E)
....................................................................................................................................
14 Encoding the real type
............................................................................................................................
15 Encoding the bitstring type
.........................................................................................................................
16 Encoding the octetstring type
17 Encoding the null type .
18 Encoding the sequence type .
19 Encoding the sequence-of type .
20 Encoding the set type .
21 Encoding the set-of type .
22 Encoding the choice type .
23 Encoding the object identifier type .
24 Encoding the embedded-pdv type .
........................................................................................................ 23
25 Encoding of a value of the external type
................................................................................................ 24
26 Encoding the restricted character string types
............................................................................................. 25
27 Encoding the unrestricted character string type
..........................................................................................................
28 Object identifiers for transfer syntaxes
............................................................................................................................. 28
Annex A - Example of encodings
...................................................................................... 28
A.1 Record that does not use subtype constraints
.................................................................................................. 31
A.2 Record that uses subtype constraints
A.3 Record that uses extension markers .
.............................................................................. 38
Annex B - Observations on combining PER-visible constraints
Annex C - Support for the PER algorithms .
Annex D - Support for the ASN. 1 rules of extensibility .
................................................................................ 41
Annex E - Tutorial annex on concatenation of PER encodings
Annex F - Assignment of object identifier values .
. . .
ISO/IEC 8825-2 : 1996 (E)
0 ISOLIEC
Foreword
IS0 (the International Organization for Standardization) and IEC (the Inter-
national Electrotechnical Commission) form the specialized system for worldwide
standardization. National bodies that are members of IS0 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.
IS0 and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with
IS0 and IEC, also take part in the work.
In the field of information technology, IS0 and IEC have established a joint
technical committee, ISO/IEC JTC 1. 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.
International Standard ISO/IEC 8825-2 was prepared by Joint Technical
Committee ISO/IEC JTC 1, Informatiort technology, Subcommittee ‘SC 21, @erz
Systems interconnection, data management and open distributed processing, in
collaboration with ITU-T. The identical text is published as ITU-T Recommen-
dation X.69 1.
ISO/IEC 8825-2 consists of the following parts, under the general title Information
technology - ASN. I encoding rules:
- Part 1: Specification of Basic Encoding Rules (BER), Canonical Encoding
Rules (CER) and Distinguished Encoding Rules (DER)
- Part 2: Specification of Packed Encoding Rules (PER)
Annexes A to F of this part of ISO/IEC 8825 are for information only.

0 ISO/IEC
ISO/IEC 8825-2 : 1996 (E)
Introduction
The publications ITU-T Rec. X.680 I ISO/IEC 8824-1, ITU-T Rec. X.681 I ISO/IEC 8824-2, ITU-T Rec. X.682 I
ISO/IEC 8824-3, ITU-T Rec. X.683 I ISO/IEC 8824-4, ITU-T Rec. X.680/Amd. 1 I ISO/IEC 8824-l/Amd. 1,
ITU-T Rec. X681/Amd. 1 I ISO/IEC 8824-2/Amd. 1 together describe Abstract Syntax Notation One (ASN.l), a
notation for the definition of messages to be exchanged between peer applications.
This Recommendation I International Standard defines encoding rules that may be applied to values of types defined
using the notation specified in ITU-T Rec. X.680 I ISOLIEC 8824-l. Application of these encoding rules produces a
transfer syntax for such values. It is implicit in the specification of these encoding rules that they are also to be used for
decoding.
There are more than one set of encoding rules that can be applied to values of ASN.1 types. This Recommendation I
International Standard defines a set of Packed Encoding Rules (PER), so called because they achieve a more compact
representation than that achieved by the Basic Encoding Rules (BER) and its derivatives described in ITU-T Rec. X.690
I ISO/IEC 8825-l which is referenced for some parts of the specification of these Packed Encoding Rules.
V
This page intentionally left blank

ISO/IEC 8825-2 : 1996 (E)
INTERNATIONAL STANDARD
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY -
ASN.l ENCODING RULES:
SPECIFICATION OF PACKED ENCODING RULES (PER)
1 Scope
This Recommendation I International Standard specifies a set of Packed Encoding Rules that may be used to derive a
transfer syntax for values of types defined in ITU-T Rec. X.680 1 ISOLIEC 8824-l. These Packed Encoding Rules are
also to be applied for decoding such a transfer syntax in order to identify the data values being transferred.
The encoding rules specified in this Recommendation I International Standard
-
are used at the time of communication;
-
are intended for use in circumstances where minimizing the size of the representation of values is the
major concern in the choice of encoding rules;
-
allow the extension of an abstract syntax by addition of extra values, preserving the encodings
of the existing values, for all forms of extension described in ITU-T Rec. X.680/Amd. 1 I
ISO/IEC 8824- 1 /Amd. 1.
Normative references
The following Recommendations and International Standards contain provisions which, through reference in this text,
constitute provisions of this Recommendation I 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 I International Standard are encouraged to investigate the possibility of applying the most recent
editions of the Recommendations and Standards listed below. Members of IEC and IS0 maintain registers of currently
valid International Standards. The Telecommunications Standardization Bureau of the ITU maintains a list of currently
valid ITU-T Recommendations.
21 . Identical Recommendations I International Standards
-
ITU-T Recommendation X.200 (1994) I ISO/IEC 7498- 1: 1994, Information technology - Open Systems
Interconnection - Basic Reference Model: The Basic Model.
-
ITU-T Recommendation X.21 6 (1994) I ISO/IEC 8822: 1994, Information technology - Open Systems
Interconnection - Presentation service definition.
-
ITU-T Recommendation X.226 (1994) I ISO/IEC 8823-l : 1994, Information technology - Qpen Systems
Interconnection - Connection-oriented presentation protocol: Protocol specification.
-
ITU-T Recommendation X.680 (1994) I ISOIIEC 8824- 1: 1995, Information technology - Abstract Syntax
Notation One (ASN. I): Specification of basic notation.
-
ITU-T Recommendation X.680 (1994)/Amd. 1 (1995) I ISO/IEC 8824- 1: 199YAmd. 1: 1995, Information
technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation - Amendment 1:
Rules of extensibility.
-
ITU-T Recommendation X.68 1 (1994) I ISO/IEC 8824-2: 1995, Information technology - Abstract Syntax
Notation One (ASN. I): Information object specification.
-
ITU-T Recommendation X.68 1 (1994)/Amd. 1 (1995) I ISOLIEC 8824-2: 1995/Amd. 1: 2995, Information
Abstract Syntax Notation One (ASN.1): Information object specification - Amendment I:
technology -
Rules of extensibility.
-
ITU-T Recommendation X.682 (1994) I ISOAEC 8824-3: 1995, Information technology - Abstract Syntax
Notation One (ASN. I): Constraint specification.
ITU-T Rec. X.691 (1995 E) 1
ISO/IEC 8825-2 : 1996 (E)
-
ITU-T Recommendation X.683 (1994) I ISO/IEC 8824-4: 1995, Information technology - Abstract Syntax
Notation One (ASN. I): Parameterization of ASN. I specifications.
-
ITU-T Recommendation X.690 (1994) I ISO/IEC 8825- 1: 1995, Information technology L ASN. I encoding
rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER).
Additional references
22 .
-
CCITT Rec. X.208 (1988), Specification of Abstract Syntax Notation One (ASN.1).
-
Character code structure and extension techniques.
ISOAEC 2022: 1994, Information technology -
-
Procedure for registration of escape sequences.
IS0 2375: 1985, Data processing -
-
IS0 6093: 1985, Information processing - Representation of numerical values in character strings for
information interchange.
-
ISO/IEC 8824: 1990, Information technology - Open Systems Interconnection - Spectfication of Abstract
Syntax Notation One (ASN. I).
-
IS0 International Register of Coded Character Sets to be Used with Escape Sequences.
-
Universal Multiple-Octet Coded Character
ISO/IEC 10646- 1: 1993, Information ’ technology -
Set (UC’S) - Part I: Architecture and Basic Multilingual Plane.
3 Definitions
For the purposes of this Recommendation I International Standard, the following definitions apply.
31 . Basic Presentation Service Definition
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.216 I
ISO/IEC 8822:
a) defined context set;
b) presentation context identifier.
32 . Specification of Basic Notation
For the purposes of this Recommendation I International Standard, all the definitions in ITU-T Rec. X.680 I
ISO/IEC 8824-l apply.
ASN.l Extensibility
33 .
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.68O/Amd. 1 I
ISO/IEC 8824- 1 /Amd. 1:
extension marker;
a>
34 . Information Object Specification
For the purposes of this Recommendation I International Standard, all the definitions in ITU-T Rec. X.681 I
ISO/IEC 8824-2 apply.
35 . Constraint Specification
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.682 I
ISOIIEC 8824-3:
component relation constraint;
a>
table constraint.
W
2 ITU-T Rec. X.691 (1995 E)
ISO/IEC 8825-2 : 1996 (E)
36 . Parameterization of ASN.1 Specification
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.683 I
ISO/IEC 8824-4:
-
variable constraint.
37 . Basic Encoding Rules
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.690 I
ISO/IEC 8825- 1:
a) dynamic conformance;
static conformance;
b)
data value;
C>
encoding (of a data value);
d)
sender;
e>
receiver.
Additional definitions
38 .
In addition, the following definitions apply.
2’s=complement-binary-integer encoding: The encoding of a whole number into an octet-aligned-bit-field of
3.8.1
a specified length, or into the minimum number of octets that will accommodate that whole number encoded as a 2’s-
complement-integer, which provides representations for whole numbers that are equal to, greater than, or less than zero,
as specified in 10.4.
NOTES
1 The value of a two’s complement binary number is derived by numbering the bits in the contents octets, starting’ with
bit 1 of the last octet as bit zero and ending the numbering with bit 8 of the first octet. Each bit is assigned a numerical value of 2N,
where N is its position in the above numbering sequence. The value of the two’s complement binary number is obtained by summing
- the numerical values assigned to each bit for those bits which are set to one, excluding bit 8 of the first octet, and then reducing this
value by the numerical value assigned to bit 8 of the first octet if that bit is set to one.
2 WhoZe number is a synonym for the mathematical term integer. It is used here to avoid confusion with the ASN.l
type integer.
3.8.2 abstract syntax value: A value of an abstract syntax (defined as the set of values of a single ASN.l type),
which is to be encoded by PER, or which is to be generated by PER decoding.
NOTE - The single ASN.l type associated with an abstract syntax is formally identified by an object of class
ABSTRACT-SYNTAX.
3.8.3 bit-field: The product of some part of the encoding mechanism that consists of an ordered set of bits that are
not necessarily a multiple of eight, and do not necessarily begin on an octet boundary in the complete encoding of the
abstract syntax value.
3.8.4 canonical encoding: A complete encoding of an abstract syntax value obtained by the application of encoding
rules that have no implementation-dependent options; such rules result in the definition of a l-l mapping between
unambiguous and unique bitstrings in the transfer syntax and values in the abstract syntax.
3.8.5 composite type: A set, sequence, set-of, sequence-of, choice, embedded-pdv, external or unrestricted character
string type.
3.8.6 composite value: The value of a composite type.
constrained whole number: A whole number which is constrained by PER-visible constraints to lie within a
3.8.7
range from “lb” to “ub” with the value “lb” less than or equal to “ub”, and the values of “lb” and “ub” as permitted
values.
NOTE - Constrained whole numbers occur in the encoding which identifies the chosen alternative of a choice type, the
length of character, octet and bit string types whose length has been restricted by PER-visible constraints to a maximum length, the
count of the number of components in a sequence-of or set-of type that has been restricted by PER-visible constraints to a maximum
number of components, the value of an integer type that has been constrained by PER-visible constraints to lie within finite minimum
and maximum values, and the value that denotes an enumeration in an enumerated type.
ITU-T Rec. X.691 (1995 E) 3
ISO/IEC 88252 : 1996 (E)
3.8.8 effective size constraint (for a constrained string type): A single finite size constraint that could be applied
to a built-in string type and whose effect would be to permit all and only those lengths that can be present in the
constrained string type.
NOTE - For example, the following has an effective size constraint:
A ::= IASString (SIZE(1.4) I SIZE(lO.lS))
since it can be rewritten with a single size constraint that applies to all values:
A ::= IASString (SIZE(1.4 I 10.15))
the following has no since the string can be arbitrarily long if it does not contain any characters other
whereas effective size constraint
than ‘a’, b’ and ‘c’:
B ::=
IASString (SIZE(L.4) I FROM(“abc”))
3.8.9 effective PermittedAlphabet constraint (for a constrained restricted character string type): A single
PermittedAlphabet constraint that could be applied to a built-in known-multiplier character string type and whose effect
would be to permit all and only those characters that can be present in any character position of any of the values in the
constrained restricted character string type.
NOTE - An effective PermittedAlphabet constraint is either the entire alphabet of the unconstrained character string type
or a PermittedAlphabet specification that happens to be a superset of all PermittedAlphabet constraints imposed on the type. For
example, in
Ax ::= IASString (FROM(“AB”) I FROM(“CD”))
Bx ::= IASString (SIZE(1.4) I FROM(“abc”))
“Ax” has an effective PermittedAlphabet constraints that consist of the entire IA5String alphabet since there is no PermittedAlphabet
constraint that applies to all values of “Ax”. The same is true for “Bx”. On the other hand, the following has an effective
PermittedAlphabet constraint of “ABCDE” since there is a PermittedAlphabet constraint specified that applies to all values:
A ::= IASString (FROM(“AB”) I FROM(“CD”) I FROM(“ABCDE”))
3.8.10 enumeration index: The non-negative whole number associated with an “EnumerationItem” in an enumerated
type. The enumeration indices are determined by sorting the “EnumerationItem”s into ascending order by their
enumeration value, then by assigning an enumeration index starting with zero for the first “EnumerationItem”, one for
the second, and so on up to the last “EnumerationItem” in the sorted list.
NOTE - “EnumerationItem”s in the “RootEnumeration” are sorted separately from those in the “AdditionalEnumeration”.
3.8.11 extensible for PER encoding: A property of a type whose definition contains an extension marker that affects
the PER encoding.
3.8.12 field-list: An ordered set of bit-field and/or octet-aligned-bit-field values that is produced as a result of
applying these encoding rules to components of a value.
NOTE - (Tutorial) The model employed in this Recommendation I International Standard uses the term “field-list” to
indicate a linked list of buffers each containing an encoding, a length in bits, and an octet alignment indicator of “bit-field” or “octet-
aligned-bit-field”. Each encoding is that of a value of an ASN.l type. The octet alignment indicator says whether the encoding is to be
aligned on an octet boundary when used to form the complete encoding of the abstract syntax value, or if it should be added
immediately after the last bit of the previous encoding in the complete encoding. The notion of “field-list” is for descriptive purposes
only and does not suggest an implementation method.
3.8.13 indefinite-length: An encoding whose length is greater than 64K-1 or whose maximum length cannot be
determined from the ASN. 1 notation.
3.8.14 fixed-length type: A type such that the value of the outermost length determinant in an encoding of this type
can be determined (using the mechanisms specified in this Recommendation I International Standard) from the type
notation (after the application of PER-visible constraints only) and is the same for all possible values of the type.
3.8.15 fixed value: A value such that it can be determined (using the mechanisms specified in this Recommendation I
International Standard) that this is the only permitted value (after the application of PER-visible constraints only) of the
type governing it.
3.8.16 known-multiplier character string type: A restricted character string type where the number of octets in the
encoding is a known fixed multiple of the number of characters in the character string for all permitted character string
values. The known-multiplier character string types are IASString, PrintableString, VisibleString, NumericString,
UniversalString and BMPString.
3.8.17 length determinant: A count (of bits, octets, characters, or components) determining the length of part or all
of a PER encoding.
3.8.18 normally small non-negative whole number: A part of an encoding which represents values of an
unbounded non-negative integer, but where small values are more likely to occur than 1 arge ones.
3.8.19 normally small length: A length encodi ng which represen ts values of an unbounded ength, but where small
lengths are more likely to occur than large ones.
4 ITU-T Rec. X.691 (1995 E)
ISO/IEC 8825-2 : 1996 (E)
3.8.20 octet-aligned-bit-field: The product of some part of the encoding mechanism that consists of an ordered set of
,
bits that are not necessarily a multiple of eight, but which are required to begin on an octet boundary in the complete
encoding of the abstract syntax value.
3.8.21 non-negative-binary-integer encoding: The encoding of a constrained or semi-constrained whole number
into either a bit-field of a specified length, or into an octet-aligned-bit-field of a specified length, or into the minimum
number of octets that will accommodate that whole number encoded as a non-negative-binary-integer which provides
representations for whole numbers greater than or equal to zero, as specified in 10.3.
NOTE - The value of a two’s complement binary number is derived by numbering the bits in the contents octets, starting
with bit 1 of the last octet as bit zero and ending the numbering with bit 8 of the first octet. Each bit is assigned a numerical value of
2N, where N is its position in the above numbering sequence. The value of the two’s complement binary number is obtained by
summing the numerical values assigned to each bit for those bits which are set to one.
3.8.22 PER-visible constraint: An instance of use of the ASN.l constraint notation which affects the PER encoding
of a value.
3.8.23 relay-safe encoding: A complete encoding of an abstract syntax value which can be decoded (including any
embedded encodings) without knowledge of the presentation layer defined context set that formed the environment in
which the encoding was performed.
whole number which is constrained by PER-visible constraints to exceed
3.8.24 semi-constrained whole number: A
or equal some value “lb” with the value “lb” as a permitted value, and which is not a constrained whole number.
NOTE - Semi-constrained whole numbers occur in the encoding of the length of unconstrained (and in some cases
constrained) character, octet and bit string types, the count of the number of components in unconstrained (and in some cases
constrained) sequence-of and set-of types, and the value of an integer type that has been constrained to exceed some minimum value.
3.8.25 simple type: A type that is not a composite type.
3.8.26 textually dependent: A term used to identify the case where if some reference name is used in evaluating an
element set, the value of the element set is considered to be dependent on that reference name, regardless of whether the
actual set arithmetic being performed is such that the final value of the element set is independent of the actual element
set value assigned to the reference name.
NOTE - For example, the following definition of “Foe” is textually dependent on “Bar” even though “Bar” has no effect on
“Foo”s set of values (thus, according to 9.3.4 the constraint on “Foe” is not PER-visible since “Bar” is constrained by a table
constraint and “Foe” is textually dependent on “Bar”).
MY-CLASS ::= CLASS { &name PrintableString, &age INTEGER } WITH SYNTAX{&name , &age}
MyObjectSet MY-CLASS ::= { {“Jack”, 7) I {“Jill”, 5) }.
Bar ::= MY-CLASS&age ({MyObjectSet})
Foo ::= INTEGER (Bar I l.lOO)
3.8.27 unconstrained whole number: A whole number which is not constrained by PER-visible constraints.
NOTE - Unconstrained whole numbers occur only in the encoding of a value of the integer type.
4 Abbreviations
ASN.l Abstract Syntax Notation One
BER
Basic Encoding Rules of ASN.1
PER Packed Encoding Rules of ASN. 1
Canonical Encoding Rules of ASN.l
CER
16K 16384
32K
48K 49152
64K 65536
5 Notation
This Recommendation I International Standard references the notation defined by ITU-T Rec. X.680 I ISO/IEC 8824-l.
ITU-T Rec. X.691 (1995 E)
ISO/IEC 8825-2 : 1996 (E)
6 Convention
This Recommendation I International Standard defines the value of each octet in an encoding by use of the
terms “most significant bit” and “least significant bit”.
NOTE - Lower layer specifications use the same notation to define the order of bit transmission on a serial line, or the
assignment of bits to parallel channels.
For the purpose of this Recommendation I International Standard, the bits of an octet are numbered from 8 to 1,
6.2
where bit 8 is the “most significant bit” and bit 1 the “least significant bit”.
63 The term “octet” is frequently used in this Recommendation I International Standard to stand for “eight bits”.
The use of this term in place of “eight bits” does not carry any implications of alignment. Where alignment is intended it
is explicitly stated in this Recommendation I International Standard.
7 Encoding rules defined in this Recommendation I International Standard
This Recommendation I International Standard specifies four encoding rules (together with their associated
7.1
object identifiers) which can be used to encode and decode the values of an abstract syntax defined as the values of a
single (known) ASN. 1 type. This clause describes their applicability and properties.
7.2 Without knowledge of the type of the value encoded, it is not possible to determine the structure of the
encoding (under any of the PER encoding rule algorithms). In particular, the end of the encoding cannot be determined
from the encoding itself without knowledge of the type being encoded.
7.3 PER encodings are always relay-safe provided the abstract values of the types EXTERNAL, EMBEDDED
PDV and CHARACTER STRING are constrained to prevent the carriage of presentation context identifiers.
7.4 The most general encoding rule algorithm specified in this Recommendation I International Standard is
BASIC-PER, which does not in general produce a canonical encoding.
A second encoding rule algorithm specified in this Recommendation I International Standard is CANONICAL-
7.5
PER, which produces encodings that are canonical. This is defined as a restriction of implementation-dependent choices
in the BASIC-PER encoding. CANONICAL-PER produces canonical encodings that have applications when
authenticators need to be applied to abstract values, as described in ITU-T Rec. X.690 I ISO/IEC 8825-l) Annex D.
NOTE - Any implementation conforming to CANONICAL-PER for encoding is conformant to BASIC-PER for encoding.
Any implementation conforming to BASIC-PER for decoding is conformant to CANONICAL-PER for decoding. Thus, encodings
made according to CANONICAL-PER are encodings that are permitted by BASIC-PER.
7.6 If a type encoded with BASIC-PER or CANONICAL-PER contains EMBEDDED PDV, CHARACTER
STRING or EXTERNAL types, then the outer encoding ceases to be relay-safe unless the transfer syntax used for all the
EMBEDDED PDV, CHARACTER STRING and EXTERNAL types is relay safe. If a type encoded with BASIC-PER
or CANONICAL-PER contains EMBEDDED PDV, EXTERNAL or CHARACTER STRING types, then the outer
encoding ceases to be canonical unless the transfer syntax used for all the EMBEDDED PDV, EXTERNAL and
CHARACTER STRING types is canonical.
NOTE - The character transfer syntaxes supporting all character abstract syntaxes of the form (iso standard 10646 level-l
(1) . .) are canonical. Those supporting (iso standard 10646 level-2 (2) . .) and (iso standard 10646 level-3 (3) “.I are not always
canonical. All the above character transfer syntaxes are relay-safe.
7.7 Both BASIC-PER and CANONICAL-PER come in two variants, the ALIGNED variant, and the
UNALIGNED variant. In the ALIGNED variant, padding bits are inserted from time to time to restore octet alignment.
In the UNALIGNED variant, no padding bits are ever inserted.
7.8 There are no interworking possibilities between the ALIGNED variant and the UNALIGNED variant.
7.9 PER encodings are self-delimiting only with knowledge of the type of the encoded value. Encodings are
always a multiple of eight bits. When carried in an EXTERNAL type they shall be carried in the OCTET STRING
choice alternative, unless the EXTERNAL type itself is encoded in PER, in which case the value may be encoded as a
single ASN.l type (i.e. an open type). When carried in OS1 presentation protocol, the “full encoding” (as defined in ITU-
T Rec. X.226 I ISO/IEC 8823-l) with the OCTET STRING choice alternative shall be used.
7.10 The rules of this Recommendation I International Standard apply to both algorithms and to both variants unless
otherwise stated.
7.11 Annex C is informative, and recommendations on which combinations of PER to implement in order to
gives
maximize the chances of interworking.
ITU-T Rec. X.691 (1995 E)
ISWIEC 8825-2 : 1996 (E)
8 Conformance
81 . Dynamic conformance is specified by clause 9 onwards.
82 Static conformance is specified by those standards which specify the application of these Packed Encoding
iules.
NOTE - Annex C of this Recommendation I International Standard provides guidance on static conformance in relation to
support for the two variants of the two encoding rule algorithms. This guidance is designed to ensure interworking, while recognizing
the benefits to some applications of encodings that are neither relay-safe nor canonical.
83 The rules in this Recommendation I International Standard are specified in terms of an encoding procedure.
Implementations are not required to mirror the procedure specified, provided the bit string produced as the complete
encoding of an abstract syntax value is identical to one of those specified in this Recommendation I International
Standard for the applicable transfer syntax.
84 . Implementations performing decoding are required to produce the abstract syntax value corresponding to any
received bit string which could be produced by a sender conforming to the encoding rules identified in the transfer
syntax associated with the material being decoded.
NOTES
1 In general there are no alternative encodings defined for the BASIC-PER explicitly stated in this Recommendation I
International Standard. The BASIC-PER becomes canonical by specifying relay-safe operation and by restricting some of the
encoding options of other ISO/IEC Standards that are referenced. CANONICAL-PER provides an alternative to both the
Distinguished Encoding Rules and Canonical Encoding Rules (see ITU-T Rec. X.690 I ISO/IEC 8825-l) where a canonical and relay-
safe encoding is required.
2 When CANONICAL-PER is used to provide a canonical encoding, it is recommended that any resulting encrypted
hash value that is derived from it should have associated with it an algorithm identifier that identifies CANONICAL-PER as the
transformation from the abstract syntax value to an initial bitstring (which is then hashed).
9 The approach to encoding used for PER
91 l Use of the type notation
9.1.1 These encoding rules make specific use of the ASN.l type notation as specified in ITU-T Rec. X.680 I
ISO/IEC 8824- 1, and can only be applied to encode the values of a single ASN. 1 type specified using that notation.
In particular, but not exclusively, they are dependent on the following information being retained in the ASN.l
9.1.2
type and value model underlying the use of the notation:
the nesting of choice types within choice types;
a>
the tags placed on the components in a set type, and on the alternatives in a choice type, and the values
b)
given to an enumeration;
whether a set or sequence component is optional or not;
Cl type
whether a set or sequence type component has a DEFAULT value or not;
d)
the restricted range of values of a type which arise through the application of PER-visible constraints
e)
(only);
whether a component is an open type;
whether an extension marker is present.
g)
92 0 Use of tags to provide a canonical order
This Recommendation I International Standard requires components of a set type and a choice type to be canonically
ordered independent of the textual ordering of the components. The canonical order is determined by sorting the tags of
the components, as specified in 6.4 of ITU-T Rec. X.680 I ISO/IEC 8824-l.
93 . PER-visible constraints
NOTE - The fact that some ASN. 1 constraints may not be PER-visible for the purposes of encoding and decoding does not
in any way affect the use of such constraints in the handling of errors detected during decoding, nor does it imply that values violating
such constraints are allowed to be transmitted by a conforming sender.
9.3.1 Constraints that are expressed in human-readable text or in ASN.l comment are not PER-visible.
9.3.2 Variable constraints are not PER-visible (see 10.4 and 10.5 of ITU-T Rec. X.683 I ISO/IEC 8824-4).
9.3.3 Table constraints are not PER-visible (see ITU-T Rec. X.682 I ISO/IEC 8824-3).
ITU-T Rec. X.691 (1995 E) 7
ISO/IEC 8825-2 : 1996 (E)
Constraints whose evaluation is textually dependent on a table constraint or a component relation constraint are
9.3.4
not PER-visible (see ITU-T Rec. X.682 I ISO/IEC 8824-3).
9.3.5 Component relation constraints are not PER-visible (see ITU-T Rec. X.682 I ISO/IEC 8824-3).
Constraints on restricted character string types which are not (see clause 34 of ITU-T Rec. X.680 I
9.3.6
ISO/IEC 8824-l) known-multiplier character string types are not PER-visible (see 3.8.16).
9.3.7 Subject to the above, all size constraints are PER-visible.
9.3.8 The effective size constraint for a constrained type is a single size constraint such that a size is permitted if and
only if there is some value of the constrained type that has that (permitted) size. If the constrained type has values of a
size that does not satisfy the constraint there is no effective size constraint.

PermittedAlphabet constraints on known-multiplier character string types are PER-visible.
9.3.9
9.3.10 The effective PermittedAlphabet constraint for a constrained type is a single PermittedAlphabet constraint such
that a character is allowed if and only if there is some value of the constrained type that contains that character. If all
characters of the type being constrained can be present in some value of the constrained type, then the effective
PermittedAlphabet constraint is the set of characters defined for the unconstrained type.
NOTES
1 In the definition of a constrained type, multiple PER-visible constraints may be applied either directly or through the
use of “ContainedSubtype%.
2 See Annex B for observations on the effect of combining constraints that individually are PER-visible.
9.3.11 An inner type constraint applied to a real type is PER-visible.
9.3.12 An inner type constraint applied to an unrestricted character string or embedded-pdv type is PER-visible only
when it is used to restrict the value of the “syntaxes” component to a single value, or when it is used to restrict
“identification” to the “fixed” alternative (see clauses 24 and 27).
9.3.13 Constraints on the useful types are not PER-visible.
PER-visible if and on1
9.3.14 Subject to the above, all other constraints are .y if they are applied to an integer type or,
single value constrai nts excluded, to a known-multiplier b character string type.
9.3.15 If a PER-visible constraint other than PermittedAlphabet has an extension marker, then the type is defined to
be extensible for PER encodings.
NOTES
1 If an extension marker is present in a ConstraintSpec which is not PER-visible, and there is no other extension marker
present in the constraint, then the type is encoded by PER as if it has no extension marker.
2 If there are multiple SizeConstraint specifications applied to a type and one of them is extensible, then the type is
encoded in PER as if the extension marker was present on all the SizeConstraint specifications.
9.3.16 A type is also extensible for PER encodings if any of the following occurs:
it is derived from an ENUMERATED type (by subtyping, type referencing, or tagging) and there is an
a>
extension marker in the “Enumerations” production; or
b) it is derived from a SEQUENCE type (by subtyping, type referencing, or tagging) and there is an
extension marker in the “ComponentTypeLists” or in the “SequenceType” productions; or
it is derived from a SET type (by subtyping, type referencing, or tagging) and there is an extension marker
C)
in the “ComponentTypeLists” or in the “SetType” productions; or
d) it is derived from a CHOICE type (by subtyping, type referencing, or tagging) and there is an extension
marker in the “AlternativeTypeLists” production.
94 . Type and value model used
...


NORME ISO/CEI
I NTE R NATIONALE 8825-2
Première édition
1996-08-01
Technologies de l'information - Règles de
codage ASN.1: Spécification des règles de
codage compact (PER)
Information technology - ASN. I encoding rules: Specification of Packed
Encoding Rules (PER)
Numéro de référence
ISO/CEI 8825-2:1996(F)
ISOKEI 8825-2:1996(F)
Sommaire
Page
1 Domaine d'application . 1
2 Références normatives .
2.1 Recommandations I Normes internationales identiques .
2.2 Autres références . 2
3 Définitions .
Définition du service de présentation de base .
3.1
3.2 Spécification de la notation de base .
Extensibilité de la notation ASN.l .
3.3
Spécification des objets informationnels .
3.4
3.5 Spécification des contraintes .
3.6 Spécification du paramétrage en notation ASN.l .
Règles de codage de base . 3
3.7
3.8 Autres définitions . 3
4 Abréviations .
5 Notation . 6
6 Conventions .
Règles de codage définies dans la présente Recommandation I Norme internationale . 6
8 Conformité .
9 Méthode de codage utilisée pour les règles PER .
9.1 Utilisation de la notation de types . 8
9.2 Utilisation d'étiquettes pour établir un ordre canonique .
9.3 Contraintes visibles par les règles PER .
9.4 Modèle utilisé pour coder les types et les valeurs .
9.5 Structure d'une expression codée .
9.6 Types à coder .
10 a
10 Procédures de codage .
10.1 Production du codage complet .
10.2 Champs de type ouvert . 11
Codage sous forme dun entier binaire non négatif . 11
10.3
10.4 Codage sous forme dun entier binaire en complément à deux . 12
Codage dun nombre entier contraint . 12
10.5
10.6 Codage dun nombre entier non négatif normalement petit . 13
10.7 Codage dun nombre entier semi-contraint . 13
10.8 Codage d'un nombre entier non contraint .
10.9 Règles générales pour le codage dun déterminant de longueur . 14
O ISO/CEI 1996
Droits de reproduction réservés . Sauf prescription différente. aucune partie de cette publication ne
peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé. électronique ou
mécanique. y compris la photocopie et les microfilms. sans l'accord écrit de l'éditeur .
ISOKEI Copyright Office Case postale 56 CH-121 1 Genève 20 Suisse
Version française tirée en 1997
Imprimé en Suisse
ISO/CEI 8825-2: 1996(F)
0 ISO/CEI
Codage du type booléen .
12 Codage du type entier .
13 Codage du type énuméré .
14 Codage du type réel .
15 Codage du type chaîne binaire .
Codage du type chaîne d'octets .
17 Codage du type néant .
Codage du type séquence .
19 Codage du type séquence-de .
Codage du type ensemble .
21 Codage du type ensemble-de .
22 Codage du type choix .
Codage du type identificateur d'objet .
0 23
Codage du type valeur PDV encapsulée .
Codage dune valeur du type externe .
26 Codage des types chaîne de caractères restreinte .
Codage du type chaîne de caractères non restreinte .
28 Identificateurs d'objet pour syntaxes de transfert .
Annexe A . Exemples de codages .
Enregistrement qui n'utilise pas de contrainte appliquée aux sous-types . 31
A.l
Enregistrement utilisant des contraintes appliquées aux sous-types .
A.2
Enregistrement qui utilise des marqueurs d'extension .
A.3
Annexe B - Observations sur la combinaison de contraintes visibles par les règles PER .
Annexe C - Prise en charge des algorithmes PER .
Annexe D - Prise en charge des règles d'extensibilité ASN.1 .
Annexe E . Complément didactique sur la concaténation de codages conformes aux règles PER .
Annexe F . Affectation de valeurs à un identificateur d'objet .
e
...
ISO/CEI 8825-2: 1996(F) 0 ISO/CEI
Avant-propos
L'ISO (Organisation internationale de normalisation) et la CE1 (Commission
électrotechnique internationale) forment ensemble un système consacré à la
normalisation internationale considérée comme un tout. Les organismes nationaux
membres de I'ISO ou de la CE1 participent au développement de Normes inter-
nationales par l'intermédiaire des comités techniques créés par l'organisation
concernée afin de s'occuper des différents domaines particuliers de l'activité
technique. Les comités techniques de I'ISO et de la CE1 collaborent dans des
domaines d'intérêt commun. D'autres organisations internationales, gouverne-
mentales ou non gouvernementales, en liaison avec I'ISO et la CE1 participent
également aux travaux.
Dans le domaine des technologies de l'information, I'ISO et la CE1 ont créé un
comité technique mixte, l'ISO/CEI JTC 1. Les projets de Normes internationales
adoptés par le comité technique mixte sont soumis aux organismes nationaux pour
approbation, avant leur acceptation comme Normes internationales. Les Normes
internationales sont approuvées conformément aux procédures qui requièrent
l'approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISO/CEI 8825-2 a été élaborée par le comité technique
mixte ISO/CEI JTC 1, Technologies de l'information, sous-comité SC 21,
Interconnexion des systèmes ouverts, gestion des données et traitement distribué
ouvert, en collaboration avec WIT-T. Le texte identique est publié en tant que
Recommandation UIT-T X.691.
L'ISO/CEI 8825 comprend les parties suivantes, présentées sous le titre général
Technologies de l'information -Règles de codage ASN.1:
-
Partie 1: Spécification des règles de codage de base (BER), des règles de
codage canoniques (CER) et des règles de codage distinctives (DER)
-
Partie 2: Spécification des règles de codage compact (PER)
Les annexes A à F de la présente partie de l'ISO/CEI 8825 sont données unique-
ment à titre d'information.
0 ISO/CEI ISO/CEI 8825-2: 1996(F)
Introduction
L'ensemble de documents Rec. UIT-T X.680 I ISO/CEI 8824-1, Rec. UIT-T X.681 I ISO/CEI 8824-2,
Rec. UIT-T X.682 I ISO/CEI 8824-3, Rec. UIT-T X.683 I ISO/CEI 8824-4, Rec. UIT-T X.680/Amd. 1 I
ISO/CEI 8824-UAmd. 1, Rec. UIT-T X.68UAmd. 1 I ISO/CEI 8824-2/Amd. 1, décrivent la notation de syntaxe abstraite
numéro un (ASN.1) qui permet de définir les messages échangés par des applications homologues.
La présente Recommandation I Norme internationale définit les règles de codage qui pourront être appliquées à des
valeurs de types définis conformément à la notation spécifiée dans la Rec. UIT-T X.680 I ISQ/CEI 8824-1. L'application
de ces règles de codage produit une syntaxe de transfert pour de telles valeurs. La spécification de ces règles de codage
postule implicitement que ces règles pourront être utilisées telles quelles pour le décodage.
Plusieurs ensembles de règles de codage peuvent être appliqués à des valeurs de types ASN.1. La présente
Recommandation I Norme internationale définit un ensemble de règles de codage compact (PER) bucked encoding
rules), ainsi dénommées parce qu'elles donnent une représentation plus compacte que celle que l'on peut obtenir au
moyen des règles de codage de base (BER) et de leurs dérivées, décrites dans la Rec. UIT-T X.690 I ISO/CEI 8825-1, à
laquelle font référence certaines parties de la spécification des présentes règles de codage compact.
V
ISO/CEI 8825-2: 1996(F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L'INFORMATION - RÈGLES DE CODAGE ASN.l:
SPÉCIFICATION DES RÈGLES DE CODAGE COMPACT (PER)
1 Domaine d'application
La présente Recommandation I Norme internationale spécifie un ensemble de règles de codage compact qui peuvent être
utilisées pour élaborer une syntaxe de transfert applicable à des valeurs de types définis dans la Rec. UIT-T X.680 I
ISO/CEI 8824-1. Ces règles de codage compact sont également applicables au décodage dune telle syntaxe de transfert
afin d'identifier les valeurs de données qui sont transférées.
Les règles de codage spécifiées dans la présente Recommandation I Norme internationale:
e
-
sont utilisées au moment de la communication;
-
sont destinées à être utilisées dans des circonstances où la minimisation du volume occupé par la
représentation de valeurs est la principale préoccupation lors du choix de règles de codage;
-
permettent l'extension d'une syntaxe abstraite par adjonction de valeurs supplémentaires, tout en
conservant les codages des valeurs existantes, pour toutes les formes d'extension décrites dans la
Rec. UIT-T X.680/Amd. 1 I ISO/CEI 8824-UAmd. 1.
2 Références normatives
Les Recommandations et les Normes internationales suivantes contiennent des dispositions qui, par suite de la référence
qui y est faite, constituent des dispositions valables pour la présente Recommandation I Norme internationale. Au
moment de la publication, les éditions indiquées étaient en vigueur. Toutes Recommandations et Normes sont sujettes à
révision et les parties prenantes aux accords fondés sur la présente Recommandation I Norme internationale sont invitées
à rechercher la possibilité d'appliquer les éditions les plus récentes des Recommandations et Normes indiquées ci-après.
Les membres de la CE1 et de VISO possèdent le registre des Normes internationales en vigueur. Le Bureau de la
normalisation des télécommunications de I'UIT tient à jour une liste des Recommandations de I'UIT-T en vigueur.
m
2.1 Recommandations I Normes internationales identiques
Recommandation UIT-T X.200 (1994) I ISO/CEI 7498-1: 1994, Technologies de l'information -
Interconnexion des systèmes ouverts - Modèle de référence de base: le modèle de référence de base.
Recommandation UIT-T X.216 (1994) I ISO/CEI 8822: 1994, Technologies de l'information -
Interconnexion des systèmes ouverts - Définition du service de présentation.
Recommandation UIT-T X.226 (1994) I ISO/CEI 8823-1: 1994, Technologies de l'information -
Interconnexion des systèmes ouverts - Protocole de présentation en mode connexion: spécijïcation du
protocole.
Recommandation UIT-T X.680 (1994) I ISO/CEI 8824-1: 1995, Technologies de l'information - Notation
de syntaxe abstraite numéro un: spécification de la notation de base.
Recommandation UIT-T X.680 (1994)/Amd. 1 (1995) I ISO/CEI 8824-1: 1995/Amd. 1: 1995, Techno-
logies de l'information - Notation de syntaxe abstraite numéro un: spécification de la notation de base -
Amendement I: règles d'extensibilité.
Recommandation UIT-T X.681 (1994) I ISO/CEI 8824-2: 1995, Technologies de l'information - Notation
de syntaxe abstraite numéro un: spécification des objets informationnels.
Recommandation UIT-T X.681 (1994)lAmd. 1 (1995) I ISOICEI 8824-2: 1995/Amd. 1: 1995, Techno-
logies de l'information - Notation de syntaxe abstraite numéro un: spécification des objets
informationnels - Amendement I: règles d'extensibilité.
Rec. UIT-T X.691(1995 F) 1
ISOKEI 8825-2: 1996(F)
-
8824-3: 1995, Technologies de l'information - Notation
Recommandation UIT-T X.682 (1994) I ISO/CEI
de syntaxe abstraite numéro un: spécification des contraintes.
-
Recommandation UIT-T X.683 (1994) I ISO/CEI 8824-4:1995, Technologies de l'information - Notation
des spécijications de la notation de syntaxe abstraite
de syntaxe abstraite numéro un: paramétrage
numéro un.
-
8825-1:1995, Technologies de l'information -Règles de
Recommandation UIT-T X.690 (1994) I ISO/CEI
codage de la notation de syntaxe abstraite numéro un: spécgcation des règles de codage de base, des
règles de codage canoniques et des règles de cod6ge distinctives.
2.2 Autres références
-
Recommandation X.208 du CCITT (1988), Spécifkation de la syntaxe abstraite numéro un (ASN. I ).
-
- Structure de code de caractères et techniques
ISO/CEI 2022:1994, Technologies de l'information
d'extension.
Définition du service de présentation de base
3.1
Termes définis dans la Rec. UIT-T X.216 I ISOKEI 8822:
a) ensemble de contextes défini;
identificateur de contexte de présentation.
b)
3.2 Spécification de la notation de base
Toutes les définitions contenues dans la Rec. UIT-T X.680 I ISOLEI 8824-1 s'appliquent.
3.3 Extensibilité de la notation ASN.l
:
Termes définis dans la Rec. UIT-T X.680/Amd. 1 I ISO/CEI 8824- l/Amd. 1
a) marqueur d'extension;
b) arc d'extension;
c) racine d'extension;
d) prolongement d'extension.
3.4 Spécification des objets informationnels
Toutes les définitions figurant dans la Rec. UIT-T X.681 I ISOKEI 8824-2 s'appliquent.
2 Rec. UIT-T X.691(1995 F)
ISO/CEI 8825-2:1996(F)
3.5 Spécification des contraintes
Termes définis dans la Rec. UIT-T X.682 I ISO/CEI 8824-3:
a) contrainte relationnelle de composante;
b) contrainte tabulaire.
3.6 Spécification du paramétrage en notation ASN.l
Terme défini dans la Rec. UIT-T X.683 I ISO/CEI 8824-4:
- contrainte variable.
Règles de codage de base
3.7
Termes définis dans la Rec. UIT-T X.690 I ISO/CEI 8825-1:
a) conformité dynamique;
b) conformité statique;
c) valeur de données;
codage (dune valeur de données);
d)
e) expéditeur;
f) destinataire.
3.8 Autres définitions
De plus, les définitions suivantes s'appliquent.
3.8.1 codage d'entier binaire en complément à 2: codage dun nombre entier sur un champ binaire aligné ii l'octet
de longueur spécifiée, ou sur le nombre minimal d'octets permettant de représenter cet entier (égal, supérieur ou inférieur
à zéro comme spécifié au 10.4) sous forme dun entier en complément à deux.
NOTES
1 La représentation dun nombre binaire en complément à deux est obtenue en numérotant les bits des octets qui le
composent, en commençant par le bit 1 du dernier octet qui devient le bit O et en terminant par le bit 8 du premier octet. A chaque bit
est affectée une valeur numérique de 2N, N étant la position du bit dans la séquence de numérotation précédente. La valeur du nombre
binaire en complément à deux est obtenue en ajoutant les valeurs numériques affectées à chacun des bits qui sont à un, sauf le bit 8 du
0 premier octet, puis en soustrayant de cette valeur la valeur numérique affectée à ce bit 8 du premier octet, s'il est à un.
2 L'expression nombre entier est synonyme du terme mathématique entier. Elle est utilisée à la place de celui-ci pour
éviter une confusion avec le type entier (integer) de I'ASN.l.
3.8.2 valeur d'une syntaxe abstraite: valeur dune syntaxe abstraite (définie comme l'ensemble des valeurs d'un
type unique ASN. I), à coder selon les règles PER, ou à générer par un décodage PER.
NOTE - Le type ASN.l unique associé à une syntaxe abstraite est identifié de façon formelle par un objet de la classe
ABSTRACT-SYNTAX.
3.8.3 champ binaire: produit dune partie du processus de codage, qui se compose dun ensemble ordonné
d'éléments binaires. Cet ensemble n'est pas nécessairement un multiple de 8 et ne commence pas nécessairement à une
limite d'octet dans le codage complet de la valeur de la syntaxe abstraite.
3.8.4 codage canonique: codage complet dune valeur dans la syntaxe abstraite, obtenu par application de règles de
codage ne comportant aucune option dépendant de la mise en œuvre; de telles règles se traduisent - dans la syntaxe de
transfert et dans les valeurs de la syntaxe abstraite - par des correspondances biunivoques entre chaînes binaires non
ambiguës et uniques de la syntaxe de transfert et valeurs de la syntaxe abstraite.
3.8.5 type composite: type du genre ensemble, séquence, ensemble-de, séquence-de, choix, valeur PDV encapsulée,
externe ou chaîne de caractères.
3.8.6 valeur composite: valeur d'un type composite.
Rec. UIT-T X.691(1995 F) 3
ISO/CEI 8825-2: 1996(F)
3.8.7 nombre entier contraint: nombre entier soumis par les contraintes visibles des règles PER, de manière à
s'inscrire dans un intervalle compris entre une borne inférieure "lb" et une borne supérieure "ub", bornes comprises, avec
"lb' inférieure ou égale à "ub".
NOTE - Les nombres entiers contraints apparaissent dans les codages qui identifient l'alternative choisie dans un type
choix, ou la longueur dune chaîne binaire, de caractères ou d'octets lorsque la longueur du type de celle-ci est limitée à un maximum
par une contrainte visible des règles PER, ou le nombre de composantes dune valeur de type séquence-de ou ensemble-de lorsque le
nombre des composantes dun tel type est limité à un maximum par une contrainte visible des règles PER, ou la valeur d'un entier
lorsque le type de celui-ci est limité à un intervalle fini par une contrainte visible des règles PER, ou la valeur ordinale d'un élément
appartenant à un type énuméré.
3.8.8 contrainte effective de taille (pour un type chaîne contrainte): contrainte unique limitant une taille à une
valeur finie, qui peut être appliquée à un type chaîne natif et dont I'effet sera de permettre toutes les longueurs - et
seulement celles-ci - qui peuvent être présentes dans le type chaîne contrainte.
NOTE - Par exemple, la définition suivante est soumise à une contrainte effective de taille:
A ::= IASString (SIZE(1.A) I SIZE(lO.lS))
car on peut la réécrire sous forme dune unique contrainte de taille qui s'applique à toutes les valeurs comme suit:
A ::= IASString (SIZE(1.A I lO.lS))
tandis que i'expression suivante n'est soumise à aucune contrainte effective de taille car la chaîne peut avoir une longueur quelconque
si elle ne contient pas d'autres caractères que 'a', 'b et 'c':
B ::= IASString (SIZE(1.A) I FROM("abc"))
3.8.9 contrainte effective d'alphabet permis (pour un type chaîne de caractères restreinte et contrainte): a
contrainte unique d'alphabet permis que l'on peut appliquer à un type natif chaîne de caractères à multiplicateur connu,
dont l'effet sera de permettre tous les caractères - et seulement ceux-ci - qui peuvent occuper une position de caractère
quelconque dans n'importe quelle valeur contenue dans le type chaîne contrainte.
NOTE - Une contrainte effective d'alphabet permis sera soit l'alphabet entier du type chaîne de caractères non restreinte ou
une spécification d'alphabet permis qui se trouvera ëtre un surensemble de toutes les contraintes d'alphabet permis qui sont imposées à
ce type. Par exemple, dans la définition suivante:
Ax ::= IASString ~OM("AB")IFROM("CD"))
Bx ::= IASString (SIZE(1.A) I FROM("abc"))
où la chaîne "Ax" obéit à une contrainte effective d'alphabet permis qui consiste en l'alphabet IASString, puisque aucune contrainte
d'alphabet permis ne s'applique à toutes les valeurs de "Ax". I1 en est de même pour "Bx". Par ailleurs, la définition suivante obéit à la
contrainte effective d'alphabet permis pour les caractères "ABCDE car elle spécifie une contrainte d'alphabet permis applicable à
toutes ces valeurs:
A ::= IASString (FROM("AB") I FROM("CD") I FROM("ABCDE"))
3.8.10 index d'énumération: nombre entier non négatif associé à un item dans un type énuméré (enumerated). Les
index d'énumération sont déterminés en classant les items par ordre croissant de la valeur énumérée, puis en affectant un
index d'énumération égal à O pour le premier item, à 1 pour le deuxième, etc., jusqu'au dernier élément de la liste ainsi
ordonnée.
NOTE - Les items de base ("RootEnumeration") et les items additionnels (" AdditionalEnumeration") sont triés
séparément.
3.8.11 extensibilité au codage compact: propriété dun type dont la définition contient un marqueur d'extension qui
affecte le codage selon les règles PER.
3.8.12 liste de champs: ensemble ordonné de valeurs de champ binaire et/ou de champ binaire calé à l'octet qui
résulte de l'application des présentes règles de codage aux composantes dune valeur.
NOTE - (Didactique) Le modèle employé dans la présente Recommandation I Norme internationale utilise le terme "liste
de champs" pour indiquer une liste liée de registres contenant chacun une séquence codée, une longueur en bits ou un indicateur
de calage à l'octet du "champ binaire" ou du "champ binaire calé à l'octet''. Chaque séquence codée correspond à une valeur dun
type ASN.l. L'indicateur de calage à l'octet précise si cette séquence codée doit être calée sur une limite d'octet lorsqu'elle est utilisée
pour former le codage complet de la valeur en syntaxe abstraite; il peut également préciser s'il convient d'insérer cette séquence codée
immédiatement après le dernier bit de la précédente séquence codée du codage complet. La notion de "liste de champs" n'a de
fonction que descriptive et ne propose aucune méthode de mise en œuvre.
3.8.13 longueur non définie: codage dont la longueur est supérieure à 64K - 1 ou dont la longueur maximale ne peut
pas être déterminée d'après la notation ASN. 1.
3.8.14 type de longueur fme: type tel que l'on puisse déterminer - à partir de la notation de type (après application
des seules contraintes visibles par les règles PER) - la valeur du déterminant de longueur le plus extérieur dans une
séquence codée de ce type (au moyen des mécanismes spécifiés dans la présente Recommandation I Norme
internationale) et tel que cette valeur soit la même pour toutes les valeurs possibles de ce type.
4 Rec. UIT-T X.691(1995 F)
ISOKEI 8825-2:1996(F)
3.8.15 valeur fixe: valeur telle qu'elle puisse être déterminée (au moyen des mécanismes spécifiés dans la présente
Recommandation I Norme internationale) comme étant la seule valeur permise (après application des seules contraintes
visibles par les règles PER) du type dont elle dépend.
3.8.16 type chaîne de caractères à multiplicateur connu: type de chaîne de caractères restreinte dont le nombre
d'octets codés est un multiple fixe et connu du nombre de caractères contenus dans la chaîne de caractères pour toutes les
valeurs permises de la chaîne de caractères. Les types chaîne de caractères à multiplicateur connu sont les suivants:
IASString, Printablestring, Visiblestring, Numericstring, UniversalString et BMPString.
déterminant de longueur: compte (de bits, d'octets, de caractères ou de composantes) qui détermine la
3.8.17
longueur de tout ou partie dune séquence à codage PER.
nombre entier non négatif normalement petit: partie dune séquence codée qui représente un entier non
3.8.18
négatif et non délimité, mais dont les petites valeurs sont normalement plus fréquentes que les grandes.
3.8.19 longueur normalement petite: codage dune longueur qui représente les valeurs d'une longueur non délimitée,
mais telle que les petites valeurs de cette longueur soient normalement plus fréquentes que les grandes.
3.8.20 champ binaire calé à l'octet: produit issu dune partie du mécanisme de codage, composé dun ensemble
ordonné d'éléments binaires qui n'est pas nécessairement un multiple de 8 mais qui doit commencer à une limite d'octet,
dans le codage complet de la valeur de syntaxe abstraite.
3.8.21 codage d'entier binaire non négatif: codage dun nombre entier contraint ou semi-contraint pour obtenir soit
un champ binaire de longueur spécifiée, soit un champ binaire calé à l'octet et de longueur spécifiée, soit encore le
nombre minimal d'octets permettant de représenter ce nombre entier sous la forme dun entier binaire non négatif, dont le
codage permet de représenter des nombres entiers supérieurs ou égaux à zéro, comme spécifié au 10.3.
NOTE - La valeur dun nombre binaire en complément à deux est obtenue en numérotant les bits des octets qui le
composent, en commençant par le bit 1 du dernier octet qui devient le bit O et en terminant par le bit 8 du premier octet. A chaque bit
est affectée une valeur numérique de 2N, N est la position du bit dans la séquence de numérotation précédente. La valeur du nombre
binaire en complément à deux est obtenue en ajoutant les valeurs numériques affectées à chacun des bits qui sont mis à 1.
contrainte visible par les règles PER: instance d'utilisation de la notation de contraintes ASN. 1 qui affecte le
3.8.22
codage PER dune valeur.
3.8.23 codage à compatibilité assurée: codage complet dune valeur de syntaxe abstraite qui peut être décodée (y
compris tous modules encastrés) sans connaissance de l'ensemble contextuel qui a été défini pour la couche présentation
afin de former l'environnement d'exécution du codage.
3.8.24 nombre entier semi-contraint: nombre entier obéissant à des contraintes visibles par les règles PER de façon
à être égal ou supérieur à une certaine valeur "lb", celle-ci étant une valeur permise et non pas un nombre entier
contraint.
NOTE - Des nombres entiers semi-contraints apparaissent dans le codage de la longueur des types chaîne de caractères,
chaîne d'octets et chaîne binaire non contraints (et parfois contraints), dans le compte du nombre de composantes contenues dans des
types séquence-de et ensemble-de non contraints (et parfois contraints) et dans la valeur dun type entier qui a été contraint à dépasser
une certaine valeur minimale.
3.8.25 type simple: type qui n'est pas composite.
3.8.26 contextuellement dépendante: terme utilisé pour qualifier le cas où, si un certain nom de référence est utilisé
pour évaluer un ensemble d'éléments, la valeur de celui-ci est considérée comme dépendant de ce nom de référence, que
l'opération arithmétique en cours d'exécution réelle soit ou non telle que la valeur de l'ensemble d'éléments soit
indépendante de la valeur d'ensemble d'éléments réellement affectée au nom de référence.
NOTE - Par exemple, la définition suivante de la variable métasyntaxique "Foo" dépend textuellement de la variable
"Bar", bien que celle-ci n'ait aucun effet sur l'ensemble des valeurs de "Foo" (selon le 9.3.4, la contrainte sur la variable "Foo" n'est
pas visible, puisque "Bar" est soumise à une contrainte tabulaire et que "Foo" dépend textuellement de "Bar").
MY-CLASS ::= CLASS { &name Printablestring, &age INTEGER } WITH SYNTAX{&name , &age}
MyObjectSet MY-CLASS ::= { {"Jack", 7) I {"Jill", 5) }
Bar ::= MY-CLASS.&age ({MyObjectSet})
Foo ::= INTEGER (Bar I 1.100)
3.8.27
nombre entier non contraint: nombre entier qui n'est pas soumis à des contraintes visibles par les règles PER.
NOTE - Des nombres entiers non contraints n'apparaissent que dans le codage dune valeur de type entier.
Rec. UIT-T X.691(1995 F) 5
ISO/CEI 8825-2: 1996(F)
4 Abréviations
ASN. 1 Notation de syntaxe abstraite numéro un (abstract syntax notation one)
BER Règles de codage de base de l'ASN.l (basic encoding rules of ASN.1)
PER Règles de codage compact de I'ASN. 1 (packed encoding rules of ASN. I)
CER Règles de codage canonique de I'ASN. 1 (canonical encoding rules of ASN.Z)
16K 16384
32K 32768
48K 49152
64K 65536
5 Notation
La présente Recommandation I Norme internationale fait référence à la notation définie par la Rec. UIT-T X.680 I
ISO/CEI 8824-1.
6 Conventions
6.1 La présente Recommandation I Norme internationale définit la valeur de chaque octet codé en utilisant les
expressions "bit le plus significatif ' et "bit le moins significatif'.
NOTE - Les spécifications relatives aux couches inférieures utilisent la même notation pour définir l'ordre de transmission
des bits sur un circuit série, ou d'affectation des bits à des canaux parallèles.
Pour les besoins de la présente Recommandation I Norme internationale, les bits dun octet sont numérotés de 8
6.2
à 1, le 8e bit étant le "bit le plus significatif' et le le* bit le "bit le moins significatif'.
6.3 Dans la présente Recommandation I Norme internationale, le terme "octet" a souvent le sens de "huit éléments
binaires". L'emploi du terme "octet" au lieu de "8 éléments binaires" n'implique aucune prescription d'alignement. Si
celui-ci est recherché, cela est explicitement déclaré dans la présente Recommandation I Norme internationale.
7 Règles de codage définies dans la présente Recommandation I Norme internationale
7.1 La présente Recommandation I Norme internationale spécifie quatre règles de codage (ainsi que leurs
identificateurs d'objet associés). Ces quatre règles pourront être utilisées pour coder et décoder les valeurs dune syntaxe
a
abstraite définie comme contenant les valeurs dun seul type ASN.1 (connu). Le présent article décrit l'applicabilité et les
propriétés de ces règles.
7.2 Si l'on ne connaît pas le type de la valeur à coder, il n'est pas possible de déterminer la structure du codage
(selon l'un des algorithmes des règles de codage compact). En particulier, la fin dune séquence codée ne peut pas être
déterminée d'après cette séquence si l'on ne connaît pas le type qui est codé.
7.3 Les codages PER sont toujours à compatibilité assurée, à condition que les valeurs abstraites des types
EXTERNAL,, EMBEDDED PDV et CHARACTER STRING soient contraintes de manière à empêcher l'acheminement
d'identificateurs de contexte de présentation.
7.4 L'algorithme de règle de codage le plus général, spécifié dans la présente Recommandation I Norme
internationale, est de type BASIC-PER, qui ne produit généralement pas de codage canonique.
7.5 Un deuxième algorithme de règle de codage, spécifié dans la présente Recommandation I Norme interna-
tionale, est de type CANONICAL-PER, qui produit généralement des codages canoniques. I1 est défini sous la forme
dune restriction des choix dépendant de la mise en œuvre dans le codage de type BASIC-PER. L'algorithme
CANONICAL-PER produit des codages canoniques qui ont des applications lorsqu'il faut appliquer des authenti-
ficateurs à des valeurs abstraites, comme décrit dans l'Annexe D de la Rec. UIT-T X.690 I ISOKEI 8825- 1.
NOTE - Toute mise en œuvre codable selon les règles de type CANONICALPER est conforme aux règles de codage
BASIC-PER. Toute mise en œuvre décodable selon les règles de type BASIC-PER est conforme aux règles de décodage
CANONICAL-PER. Les codages effectués selon les règles CANONICAL-PER sont donc autorisés par les règles BASIC-PER.
6 Rec. UIT-T X.691(1995 F)
ISO/CEI 8825-2: 1996(F)
7.6 Si un type codé selon les règles BASIC-PER ou CANONICAL-PER contient des types comme EMBEDDED
PDV, CHARACTER STRING ou EXTERNAL, le codage extérieur perd son assurance de compatibilité, à moins que la
syntaxe de transfert utilisée pour tous ces types (EMBEDDED PDV, CHARACTER STRING et EXTERNAL) soit elle-
même à compatibilité assurée. Si un type codé selon les règles BASIC-PER ou CANONICAL-PER contient des types
comme EMBEDDED PDV, EXTERNAL ou CHARACTER STRING, le codage extérieur perd son caractère canonique,
à moins que la syntaxe de transfert utilisée pour tous ces types (EMBEDDED PDV, EXTERNAL et CHARACTER
STRING) ne soit elle-même canonique.
NOTE - Les syntaxes de transfert de caractères, prenant en charge toutes les syntaxes abstraites en mode caractère de la
forme {iso standard 10646 level-1 (1) .} sont canoniques. Celles qui prennent en charge des syntaxes de la forme {iso standard
(2) .) et (is0 standard 10646 level-3 (3) .) ne sont pas toujours canoniques. Toutes les syntaxes de transfert de
10646 level-2
caractères susmentionnées sont à compatibilité assurée.
7.7 Les règles BASIC-PER et CANONICAL-PER ont chacune deux variantes: ALIGNED et UNALIGNED. Dans
la variante ALIGNED, des bits de bourrage sont insérés de temps en temps afin de restaurer l'alignement en octets. Dans
la variante UNALIGNED, aucun bit de bourrage n'est jamais inséré.
7.8 I1 n'existe aucune possibilité dinterfonctionnement entre la variante ALIGNED et la variante UNALIGNED.
7.9 Les codages compacts (selon les règles PER) ne sont autodélimitants que si l'on connaît le type de la valeur
codée. Les codages sont toujours un multiple de 8 éléments binaires. Lorsqu'ils sont acheminés dans un type
EXTERNAL, ils doivent figurer dans l'option OCTET STRING, à moins que le type EXTERNAL soit lui-même en
codage compact, auquel cas la valeur peut être codée sous la forme d'un unique type ASN.1 (c'est-à-dire comme un type
ouvert). Lorsque les codages compacts sont acheminés dans un protocole de couche présentation de I'OSI, le "codage
complet" (tel que défini dans la Rec. UIT-T X.226 I ISO/CEI 8823-1) doit être utilisé avec l'option OCTET STRING.
Les règles de la présente Recommandation I Norme internationale s'appliquent aux deux algorithmes et aux
7.10
deux variantes, sauf indication contraire.
7.11 L'Annexe C est informative et donne des recommandations sur les combinaisons de règles PER à mettre en
œuvre afin de maximiser les chances dinterfonctionnement.
8 Conformité
La conformité dynamique est spécifiée à partir de l'article 9.
8.1
8.2 La conformité statique est spécifiée par les règles d'application des présentes règles de codage compact.
NOTE - L'Annexe C de la présente Recommandation I Norme internationale donne des directives sur la conformité
statique afin d'assurer le support des deux variantes des deux algorithmes de codage. Ces directives sont conçues de façon à assurer
l'interfonctionnement, tout en admettant que, pour certaines applications, il peut être préférable de suivre des règles de codage qui ne
sont ni à compatibilité assurée ni canoniques.
8.3 Les règles contenues dans la présente Recommandation I Norme internationale sont spécifiées en termes de
procédure de codage. Les mises en œuvre ne sont pas tenues de refléter intégralement la procédure spécifiée, à condition
que la chaîne binaire produite comme codage complet dune valeur de syntaxe abstraite, soit identique à l'une des chaînes
binaires spécifiées dans la présente Recommandation I Norme internationale pour la syntaxe de transfert applicable.
8.4 Les mises en œuvre effectuant le décodage sont tenues de produire la valeur de syntaxe abstraite correspondant
à toute chaîne binaire reçue en provenance dun expéditeur se conformant aux règles de codage indiquées dans la syntaxe
de transfert associée aux données à décoder.
NOTES
1 on ne définit pas de variantes de codage pour les règles BASIC-PER qui sont explicitement déclarées
En général,
dans la présente Recommandation I Norme internationale. Le codage BASIC-PER devient canonique lorsque l'on spécifie un
fonctionnement à compatibilité assurée et que l'on restreint certaines des options de codage indiquées par d'autres Normes ISOKEI
citées en référence. L'algorithme CANONICAL-PER offre une variante, aussi bien aux règles de codage distinctif (DER) qu'aux
règles de codage canonique (CER) (voir la Rec. UIT-T X.690 I ISOKEI 8825-l), lorsqu'il est nécessaire de disposer dun codage
canonique à compatibilité assurée.
2 Lorsque l'algorithme CANONICAL-PER est utilisé pour produire un codage canonique, il est recommandé que toute
valeur chiffrée à codage dispersé qui en est dérivée dispose dun identificateur d'algorithme associé qui indique que l'algorithme
CANONICAL-PER a été utilisé pour transformer la valeur abstraite en une chaîne binaire initiale (dispersée par la suite).
Rec. UIT-T X.691(1995 F) 7
ISO/CEI 8825-2:1996(F)
préambule longueur préambule longueur contenu préambule longueur contenu .
contenu
NOTE - Le préambule, la longueur et le contenu sont des "champs" dont la concaténation forme une "liste de champs". La liste de
champs d'un type composite différent du type choix (Choice) peut être formée par la concaténation de champs de valeur différente.
Le préambule, la longueur et/ou le contenu peuvent ne pas figurer, quelle que soit leur valeur.
Figure 1 - Codage d'une valeur composite dans une liste de champs
9.5.2 Le codage dune composante de valeur de données est constitué dune des deux manières suivantes:
comprend trois parties, comme représenté à la Figure 1, qui apparaissent dans l'ordre suivant:
a)
un préambule (voir articles 18,20 et 22);
1)
un déterminant de longueur (voir 10.9);
2)
3) un contenu;
ou bien (si le contenu est important), un nombre quelconque de parties (comme représenté à la Figure 2),
b)
dont la première est un préambule (voir articles 18, 20 et 22), les parties suivantes étant des paires de
à l'octet, le premier champ étant un déterminant de longueur pour un fragment du
champs binaires calés
contenu et le deuxième étant ce fragment de contenu; la dernière paire de champs est identifiée par la
partie contenant le déterminant de longueur, comme spécifié au 10.9.
contenu
préambule longueur contenu longueur contenu . Ion g u e u r (peut ne pas
figurer)
9.5.3 Chacune des parties mentionnées au 9.5.2 produit un des résultats suivants:
a) un champ nul (néant);
b) un champ binaire;
un champ binaire calé à l'octet;
c)
une liste de champs pouvant contenir des champs binaires, ou des champs binaires calés à l'octet, ou les
d)
deux sortes.
9.6 Types à coder
9.6.1 Les articles suivants spécifient le codage des types suivants pour créer une liste de champs: booléen, entier,
énuméré, réel, chaîne binaire, chaîne d'octets, néant, séquence, séquence-de, ensemble, ensemble-de, choix, ouvert,
identificateur d'objet, valeurs PDV encapsulées, externe, chaîne de caractères restreinte et chaîne de caractères non
restreinte.
Le type ANY, défini dans la Rec. X.208 du CCITT (1988) I ISOKEI 8824: 1990 doit être codé comme un type
9.6.2
ouvert.
9.6.3 Le type de sélection doit être codé sous forme de séquence codée du type sélectionné.
9.6.4 Le codage dun type étiqueté n'est pas traité dans la présente Recommandation I Norme internationale car, sauf
dans le cas stipulé au 9.2, l'étiquetage n'est pas visible dans le modèle type et valeur utilisé pour les présentes règles de
codage. Un type étiqueté est donc codé comme le type correspondant qui a été étiqueté.
10 Rec. UIT-T X.691(1995 F)
ISO/CEI 8825-2:1996(F)
Les "types utiles" suivants, définis à l'article 38 de la Rec. UT-T X.680 I ISOKEI 8824-1, doivent être codés
9.6.5
comme s'ils avaient été remplacés par leurs définitions selon la Rec. UIT-T X.680 I ISO/CEI 8824-1:
- temps généralisé;
- temps universel;
- descripteur d'objet.
Les contraintes sur les types utiles ne sont pas visibles par les règles PER.
10 Procédures de codage
10.1 Production du codage complet
10.1.1 La liste de champs produite par l'application des règles de la présente Recommandation I Norme internationale
à la valeur la plus externe doit être utilisé
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...