ISO 9735-1:1998
(Main)Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4) — Part 1: Syntax rules common to all parts, together with syntax service directories for each of the parts
Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4) — Part 1: Syntax rules common to all parts, together with syntax service directories for each of the parts
Échange de données informatisé pour l'administration, le commerce et le transport (EDIFACT) — Règles de syntaxe au niveau de l'application (numéro de version de syntaxe: 4) — Partie 1: Règles de syntaxe communes à l'ensemble des parties, accompagnées des répertoires de service syntaxiques associés à chacune d'elles
General Information
Relations
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 9735-1
First edition
1998-10-01
Electronic data interchange for
administration, commerce and transport
(EDIFACT) — Application level syntax
rules (Syntax version number: 4) —
Part 1:
Syntax rules common to all parts, together with
syntax service directories for each of the parts
Échange de données informatisées pour l'administration, le commerce et le
transport (EDIFACT) — Règles de syntaxe au niveau de l'application
(Numéro de version de syntaxe: 4) —
Partie 1: Règles de syntaxe communes à toutes les parties, et annuaires de
syntaxe pour chacune des parties
A
Reference number
ISO 9735-1:1998(E)
---------------------- Page: 1 ----------------------
ISO 9735-1:1998(E)
Contents
Page
1 Scope. 1
2 Conformance . 1
3 Normative references. 1
4 Definitions . 2
5 Service characters. 2
6 Character repertoires . 3
7 Syntax structures . 4
8 Inclusion and exclusion. 5
9 Suppression of characters within data elements. 8
10 Representation of numeric data element values. 9
11 Dependency notes. 9
12 Segment collision prevention . 11
Annex A (normative): Definitions. 12
Annex B (normative): UNA service string advice . 17
Annex C (normative): Service directories (service segments, service
composite data elements and service simple data elements) . 18
Annex D (informative): Service code directory. 60
Annex E (informative): Order of segments and groups of segments
within a message . 61
Annex F (informative): The use of anti-collision segment group
UGH/UGT . 64
© ISO 1998
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.
International Organization for Standardization
Case postale 56 • CH-1211 Genève 20 • Switzerland
Internet iso@iso.ch
Printed in Switzerland
ii
---------------------- Page: 2 ----------------------
©
ISO ISO 9735-1:1998(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO
member bodies). The work of preparing International Standards is normally carried out through ISO technical
committees. Each member body interested in a subject for which a technical committee has been established has
the right to be represented on that committee. International organizations, governmental and non-governmental, in
liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
Draft International Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.
This part of ISO 9735 was prepared by the UN/ECE Trade Division (as UN/EDIFACT) and was adopted, under a
Documents and data elements in
special “fast-track procedure”, by Technical Committee ISO/TC 154,
administration, commerce and industry.
Together with ISO 9735-2, this part of ISO 9735 cancels and replaces ISO 9735:1988 (amended and reprinted
in 1990) and Amendment 1:1992.
Whereas this part supersedes the earlier publications, and shall use a version number of “4” in the mandatory data
element 0002 (Syntax version number) in the segment UNB (Interchange header), interchanges continuing to use
the syntax defined in the earlier published versions shall use the following Syntax version numbers, in order to
differentiate them from each other and from this part:
ISO 9735:1988 — Syntax version number: 1
ISO 9735:1988 (amended and reprinted in 1990) — Syntax version number: 2
— Syntax version number: 3
ISO 9735:1988 (amended and reprinted in 1990) plus Amendment 1:1992
ISO 9735 consists of the following parts, under the general title Electronic data interchange for administration,
commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4):
— Part 1: Syntax rules common to all parts, together with syntax service directories for each of the parts
— Part 2: Syntax rules specific to batch EDI
— Part 3: Syntax rules specific to interactive EDI
— Part 4: Syntax and service report message for batch EDI (message type - CONTRL)
— Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin)
— Part 6: Secure authentication and acknowledgement message (message type - AUTACK)
— Part 7: Security rules for batch EDI (confidentiality)
— Part 8: Associated data in EDI
— Part 9: Security key and certificate management message (message type - KEYMAN)
— Part 10: Security rules for interactive EDI
Further parts may be added in the future.
Annexes A, B and C form an integral part of this part of ISO 9735.
Annexes D and E are for information only.
iii
---------------------- Page: 3 ----------------------
©
ISO 9735-1:1998(E) ISO
Introduction
This part of ISO 9735 includes the rules at the application level for the structuring of data in the interchange of
electronic messages in an open environment, based on the requirements of either batch or interactive processing.
These rules have been agreed by the United Nations Economic Commission for Europe (UN/ECE) as syntax rules
for Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT) and are part of the United
Nations Trade Data Interchange Directory (UNTDID) which also includes both batch and interactive Message
Design Guidelines.
This part of ISO 9735 may be used in any application, but messages using these rules may only be referred to as
EDIFACT messages if they comply with other guidelines, rules and directories in the UNTDID. For UN/EDIFACT,
messages shall comply with the message design rules for batch or interactive usage as applicable. These rules are
maintained in the UNTDID.
Communications specifications and protocols are outside the scope of this part of ISO 9735.
A previous version of ISO 9735 was published in 1988 as a single part. The current version of ISO 9735 consists of
multiple parts and incorporates enhancements to extend its application.
This part of ISO 9735 is a re-draft of corresponding sections in the previous version of ISO 9735. It consists of the
rules common to all parts of ISO 9735, and includes the definitions and service directories for all parts.
The basic syntax rules specified in this part remain unchanged from the previous version, with the exception that
the coverage of character repertoires has been extended, and two new techniques have been introduced (the
provision for 'dependency notes' and the introduction of a service repetition character, to support the capability of
permitting multiple occurrences (repeats) of stand-alone and/or composite data elements). Both of these
techniques are used in other parts of the current version of ISO 9735, and are available for specification in
EDIFACT messages which utilise this International Standard.
In addition, enhancements have been made to the batch interchange; group; and message header segments (UNB;
UNG; and UNH).
Character repertoires: Because of the widening use of ISO 9735, it has become necessary to extend its coverage
to include all character repertoires covered by ISO 8859, Parts 1-9 (Information processing — 8-Bit single – byte
coded graphic character sets)
; the code extension techniques covered by ISO 2022 (with certain restrictions on its
use within an interchange); and partial use of the techniques covered by ISO/IEC 10646-1.
Dependency notes: These provide a formal notation to express relationships in EDIFACT message, segment and
composite data element specifications.
Repeating data elements: The specification of multiple occurrences of a message within a group or within an
interchange; a group within an interchange; and a segment group and/or a segment within a message, which
existed in the previous version of ISO 9735, has been extended in the current version. The additional capability for
the specification of multiple occurrences of a stand-alone data element and/or of a composite data element within a
segment has been introduced.
UNB - Interchange header segment: This segment has been enhanced to permit the identification of the service
code list directory version number; identification of the character encoding scheme; and internal sub-identification of
the sender and recipient. In addition, to conform to year 2000 requirements, the date format in this segment has
been extended.
UNG - Group header segment: This segment has been re-named and its function changed to permit one or more
message types and/or packages to be contained in the group. As a result, certain data elements, which are now
redundant, have been marked for deletion. In addition, to conform to year 2000 requirements, the date format in this
segment has been extended.
UNH - Message header segment: This segment has been enhanced to permit the identification of a message
subset; of a related message implementation guideline; and of a related scenario.
iv
---------------------- Page: 4 ----------------------
©
ISO ISO 9735-1:1998(E)
An addition has been made to permit the prevention of collision, by use of the UGH/UGT segment group. This
technique shall be used in a message specification when it is not otherwise possible to ensure unambiguous
identification of each message segment upon receipt.
v
---------------------- Page: 5 ----------------------
©
INTERNATIONAL STANDARD ISO ISO 9735-1:1998(E)
Electronic data interchange for administration, commerce and
transport (EDIFACT) — Application level syntax rules
(Syntax version number: 4) —
Part 1:
Syntax rules common to all parts, together with syntax service
directories for each of the parts
1 Scope
This part of ISO 9735 specifies common syntax rules for the formatting of batch and interactive messages to
be interchanged between computer application systems. It includes the definitions and service directories
for all parts comprising ISO 9735.
2 Conformance
Conformance to a standard means that all of its requirements, including all options, are supported. If all
options are not supported, any claim of conformance shall include a statement which identifies those options
to which conformance is claimed.
Data that is interchanged is in conformance if the structure and representation of the data conforms to the
syntax rules specified in this International Standard.
Devices supporting this International Standard are in conformance when they are capable of creating and/or
interpreting the data structured and represented in conformance with the standard.
Conformance shall be based on this part, and at least either ISO 9735-2 or ISO 9735-3.
When identified in this International Standard, provisions defined in related standards shall form part of the
conformance criteria.
3 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this
part of ISO 9735. At the time of publication, the editions indicated were valid. All standards are subject to
revision, and parties to agreements based on this part of ISO 9735 are encouraged to investigate the
possibility of applying the most recent editions of the standards indicated below. Members of IEC and ISO
maintain registers of currently valid International Standards.
ISO 639:1988, Code for the representation of names of languages.
Information technology — ISO 7-bit coded character set for information interchange
ISO/IEC 646:1991, .
1
---------------------- Page: 6 ----------------------
©
ISO
ISO 9735-1:1998(E)
ISO/IEC 2022:1994, Information technology — Character code structure and extension techniques.
ISO/IEC 2382-1:1993, Information technology — Vocabulary — Part 1: Fundamental terms.
ISO 2382-4:1987, Information processing systems — Vocabulary — Part 04: Organization of data.
Information processing — Representation of numerical values in character strings for
ISO 6093:1984,
information interchange.
ISO/IEC 6429:1992, Information technology — Control functions for coded character sets.
ISO 6523:1984, Information technology — Structure for the identification of organizations.
ISO 8601:1988, Data elements and interchange formats — Information interchange — Representation of
dates and times.
Electronic data interchange for administration, commerce and transport (EDIFACT) —
ISO 9735-2:1998,
Application level syntax rules (Syntax version number: 4) — Part 2: Syntax rules specific to batch EDI
.
ISO 9735-3:1998, Electronic data interchange for administration, commerce and transport (EDIFACT) —
Application level syntax rules (Syntax version number: 4) — Part 3: Syntax rules specific to interactive EDI.
ISO/IEC 10646-1:1993, Information technology — Universal Multiple-Octet Coded Character Set (UCS) —
Part 1: Architecture and Basic Multilingual Plane.
4 Definitions
For the purposes of this International Standard, the definitions in annex A apply.
5 Service characters
The service characters are the component data element separator, data element separator, release
character, repetition separator, and segment terminator.
The component data element separator, data element separator, repetition separator, and segment
terminator delineate various syntax structures as defined in clause 7.
The purpose of the release character is to allow the use of a character that would otherwise be interpreted as
a service character. The character immediately following the release character in a interchange shall not be
interpreted as a service character.
When used, the release character is not counted in the length of the data element value.
NOTE - Using default service characters shown below, 10?+10=20 appearing in a data transfer shall be interpreted on
receipt as 10+10=20. A question mark in a data element value is represented in transfer as ??.
2
---------------------- Page: 7 ----------------------
©
ISO
ISO 9735-1:1998(E)
5.1 Default service characters
The default service characters reserved for use in this International Standard are:
Graphic
Name Representation Functionality
Colon : component data element separator
Plus sign + data element separator
Question mark ? release character
Asterisk * repetition separator
Apostrophe ' segment terminator
5.2 UNA, service string advice
The conditional service string advice (UNA) provides the capability to specify the service characters used in
the interchange (see annex B). The UNA service string advice shall be used if the service characters differ
from the defaults (see clause 5.1). Its use is optional if the default characters are used.
When used, the service string advice shall appear immediately before the interchange header segment.
6 Character repertoires
The character encoding specified in basic code table of ISO/IEC 646 (7-bit coded character set for
information interchange) shall be used for the interchange service string advice (if used) and up to and
including the composite data element S001 ‘Syntax identifier’ in the interchange header.
The character repertoire used for the characters in an interchange shall be identified from the code value of
data element 0001 in S001 ‘Syntax identifier’ in the interchange header (see Annex D). The character
repertoire identified does not apply to objects and/or encrypted data.
The default encoding technique for a particular repertoire shall be the encoding technique defined by its
associated character set specification.
If the default option is not used, a code value for the data element 0133 'Character encoding, coded' in the
interchange header shall be used.
Code extension technique (ISO/IEC 2022) may only be used in an interchange after the composite data
element S001 ‘Syntax identifier’ in the interchange header.
The code extension technique and its target graphic characters shall only be used for:
- plain language (textual) data elements, with a representation of alphabetic or alphanumeric.
The technique shall not be used, for example, for any:
- segment tag, or
- service character, or
- data element with a representation of numeric.
Characters used to indicate code extension shall not be counted in the length of a data element, and shall not
be used as service characters.
In calculating data element length, one graphic character shall be counted as one character, irrespective of
the number of bytes/octets required to encode it.
3
---------------------- Page: 8 ----------------------
©
ISO
ISO 9735-1:1998(E)
7 Syntax structures
The definitions in this clause specify logical syntax structures. Rules to be applied for their usage are defined
in clause 8.
7.1 Interchange structure
An interchange shall be started either by a service string advice or by an interchange header, shall be
identified by an interchange header, shall be terminated by an interchange trailer, and shall contain at least
one group, or one message or one package. There may be more than one group or message and/or
package within an interchange, each identified by its own header and terminated by its own trailer. Messages
within an interchange or within a group may comprise one or more message types.
An interchange shall contain only:
• Messages, or
• Packages, or
• Messages and Packages, or
• Groups containing messages, or
• Groups containing packages, or
• Groups containing messages and packages.
7.2 Group structure
A group is a conditional structure which is located between the interchange header and trailer and which
comprises one or more messages and/or packages.
A group shall be started and identified by a group header, shall be terminated by a group trailer, and shall
contain at least one message or package.
7.3 Message structure
A message comprises an ordered set of segments (see annex E). Segments may be grouped. Each
segment's position, status, and maximum number of occurrences shall be stated in the message
specification.
A given segment within a message specification shall have a status of mandatory or conditional.
A message specification shall ensure unambiguous identification of each message segment upon receipt.
Identification shall be possible on the basis of the segment tag (or the segment tag plus the anti-collision
segment group identification in the UGH and UGT segments) and the segment’s position in the transferred
message. Identification shall not depend on a segment’s status or maximum number of occurrences.
A message shall be started and identified by a message header, shall be terminated by a message trailer,
and shall contain at least one additional segment.
7.4 Segment group structure
A segment group comprises an ordered set of segments: a trigger segment and at least one more segment
or segment group. The trigger segment shall be the first segment in the segment group, shall have a status
of mandatory and a maximum number of occurrences of one. Each segment group's position, status, and
maximum number of occurrences within the message structure shall be stated in the message specification.
A segment group may contain one or more dependent segment groups. When a segment group is contained
within and directly subordinate to another segment group, the subordinate segment group is referred to as
the child, and the other segment group is referred to as the parent.
A given segment group within a message specification shall have a status of mandatory or conditional.
7.5 Segment structure
A segment comprises an ordered set of stand-alone data elements and/or composite data elements, each of
which are permitted to repeat, if so stated in the segment specification. Each stand-alone or composite data
4
---------------------- Page: 9 ----------------------
©
ISO
ISO 9735-1:1998(E)
element's position, status and maximum number of occurrences within the segment structure shall be stated
in the segment specification. A segment shall be started and identified by a segment tag which references a
specific segment specification. A segment shall contain at least one data element in addition to the segment
tag.
A given data element within a segment specification shall have a status of mandatory or conditional.
7.6 Segment tag structure
A segment tag is a simple data element.
Segment tags starting with the letter "U" (e.g. UNB, UIH) shall be reserved for service segments.
7.7 Composite data element structure
A composite data element comprises an ordered set of two or more component data elements. Each
component data element's position and status within the composite data element structure shall be stated in
the composite data element specification.
A given component data element within a composite data element specification shall have a status of
mandatory or conditional.
7.8 Simple data element structure
A simple data element contains a single data element value.
A simple data element is used either as a stand-alone data element or as a component data element. A
stand-alone data element occurs in a segment outside a composite data element. A component data
element occurs within a composite data element.
Each simple data element's data value representation shall be stated in the data element specification.
7.9 Package structure
A package shall be started and identified by an object header, shall be terminated by an object trailer, and
shall contain one object.
8 Inclusion and exclusion
The rules in this clause shall be applied when a message is prepared for transfer. Under these rules, in
certain circumstances, segment groups, segments, data elements, and characters within a data element
value, shall be present, while in other circumstances shall be omitted.
8.1 Determination of presence
A simple data element is considered present if its data element value contains at least one character.
A composite data element is considered present if at least one of its component data elements is present.
A segment is considered present if its segment tag is present.
A segment group is considered present if its trigger segment is present.
8.2 Inclusion of segment groups
A mandatory segment group which is not contained within another segment group shall be present.
A mandatory child segment group shall be present if its parent segment group is present.
A single occurrence of a segment group having a status of mandatory is sufficient to satisfy the mandatory
requirement.
5
---------------------- Page: 10 ----------------------
©
ISO
ISO 9735-1:1998(E)
8.3 Exclusion of segment groups
If a segment group is omitted, all of its segments and any dependent segment groups contained within it,
regardless of their status, shall also be omitted.
8.4 Inclusion of segments
Segments shall appear in the order stated in the message specification.
A segment shall be terminated by a segment terminator.
A mandatory segment which is not in a segment group shall be present.
A mandatory segment contained in a segment group shall be present if the segment group is present.
A single occurrence of a segment having a status of mandatory is sufficient to satisfy the mandatory
requirement.
Using a fictitious segment tag of ABC as an example, a mandatory segment defined as containing only
conditional data elements for which no data is present at the time of transfer, shall be transferred in the form
ABC'.
8.5 Exclusion of segments
A conditional segment for which only the segment tag is present shall be omitted in its entirety.
8.6 Inclusion of data elements
Data elements shall appear in the order stated in the segment specification.
Adjacent non-repeating data elements in the same segment shall be separated by a data element separator.
Adjacent occurrences of the same repeating data element in a segment shall be separated by a repetition
separator.
Adjacent component data elements in the same composite data element shall be separated by a component
data element separator.
A mandatory stand-alone data element in a segment shall be present if the segment is present.
A mandatory composite data element in a segment shall be present if the segment is present.
A mandatory component data element in a composite data element shall be present if the composite data
element is present.
A single occurrence of a repeating data element having a status of mandatory is sufficient to satisfy the
mandatory requirement.
6
---------------------- Page: 11 ----------------------
©
ISO
ISO 9735-1:1998(E)
8.7 Exclusion of data elements
In the figures in the following sub-clauses, "Tag" represents a segment tag, "DE" represents a composite
data element or stand-alone data element, and "CE" represents a component data element. The default
service characters are used.
8.7.1 Exclusion of composite data elements and stand-alone data elements
If a non-repeating composite data element or stand-alone data element is omitted and is followed by a
another composite data element or stand-alone data element in the same segment, its position shall be
indicated by retention of the data element separator which would normally follow it. This rule also applies if
all occurrences of a repeating data element are omitted.
Tag+DE+DE+++DE+DE+DE'
Two data elements have been omitted.
Figure 1 - Exclusion of non-repeating data elements within a segment
If one or more non-repeating composite data elements or stand-alone data elements at the end of a segment
are omitted, the data element separators which would normally follow them shall also be omitted.
Tag+DE+DE+++DE'
Using the example structure in figure 1, the last two
data elements have been omitted.
Figure 2 - Exclusion of non-repeating data elements at the end of a segment
8.7.2 Exclusion of component data elements
If a component data element is omitted and is followed by another component data element in the same
composite data element, its position shall be indicated by retention of the component data element separator
which would normally follow it.
Tag+DE+:CE:CE+CE:::CE'
Two component data elements have been omitted.
One component data element has been omitted.
Figure 3 - Exclusion of component data elements within a composite data element
7
---------------------- Page: 12 ----------------------
©
ISO
ISO 9735-1:1998(E)
If one or more component data elements at the end of a composite data element are omitted, the component
data element separators which would normally follow them shall also be omitted.
Tag+DE+:CE+CE'
Using the example structure in figure 3, the last
component data element in the first composite data
element and the last component data element in
the last composite data element have been
omitted.
Figure 4 - Exclusion of component data elements at the end of a composite data element
8.7.3 Exclusion of occurrences of repeating data elements
The position of an occurrence of a repeating data element may be significant, for example, to transfer array
data.
In such a case, if an occurrence of a repeating data element is omitted and is followed by another occurrence
of the same repeating data element, its position shall be indicated by retention of the repetition separator
which would normally follow it.
Tag+DE+DE*DE***DE+DE*DE'
Two occurrences of a repeating data element have
been omitted.
Figure 5 - Exclusion of occurrences within a repeating data element
If one or more occurrences of a repeating data element at the end of a repeating data element are omitted,
the repetition separators which would normally follow them shall also be omitted.
Tag+DE+DE*DE+DE'
Using the example structure in figure 5, the last
occurrence in the first repeating data element, and
the last occurrence in the last repeating data
element have been omitted.
Figure 6 - Exclusion of occurrences at the end of a repeating data element
9 Suppression of characters within data elements
In variable length data elements, insignificant characters shall be suppressed (i.e. omitted from the transfer),
while significant characters shall be present.
9.1 Insignificant characters
In variable length numeric data elements, leading zeroes shall be suppressed. Nevertheless, a single zero
before a decimal mark is allowed. In variable length alphabetic and alphanumeric data elements, trailing
spaces shall be suppressed.
8
---------------------- Page: 13 ----------------------
©
ISO
ISO 9735-1:1998(E)
9.2 Significant zeroes
Significant zeroes shall not be suppressed. A single zero may be significant, for example, to indicate a
temperature or tax rate. Trailing zeroes following the decimal mark may be significant to indicate precision.
9.3 Significant spaces
Significant spaces shall not be suppressed. Leading and embedded spaces may be significant.
A data element value containing only space(s) shall not be allowed.
10 Representation of numeric data element values
For the purposes of this standard, the representation of numeric da
...
NORME ISO
INTERNATIONALE 9735-1
Première édition
1998-10-01
Échange de données informatisé pour
l’administration, le commerce et le
transport (EDIFACT) — Règles de syntaxe
au niveau de l’application (numéro de
version de syntaxe: 4) —
Partie 1:
Règles de syntaxe communes à l’ensemble
des parties, accompagnées des répertoires
de service syntaxiques associés à chacune
d’elles
Electronic data interchange for administration, commerce and transport
(EDIFACT) — Application level syntax rules (Syntax version number: 4) —
Part 1: Syntax rules common to all parts, together with syntax service
directories for each of the parts
Numéro de référence
ISO 9735-1:1998(F)
©
ISO 1998
---------------------- Page: 1 ----------------------
ISO 9735-1:1998(F)
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier peut
être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence autorisant
l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées acceptent de fait la
responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute responsabilité en la
matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info du
fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir l'exploitation de
ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation, veuillez en informer le
Secrétariat central à l'adresse donnée ci-dessous.
© ISO 1998
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’ISO à
l’adresse ci-après ou du comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 734 10 79
E-mail copyright@iso.ch
Web www.iso.ch
Version française parue en 1999
ImpriméenSuisse
ii © ISO 1998 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO 9735-1:1998(F)
Sommaire Page
1 Domaine d'application.1
2 Conformité.1
3 Références normatives .1
4 Définitions .2
5 Caractères de service.2
6 Répertoires des caractères.3
7 Structures de la syntaxe .4
8 Inclusion et exclusion .6
9 Suppression de caractères dans les éléments de données .9
10 Représentation des valeurs numériques des éléments de données .10
11 Notes de dépendance.10
12 Prévention de la collision de segments .11
Annexe A (normative) Définitions .13
Annexe B (normative) Avis de chaîne de caractères de service UNA.19
Annexe C (normative) Répertoires de service (segments de service, éléments de données composites
de service et éléments de données simples de service).20
Annexe D (informative) Répertoire des codes de service.67
Annexe E (informative) Ordre des segments et des groupes de segments dans un message .68
Annexe F (informative) Utilisation du groupe de segments anticollision UGH/UGT .71
© ISO 1998 – Tous droits réservés iii
---------------------- Page: 3 ----------------------
ISO 9735-1:1998(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée aux
comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du comité
technique créé à cet effet. Les organisations internationales, gouvernementales et non gouvernementales, en
liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec la Commission
électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI, Partie 3.
Les projets de Normes internationales adoptés par les comités techniques sont soumis aux comités membres pour
vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins des comités
membres votants.
L’attention est appelée sur le fait que certains des éléments de la présente partie de l’ISO 9735 peuvent faire
l’objet de droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable de
ne pas avoir identifié de tels droits de propriété et averti de leur existence.
La Norme internationale ISO 9735-1 a été élaborée par la Division du commerce de la Commission Économique
pour l'Europe des Nations Unies (en tant qu'EDIFACT/ONU) et a été adoptée, selon une procédure spéciale par
«voie express», par le comité technique ISO/TC 154, Documents et éléments d'information dans l'administration, le
commerce et l'industrie.
La présente partie de l’ISO 9735, ainsi que l'ISO 9735-2, annule et remplace l'ISO 9735:1988 (modifiée et
réimprimée en 1990) et l’Amendement 1:1992.
Alors que la présente partie remplace les publications antérieures et qu’un numéro de version «4» doit être attribué
à l’élément de données obligatoire 0002 (numéro de version de syntaxe) du segment UNB (en-tête de l’échange),
les échanges continuant à utiliser la syntaxe définie dans les versions publiées antérieurement doivent reprendre
les numéros suivants de version de syntaxe, afin de se différencier tant les uns des autres que de la présente
partie:
ISO 9735:1988 — Numéro de version de syntaxe: 1
ISO 9735:1988 (modifiée et réimprimée en 1990) — Numéro de version de syntaxe: 2
ISO 9735:1988 (modifiée et réimprimée en 1990) plus Amendement 1:1992 — Numéro de version de
syntaxe: 3
L'ISO 9735 comprend les parties suivantes, présentées sous le titre général Échange de données informatisé pour
l'administration, le commerce et le transport (EDIFACT) — Règles de syntaxe au niveau de l'application (numéro
de version de syntaxe: 4):
� Partie 1: Règles de syntaxe communes à l’ensemble des parties, accompagnées des répertoires de service
syntaxiques associés à chacune d'elles
� Partie 2: Règles de syntaxe spécifiques à l'EDI par lots
� Partie 3: Règles de syntaxe spécifiques à l'EDI interactif
� Partie 4: Message Compte rendu syntaxique et de service pour l'EDI par lots (type de message CONTRL)
� Partie 5: Règles de sécurité pour l'EDI par lots (authentification, intégrité et non-répudiation de l'origine)
� Partie 6: Message sécurisé Authentification et accusé de réception (type de message AUTACK)
iv © ISO 1998 – Tous droits réservés
---------------------- Page: 4 ----------------------
ISO 9735-1:1998(F)
� Partie 7: Règles de sécurité pour l'EDI (confidentialité)
� Partie 8: Données associées en EDI
� Partie 9: Message Gestion de Clés et de certificats de sécurité (type de message KEYMAN)
� Partie 10: Règles de sécurité pour l’EDI interactif
D'autres parties pourront être ajoutées ultérieurement.
Les annexes A, B et C constituent des éléments normatifs de la présente partie de l’ISO 9735. Les annexes D et E
sont données uniquement à titre d’information.
© ISO 1998 – Tous droits réservés v
---------------------- Page: 5 ----------------------
ISO 9735-1:1998(F)
Introduction
La présente partie de l’ISO 9735 comprend les règles qui se situent au niveau de l'application pour la structuration
des données associées à l'échange de messages électroniques dans un environnement ouvert, fondées sur les
prescriptions du traitement ou par lots, ou interactif. Ces règles ont été adoptées par la Commission Économique
pour l'Europe des Nations Unies (CEE/ONU) comme règles de syntaxe pour l'échange de données informatisé
pour l'administration, le commerce et le transport (EDIFACT). Elles font partie du Répertoire d'Échange de
données commerciales des Nations Unies (UNTDID) qui comporte également les Directives pour la conception de
messages, tant par transmission par lots qu'en mode interactif.
La présente partie de l’ISO 9735 peut être utilisée dans toute application, mais seuls les messages qui les
prennent en compte peuvent se prévaloir d'être des messages EDIFACT s'ils respectent les autres directives,
règles et répertoires contenus dans le Répertoire d'échange de données commerciales des Nations Unies. Pour
être EDIFACT/ONU, les messages doivent être conformes aux règles de conception des messages destinés à une
utilisation par lots ou en mode interactif. Ces règles sont maintenues dans le Répertoire d'échange de données
commerciales.
Les spécifications des communications et les protocoles n'entrent pas dans le cadre de la présente partie de
l’ISO 9735.
Une version antérieure de l'ISO 9735, qui ne comprenait qu’une seule partie, a été publiée en 1988. La présente
version de l’ISO 9735 comporte de nombreuses parties, assorties d'enrichissements permettant d'en étendre le
champ d'application.
La présente partie de l'ISO 9735 est une refonte des articles correspondants de la précédente version de
l'ISO 9735. Elle consiste en règles communes à toutes les parties de l'ISO 9735, et comprend les définitions et
répertoires de service associés à chacune d’elles.
Les règles de syntaxe de base définies dans la présente partie restent inchangées par rapport à la précédente
version, à ceci près que le champ des répertoires de caractères a été étendu et que deux techniques nouvelles ont
été ajoutées [le principe de «notes de dépendance» et l'introduction d'un caractère de répétition de service
permettant d'admettre de multiples occurrences (répétitions) d'éléments de données autonomes et/ou d'éléments
de données composites]. Ces deux techniques, auxquelles il est fait référence dans d'autres parties de la présente
version de l'ISO 9735, peuvent servir à la spécification de messages EDIFACT qui s'appuient sur la présente
Norme internationale.
En outre, des enrichissements ont été apportés à l'échange par lots, au groupe et aux segments d'en-tête de
message (UNB, UNG, et UNH).
Répertoire des caractères: en raison de la généralisation de l'utilisation de l'ISO 9735, il s'est avéré nécessaire d'en
étendre le champ d'application en y incorporant tous les répertoires de caractères définis dans l'ISO 8859,
Parties 1 à 9 (Traitement de l’information — Jeux de caractères graphiques codés sur un seul octet), les
techniques d'extension de code définies dans l'ISO 2022 (assorties de certaines restrictions en limitant l'utilisation
au sein d'un échange), ainsi que l'utilisation partielle des techniques définies dans l'ISO 10646-1.
Notes de dépendance: elles donnent une notation formelle permettant d'exprimer des relations dans les
spécifications des messages, des segments et des éléments de données composites EDIFACT.
Éléments de données répétitifs: la définition de multiples occurrences d'un message au sein d'un groupe ou d'un
échange, d'un groupe au sein d'un échange, d'un groupe de segments et/ou d'un segment au sein d'un message,
qui existait dans la précédente version de l'ISO 9735, a été élargie dans la présente version. La possibilité
complémentaire de définir de multiples occurrences d'un élément de données autonome et/ou d'un élément de
données composite au sein d'un segment a été ajoutée.
vi © ISO 1998 – Tous droits réservés
---------------------- Page: 6 ----------------------
ISO 9735-1:1998(F)
Segment d'en-tête d'échange, UNB: ce segment a été enrichi pour permettre l'identification du numéro de version
du répertoire de la liste des codes de service, l'identification du mécanisme de codage des caractères et
l'identification secondaire de l'émetteur et du destinataire. De plus, pour satisfaire aux prescriptions de l’an 2000, le
format de la date contenu dans ce segment a été étendu.
Segment d'en-tête de groupe, UNG: ce segment a reçu une nouvelle dénomination et sa fonction a été modifiée
pour permettre de contenir un ou plusieurs types de messages et/ou de paquets. Il en résulte que certains
éléments de données devenus redondants ont été signalés pour être supprimés. De plus, pour satisfaire aux
prescriptions de l’an 2000, le format de la date contenu dans ce segment a été étendu.
Segment d'en-tête de message, UNH: ce segment a été enrichi pour permettre l'identification d'un sous-ensemble
de message, d'un guide de mise en œuvre d'un message et d'un scénario associés.
Un ajout constitué du groupe de segments UGH/UGT a été apporté pour prévenir les collisions. Cette technique
doit être utilisée dans la spécification d’un message lorsqu’il n’est pas possible d’assurer autrement l’identification
non ambiguë de chaque segment de message à sa réception.
© ISO 1998 – Tous droits réservés vii
---------------------- Page: 7 ----------------------
NORME INTERNATIONALE ISO 9735-1:1998(F)
Échange de données informatisé pour l'administration, le
commerce et le transport (EDIFACT) — Règles de syntaxe au
niveau de l'application (numéro de version de syntaxe: 4) —
Partie 1:
Règles de syntaxe communes à l’ensemble des parties,
accompagnées des répertoires de service syntaxiques associés à
chacune d’elles
1 Domaine d'application
La présente partie de l'ISO 9735 définit les règles de syntaxe spécifiques au formatage des messages par lots et
interactifs destinés aux échanges entre applications informatiques. Elle comprend les définitions et les répertoires
de service correspondant à chacune des parties de l'ISO 9735.
2 Conformité
La conformité à une norme signifie que la totalité de ses prescriptions, y compris tous ses aspects, sont pris en
compte. Si tel n’est pas le cas, toute demande de conformité doit comporter une déclaration identifiant chacun des
aspects qui en fait l'objet.
Les données échangées sont en conformité si la structure et la représentation des données respectent les règles
de syntaxe définies dans la présente Norme internationale.
Les dispositifs qui s'appuient sur la présente Norme internationale sont en conformité s'ils sont en mesure de créer
et/ou d'interpréter les données structurées et représentées conformément à cette norme.
La conformité doit être fondée sur la présente partie de l'ISO 9735, et au moins sur l’ISO 9735-2 ou l’ISO 9735-3.
Une fois identifiées dans la présente Norme internationale, les dispositions définies dans les normes associées
doivent faire partie intégrante des critères de conformité.
3 Références normatives
Les documents normatifs suivants contiennent des dispositions qui, par suite de la référence qui y est faite,
constituent des dispositions valables pour la présente partie de l'ISO 9735. Pour les références datées, les
amendements ultérieurs ou les révisions de ces publications ne s’appliquent pas. Toutefois, les parties prenantes
aux accords fondés sur la présente partie de l'ISO 9735 sont invitées à rechercher la possibilité d'appliquer les
éditions les plus récentes des documents normatifs indiqués ci-après. Pour les références non datées, la dernière
édition du document normatif en référence s’applique. Les membres de l'ISO et de la CEI possèdent le registre des
Normes internationales en vigueur.
ISO 639:1988, Code pour la représentation des noms de langue.
ISO/CEI 646:1991, Technologies de l'information — Jeu ISO de caractères codés à 7 éléments pour l'échange
d'informations.
© ISO 1998 – Tous droits réservés 1
---------------------- Page: 8 ----------------------
ISO 9735-1:1998(F)
ISO/CEI 2022:1994, Technologies de l'information — Structure de code de caractères et techniques d'extension.
ISO/CEI 2382-1:1993, Technologies de l'information — Vocabulaire — Partie 1: Termes fondamentaux.
ISO 2382-4:1987, Systèmes de traitement de l'information — Vocabulaire — Partie 04: Organisation des données.
ISO 6093:1984, Traitement de l’information — Représentation des valeurs numériques dans les chaînes de
caractères pour l’échange d’information.
ISO/CEI 6429:1992, Technologies de l'information — Fonctions de commande pour les jeux de caractères codés.
ISO 6523:1984, Échange de données — Structure pour l'identification des organisations.
ISO 8601:1988, Éléments de données et formats d'échange — Échange d'information — Représentation de la date
et de l'heure.
ISO 9735-2:1998, Échange de données informatisé pour l’administration, le commerce et le transport
(EDIFACT) — Règles de syntaxe au niveau de l’application (numéro de version de syntaxe: 4) — Partie 2: Règles
de syntaxe spécifiques à l’EDI par lots.
ISO 9735-3:1998, Échange de données informatisé pour l’administration, le commerce et le transport
(EDIFACT) — Règles de syntaxe au niveau de l’application (numéro de version de syntaxe: 4) — Partie 3: Règles
de syntaxe spécifiques à l’EDI interactif.
ISO/CEI 10646-1:1993, Technologies de l'information — Jeu universel de caractères codés à plusieurs octets —
Partie 1: Architecture et table multilingue.
4 Définitions
Pour les besoins de la présente Norme internationale, les définitions données dans l'annexe A s'appliquent.
5 Caractères de service
Les caractères de service sont le séparateur d'éléments de données constitutifs, le séparateur d'éléments de
données, le caractère suspensif, le séparateur de répétition et la fin de segment.
Le séparateur d'éléments de données constitutifs, le séparateur d'élément de données, le séparateur de répétition
et le caractère de fin de segment permettent de délimiter les différentes structures de syntaxe telles que définies
dans l'article 7.
Le caractère suspensif a pour objet de permettre l'utilisation d'un caractère qui serait autrement interprété comme
caractère de service. Le caractère qui suit immédiatement le caractère suspensif dans un échange ne doit pas être
interprété comme caractère de service.
Lorsqu'il est utilisé, le caractère suspensif n'est pas pris en compte dans la longueur de la valeur de l'élément de
données.
NOTE L'utilisation de caractères de service présentée ci-après, 10?+10=20, qui apparaît dans un transfert de données,
doit être interprétée à réception comme 10+10=20. Un point d'interrogation dans la valeur d'un élément de données est
représenté par ??.
2 © ISO 1998 – Tous droits réservés
---------------------- Page: 9 ----------------------
ISO 9735-1:1998(F)
5.1 Caractères de service par défaut
Les caractères de service par défaut dont l'utilisation est réservée à la présente Norme internationale sont les
suivants:
Représentation Fonctionnalité
Nom graphique
Deux points : Séparateur d'éléments de données constitutifs
Signe plus + Séparateur d'éléments de données
Point d'interrogation ? Caractère suspensif
*
Astérisque Séparateur de répétition
Apostrophe ' Fin de segment
5.2 Avis de chaîne de caractères de service UNA
L'avis conditionnel de chaîne de caractères de service (UNA) offre la possibilité d'indiquer les caractères de service
utilisés dans l'échange (voir annexe B). L'avis de chaîne de caractères de service UNA doit être utilisé si les
caractères de service diffèrent des caractères par défaut (voir 5.1). Son utilisation est facultative si les caractères
par défaut sont utilisés.
Lorsqu'il est utilisé, l'avis de chaîne de caractères de service doit apparaître immédiatement avant le segment
d'en-tête d'échange.
6 Répertoires des caractères
Le codage des caractères défini dans la table de base des codes de l'ISO/CEI 646 (Jeu ISO de caractères codés à
7 éléments pour l'échange d'informations) doit être utilisé pour l'avis de chaîne de caractères de service de
l’échange (s'il est employé) jusqu'à et y compris l'élément de données composite S001 «Identifiant de la syntaxe»
qui figure dans l'en-tête d'échange.
Le répertoire des caractères utilisé pour les caractères d'un échange doit être identifié à partir de la valeur de code
de l'élément de données, 0001 dans l’élément de données composite S0001 «Identifiant de la syntaxe» qui figure
dans l'en-tête d'échange (voir annexe D). Le répertoire des caractères identifié ne s’applique ni aux objets ni/ou
aux données chiffrées de sécurité.
La technique de codage par défaut d'un répertoire particulier doit être la technique de codage définie dans la
spécification associée du jeu de caractères.
SI la solution par défaut n'est pas utilisée, il convient d'avoir recours à une valeur de code de l'élément de données
0133 «Codage de caractères, en code» qui figure dans l'en-tête d'échange.
La technique d'extension de code (ISO/CEI 2022) ne peut être utilisée dans un échange qu'après l'élément de
données composite S0001 «Identifiant de la syntaxe» qui figure dans l'en-tête d'échange.
La technique d'extension de code et les caractères graphiques cibles ne doivent être utilisés que pour, par
exemple
� les éléments de données en langage clair (textuel) représentés sous forme alphabétique ou alphanumérique.
Cette technique ne doit pas être utilisée pour, par exemple
� toute étiquette de segment, ou
� tout caractère de service, ou
� tout élément de données représenté sous forme numérique.
© ISO 1998 – Tous droits réservés 3
---------------------- Page: 10 ----------------------
ISO 9735-1:1998(F)
Les caractères servant à indiquer une extension de code ne doivent pas être comptabilisés dans la longueur d'un
élément de données, ni être utilisés comme caractères de service.
Dans le calcul de la longueur d'un élément de données, un caractère graphique peut compter comme un caractère,
indépendamment du nombre de multiplets/octets nécessaires à son codage.
7 Structures de la syntaxe
Les définitions de cet article précisent les structures logiques de la syntaxe. Les règles applicables à leur utilisation
sont définies à l'article 8.
7.1 Structure d'un échange
Un échange doit débuter soit par un avis de chaîne de caractères de service, soit par un en-tête d'échange. Il doit
être identifié par un en-tête d'échange, se terminer par une fin d'échange et contenir au moins un groupe ou un
message ou un paquet. Il peut y avoir plus d'un groupe ou d'un message et/ou d'un paquet dans un échange,
chacun étant identifié par son propre en-tête et terminé par sa propre fin. Les messages contenus dans un
échange ou dans un groupe peuvent comporter un ou plusieurs types de messages.
Un échange ne doit contenir que
� des messages, ou
� des paquets, ou
� des messages et des paquets, ou
� des groupes et des paquets, ou
� des groupes contenant des messages, ou
� des groupes contenant des paquets, ou
� des groupes contenant des messages et des paquets.
7.2 Structure d’un groupe
Un groupe est une structure conditionnelle située entre l'en-tête et la fin d'échange et comprend un ou plusieurs
messages et/ou paquets.
Un groupe doit débuter et être identifié par un en-tête de groupe. Il doit se terminer par une fin de groupe et
contenir au moins un message ou un paquet.
7.3 Structure d’un message
Un message comprend un jeu ordonné de segments (voir annexe E). Les segments peuvent être regroupés. La
position de chaque segment, son statut et le nombre maximal d'occurrences doivent être indiqués dans la
spécification du message.
Un segment donné dans la spécification d'un message doit avoir un statut obligatoire ou conditionnel.
La spécification d’un message doit assurer l'identification non ambiguë de chaque segment du message à sa
réception. L'identification doit être possible en se fondant sur l'étiquette du segment (ou l’étiquette du segment plus
l’identification du groupe de segments à l’intérieur des segments UGH et UGT) et sa position dans le message
transféré. L'identification ne doit pas dépendre du statut d’un segment ni de son nombre maximal d'occurrences.
Un message doit débuter et être identifié par un en-tête de message, se terminer par une fin de message et
contenir au moins un segment supplémentaire.
4 © ISO 1998 – Tous droits réservés
---------------------- Page: 11 ----------------------
ISO 9735-1:1998(F)
7.4 Structure d’un groupe de segments
Un groupe de segments comprend un jeu ordonné de segments: un segment déclencheur et un autre segment ou
un autre groupe de segments. Le segment déclencheur doit être le premier segment du groupe de segments. Il
doit avoir un statut obligatoire et un nombre maximal d'occurrences égal à un. La position de chaque groupe de
segments, son statut et le nombre maximal d'occurrences dans la structure du message doivent être indiqués dans
la spécification du message.
Un groupe de segments peut contenir un ou plusieurs groupes de segments dépendants. Lorsqu'un groupe de
segments est contenu à l'intérieur d'un autre groupe de segments et lui est directement subordonné, le groupe
subordonné de segments est désigné sous le nom «d’enfant» et l'autre groupe de segments, sous le nom de
«parent».
Un groupe donné de segments dans une spécification de message doit avoir un statut obligatoire ou conditionnel.
7.5 Structure d’un segment
Un segment comprend un jeu ordonné d'éléments de données autonomes et/ou d'éléments de données
composites dont chacun peut être répété si cette possibilité est donnée dans la spécification du segment. La
position de chaque élément de données autonome ou composite, son statut et le nombre maximal d'occurrences
dans la structure du segment doivent être indiqués dans la spécification du segment. Un segment doit débuter et
être identifié par une étiquette de segment faisant référence à la spécification particulière de segment. Un segment
doit contenir au moins un élément de données en plus de l'étiquette du segment.
Un élément de données déterminé dans une spécification de segment doit avoir un statut obligatoire ou
conditionnel.
7.6 Structure d'une étiquette de segment
Une étiquette de segment est un élément de données simple.
Les étiquettes de segments commençant par la lettre U (par exemple UNB, UIH) doivent être réservées aux
segments de service.
7.7 Structure d'un élément de données composite
Un élément de données composite comprend un jeu ordonné de deux ou plusieurs éléments de données
constitutifs. La position et le statut de chaque élément de données constitutif dans la structure de l'élément de
données composite doivent être indiqués dans la spécification de l'élément de données composite.
Un élément de données constitutif déterminé qui figure dans la spécification d'un élément de données composite
doit avoir un statut obligatoire ou conditionnel.
7.8 Structure d'un élément de données simple
Un élément de données simple contient une seule valeur d'élément de données.
Un élément de données simple est utilisé soit comme élément de données autonome soit comme élément de
données constitutif. Un élément de données autonome figure dans un segment à l'extérieur d'un élément de
données composite. Un élément de données constitutif figure dans un élément de données composite.
La représentation de la valeur de chaque élément de données simple doit être indiquée dans la spécification de cet
élément de données.
© ISO 1998 – Tous droits réservés 5
---------------------- Page: 12 ----------------------
ISO 9735-1:1998(F)
7.9 Structure d’un paquet
Un paquet doit débuter et être identifié par un en-tête d'objet. Il doit se terminer par une fin d'objet et contenir un
objet.
8 Inclusion et exclusion
Les règles de cet article doivent s'appliquer lorsqu'un message est établi pour son transfert. D'après ces règles,
dans certains cas, les groupes de segments, segments, éléments de données et caractères dans une valeur
d'élément de données, doivent être présents, alors que, dans d’autres cas, ils doivent être omis.
8.1 Détermination de présence
Un élément de données simple est considéré présent si sa valeur d'élément de données contient au moins un
caractère.
Un élément de données composite est considéré présent si au moins l'un de ces éléments de données constitutif
est présent.
Un segment est considéré présent si son étiquette est présente.
Un groupe de segments est considéré présent si son segment déclencheur est présent.
8.2 Inclusion de groupes de segments
Un groupe de segments obligatoire qui n'est pa
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.