SIST ISO 10161-2:2017

INTERNATIONAL ISO
STANDARD 10161-2
Second edition
2014-10-15
Information and documentation —
Open Systems Interconnection —
Interlibrary Loan Application Protocol
Specification —
Part 2:
Protocol implementation conformance
statement (PICS) proforma
Information et documentation — Interconnexion de systèmes ouverts
(OSI) — Spécification du protocole d’application pour les prêts entre
bibliothèques —
Partie 2: Proforma d’établissement de conformité pour la mise en
oeuvre du protocole (PICS)
Reference number
ISO 10161-2:2014(E)
©
ISO 2014

---------------------- Page: 1 ----------------------
ISO 10161-2:2014(E)

COPYRIGHT PROTECTED DOCUMENT
© ISO 2014
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2014 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 10161-2:2014(E)

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3  Terms and definitions . 1
4 Abbreviations. 2
5 Layout . 2
6 Conformance . 2
7  Notations defined in the proforma . 2
7.1 General . 2
7.2 “D” Column . 2
7.3 “I” Column . 3
7.4 “Reference, usage or range of values” column . 3
8 PICS Numbers. 3
9  Completion of the PICS . 3
Annex A (normative) Protocol Implementation Conformance Statement (PICS) proforma for the
Interlibrary Loan Protocol . 4
Bibliography .34
© ISO 2014 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 10161-2:2014(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.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical Barriers
to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 46, Information and documentation, Subcommittee
SC 4, Technical interoperability.
This second edition cancels and replaces the first edition (ISO 10161-2:1997) of which it constitutes a
minor revision.
ISO 10161 consists of the following parts, under the general title Information and documentation — Open
Systems Interconnection — Interlibrary Loan Application Protocol Specification:
— Part 1: Protocol specification
— Part 2: Protocol implementation conformance statement (PICS) proforma
iv © ISO 2014 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 10161-2:2014(E)

Introduction
To evaluate conformance of a particular implementation of an OSI protocol, it is necessary to have a
description of the capabilities and options which have been implemented. Such a description is called a
Protocol Implementation Conformance Statement (PICS).
A PICS proforma is developed as a companion standard to an OSI protocol standard. It is developed in the
form of a questionnaire to be filled out by a supplier of a product claiming to implement the protocol. The
filled-out questionnaire becomes the PICS for the product. It indicates which capabilities and options
have been implemented and what limitations might prevent interworking. It allows a customer of the
product to evaluate its conformance to the standard and to determine whether the product meets the
customer’s requirements.
This part of ISO 10161 defines a protocol implementation conformance statement (PICS) proforma for
the detailed expression of the conformance requirements of ISO 10161-1 which incorporates Defect
Reports 1-22 and Amendment 1: ILL Support for Electronic Document Delivery. Detail of the use of this
proforma is provided in this part of ISO 10161.
The level of detail required in the proforma exceeds that of the protocol specification by requiring
details of the implementer in addition to details of the implementation.
© ISO 2014 – All rights reserved v

---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 10161-2:2014(E)
Information and documentation — Open Systems
Interconnection — Interlibrary Loan Application Protocol
Specification —
Part 2:
Protocol implementation conformance statement (PICS)
proforma
1 Scope
This part of ISO 10161 defines the protocol implementation conformance statement (PICS) proforma
for the ILL protocol as specified in ISO 10161-1, in compliance with the relevant requirements, and in
accordance with the relevant guidance for a PICS proforma, given in ISO/IEC 9646-2.
Implementers claiming conformance to ISO 10161-1 complete the proforma as part of the conformance
requirements.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 9646-1, Information technology — Open Systems Interconnection — Conformance testing
1)
methodology and framework — Part 1: General concepts
ISO 10161-1:2014, Information and documentation — Open Systems Interconnection — Interlibrary Loan
Application Protocol Specification — Part 1: Protocol specification
3  Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 9646-1 and the following
apply.
3.1
PICS proforma
document, in the form of a questionnaire, designed by the protocol specifier or conformance test suite
specifier, which when completed for an OSI implementation or system becomes the PICS
3.2
protocol implementation conformance statement
PICS
statement made by the supplier of an OSI implementation or system stating which capabilities have been
implemented for a given OSI protocol
1) ISO/IEC 9646-1:1994 supersedes ISO/IEC 9646-1:1991. However, when this part of ISO 10161 was under
development, the previous edition was valid and this part of ISO 10161 is therefore based on that edition.
© ISO 2014 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO 10161-2:2014(E)

4 Abbreviations
This part of ISO 10161 uses the following abbreviations.
APDU Application Protocol Data Unit ASN.1 — Abstract Syntax Notation One EDIFACT — Elec-
tronic Data Interchange for Administration, Commerce and Transport
ILL Interlibrary Loan
OSI Open Systems Interconnection
PICS Protocol Implementation Conformance Statement
5 Layout
Annex A contains the actual proforma to be filled in by an implementer claiming conformance to
ISO 10161-1. The PICS proforma has been designed to be a self-contained section of this part of ISO 10161,
for use in testing and procurement.
6 Conformance
A conforming PICS shall:
a) be technically equivalent to the ISO published PICS proforma and shall preserve the numbering and
ordering of the items in the ISO PICS proforma;
b) include the information necessary to uniquely identify both the supplier and the implementation.
A supplier shall complete this PICS proforma in accordance with the instructions for completion given
in Clauses 7 and 9.
7  Notations defined in the proforma
7.1 General
In order to reduce the size of the tables in the proforma, a number of abbreviations have been introduced.
The definition of each of these follows:
For column headings:
“D”:  Defined in ISO 10161. This column indicates the level of support required for conformance to
ISO 10161.
“I”:    Implementation indicator. This column shows which parameters or other details have or have not
been implemented.
7.2 “D” Column
“m”:   mandatory: support for this feature is required for conformance to ISO 10161.
“o”:   optional: support for this feature is permitted, but is not required for conformance to ISO 10161.
However, if this feature is implemented, it must conform to the specifications and restrictions contained
in ISO 10161. These restrictions may affect the optionality of other features.
“c”:   conditional: support for this feature is mandatory if certain conditions as specified in ISO 10161-1
are met. The conditions to be met are indicated by an integer referencing a table of conditions at the end
of each proforma section.
2 © ISO 2014 – All rights reserved

---------------------- Page: 7 ----------------------
ISO 10161-2:2014(E)

“cc”:  conditional on supporting communication service: support for this feature is mandatory if the
supporting communication service is store-and-forward service; support is optional if the supporting
communication service is connection oriented.
“-”:    not applicable.
7.3 “I” Column
The “I” column shall be completed by the supplier or implementer to indicate the level of implementation
of each feature. The proforma has been designed such that the only entries required in the “I” column
are:
“Y”:   Yes, the feature has been implemented
“N”:   No. the feature has not been implemented
“-”:    Not applicable to this implementation
7.4 “Reference, usage or range of values” column
The “Reference, usage or range of values” column requires the specification of information pertaining to
the usage or range of values implemented for a feature, where relevant and/or where the implementation
has restrictions or limits not present in ISO 10161-1.
If the proforma has insufficient room for a complete description of the usage or range of values for any
particular feature, a reference to an attachment on a separate page may be given here.
8 PICS Numbers
Each line in the PICS proforma which requires implementation detail to be supplied is numbered at the
left-hand edge of the line. This numbering is included as a means of uniquely identifying all possible
implementation details within the proforma. The need for such unique referencing has been identified
by testing bodies.
The means of referencing individual responses shall be to specify the smallest subclause enclosing the
relevant item and the reference number of the row in which the response appears.
9  Completion of the PICS
The implementer shall complete all “[ ]” entries in the proforma, in addition to other specifically
identified sections. In certain clauses further guidance for completion is included. Such guidance
supplements the guidance given in this clause and its scope is restricted to the clause in which it appears.
Other specifically identified information shall be provided by the implementer where requested.
No changes shall be made to the proforma except the addition of responses as required. Recognizing
that the level of detail required may, in some instances, exceed the space available for responses, the
implementer may continue the response on separate paper (so indicating in the space provided) and
provide a reference (see Clause 8).
© ISO 2014 – All rights reserved 3

---------------------- Page: 8 ----------------------
ISO 10161-2:2014(E)

Annex A
(normative)

Protocol Implementation Conformance Statement (PICS) proforma
2)
for the Interlibrary Loan Protocol
Section One — General information
A.1 Implementation details
A.1.1 Date of statement
1 Date of Statement (YYYY-MM-DD):
A.1.2  Identification of the implementation
1 Implementation Supplier:
2 Implementation Name:
3 Implementation Version Number:
4 Machine Name:
5 Machine Version Number:
6 Operating System Name:
7 Operating System Version Number:
8 Other Operating Systems:
9 Other Hardware:
10 System Name (if different):
11 Resources Required:
12 Contact Name:
13 Contact Address:
14 Contact Telephone:
A.2 Global statement of conformance
1 Are all mandatory features of ISO 10161-1 implemented? [ ]
Copyright release for PICS proforma: Users of this part of ISO 10161 may freely reproduce this PICS proforma so that it can be used for its
2)
intended purpose and may further publish the completed PICS.
4 © ISO 2014 – All rights reserved

---------------------- Page: 9 ----------------------
ISO 10161-2:2014(E)

Section Two — General details
A.3 ISO 10161 details
1 Protocol Version Number(s) that this PICS
describes:
2 Other Version Number(s) supported:
3 Defect Report Number(s) implemented:
4 Amendment(s) implemented:
A.4 Application-context names
List the names and object identifiers of the application-contexts recognized or provided by this
implementation.
Ref Application-Context Name Object Identifier
A.5 Roles supported
Ref D I
1 Requester o [ ]
2 Responder o [ ]
3 Intermediary o [ ]
NOTE At least one role must be supported by an implementation.
A.6 ILL Service types supported
Ref Service Type Requester Responder Intermediary
D I D I D I
1 Loan o [ ] o [ ] o [ ]
2 Copy/Non-returnable o [ ] o [ ] o [ ]
3 Locations o [ ] o [ ] o [ ]
4 Estimate o [ ] o [ ] o [ ]
5 Responder-specific o [ ] o [ ] o [ ]
A.7 Transaction types supported
Ref Transaction Type Requester Responder Intermediary
D I D I D I
1 Simple m [ ] m [ ] — [ ]
2 Chained o [ ] o [ ] o [ ]
3 Partitioned o [ ] o [ ] o [ ]
NOTE 1 For chained transactions, requester support implies the ability to permit chained transactions;
responder support implies the ability to send the SHIPPED message; intermediary support implies the ability to
initiate chained subtransactions.
© ISO 2014 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO 10161-2:2014(E)

NOTE 2 For partitioned transactions, requester support implies the ability to permit partitioned transactions
and to interact with different parties for the processing and tracking phases of a transaction; responder support
implies the ability to send the SHIPPED message and to interact directly with the requester during the tracking
phase of the transaction; intermediary support implies the ability to initiate partitioned sub-transactions.
NOTE 3 Implementation of the intermediary role implies support for at least one of the chained or partitioned
transaction types.
Section Three — Syntaxes
A.8 Syntaxes
This section identifies the requirements for support of the various possible syntaxes associated with the
ILL protocol. Support for a particular syntax implies that an implementation is capable of generation and
reception of information defined by that syntax.
A.8.1 Abstract syntaxes supported
Indicate below what abstract syntaxes are supported by the implementation. Registered syntaxes may
be identified by citing the assigned object identifier; other syntaxes should be fully defined using ASN.1
notation, if appropriate, in an attachment.
Ref Parameter D I Abstract-Syntax Name Object Identifier
1 ILL-APDU m [ ] ill-apdus 1 0 10161 2 1
2 responder-specific service o [ ]
3 national-bibliography-no o [ ]
4 system-no o [ ]
5 responder-specific-results o [ ]
(for reason-unfilled)
6 responder-specific-results o [ ]
(for reason-locs-provided)
7 responder-specific-results o [ ]
(for reason-not-available)
8 responder-specific-results o [ ]
(for conditions)
9 responder-specific-results o [ ]
(for reason-will-supply))
10 supplemental-item- descrip- o [ ]
tion
A.8.2 Transfer syntaxes
For each abstract syntax identified in A.8.1, multiple transfer syntaxes are possible. Two transfer
syntaxes for ILL APDUs have been identified in the base standard, one based on ASN.1 encoding rules
(ISO 8825, “basic-encoding”), and the other based on the EDIFACT syntax (ISO 9735).
For each abstract syntax name shown as supported in A.8.1, state below which transfer syntax(es) is/are
supported.
Ref Abstract Syntax Object Identifier Transfer Syntax Object Identifier D I
1.1 ill-apdus 1 0 10161 2 1 basic-encoding 2 1 1 m [ ]
1.2 ill-apdus 1 0 10161 2 1 EDIFACT-encoding 1 0 10161 3 1 o [ ]
6 © ISO 2014 – All rights reserved

---------------------- Page: 11 ----------------------
ISO 10161-2:2014(E)

Section Four — Interlibrary Loan Protocol
A.9 Interlibrary Loan application services
Except for optional APDUs, addressed in A.9.2, support for an ILL service implies support for sending
and/or receiving the corresponding APDUs as appropriate.
NOTE This section is cast in terms of services rather than APDUs because some mandatory services do not
necessarily result in the transfer of an APDU. For instance, it is mandatory for a responder to support the SHIPPED
service, but sending a Shipped APDU is optional. The protocol allows the most recent service and the current state
to be determined at any time by mean of the Status-Query and Status-Or-Error-Report APDUs.
A.9.1 Support for services
Ref Service Requester Responder Intermediary
D I D I D I
1 ILL-REQUEST m [ ] m [ ] m [ ]
2 FORWARD — — o [ ] o [ ]
3 FORWARD-NOTIFICATION c1 [ ] — — c1 [ ]
4 SHIPPED m [ ] m [ ] m [ ]
5 ILL-ANSWER m [ ] m [ ] m [ ]
6 CONDITIONAL-REPLY m [ ] c2 [ ] m [ ]
7 CANCEL o [ ] m [ ] m [ ]
8 CANCEL-REPLY c3 [ ] m [ ] m [ ]
9 RECEIVED m [ ] m [ ] m [ ]
10 RECALL c4 [ ] c4 [ ] c4 [ ]
11 RETURNED c4 [ ] c4 [ ] c4 [ ]
12 CHECKED-IN c4 [ ] c4 [ ] c4 [ ]
13 OVERDUE c4 [ ] c4 [ ] c4 [ ]
14 RENEW c5 [ ] c4 [ ] c4 [ ]
15 RENEW-ANSWER c6 [ ] c4 [ ] c4 [ ]
16 LOST m [ ] m [ ] m [ ]
17 DAMAGED o [ ] o [ ] m [ ]
18 MESSAGE o [ ] o [ ] m [ ]
19 STATUS-QUERY o [ ] o [ ] m [ ]
Conditions
c1 Support for the FORWARD-NOTIFICATION service is mandatory for requesters and intermediaries that support
permission-to-forward with the value “TRUE”; otherwise it is not applicable. See A.10.1 ref 21.1.
c2 Support for the CONDITIONAL-REPLY service is mandatory for responders that support transaction-results with the
value “CONDITIONAL”; otherwise it is not applicable.
c3 Support for the CANCEL-REPLY indication service is mandatory for requesters that support the CANCEL service;
otherwise it is not applicable.
c4 Support for the RECALL, RETURNED, CHECKED-IN, OVERDUE and RENEW-ANSWER services is mandatory for
implementations that support the “loan” service type; otherwise they are not applicable. See A.6.
c5 Support for the RENEW service is optional for requesters the support the “loan” service type; otherwise it is not
applicable. See A.6.
c6 Support for the RENEW-ANSWER service is mandatory for requesters that support the RENEW service; otherwise it is
not applicable.
© ISO 2014 – All rights reserved 7

---------------------- Page: 12 ----------------------
ISO 10161-2:2014(E)

Ref Service Requester Responder Intermediary
D I D I D I
20 STATUS-OR-ERROR- m [ ] m [ ] m [ ]
REPORT
21 EXPIRY o [ ] o [ ] m [ ]
Conditions
c1 Support for the FORWARD-NOTIFICATION service is mandatory for requesters and intermediaries that support
permission-to-forward with the value “TRUE”; otherwise it is not applicable. See A.10.1 ref 21.1.
c2 Support for the CONDITIONAL-REPLY service is mandatory for responders that support transaction-results with the
value “CONDITIONAL”; otherwise it is not applicable.
c3 Support for the CANCEL-REPLY indication service is mandatory for requesters that support the CANCEL service;
otherwise it is not applicable.
c4 Support for the RECALL, RETURNED, CHECKED-IN, OVERDUE and RENEW-ANSWER services is mandatory for
implementations that support the “loan” service type; otherwise they are not applicable. See A.6.
c5 Support for the RENEW service is optional for requesters the support the “loan” service type; otherwise it is not
applicable. See A.6.
c6 Support for the RENEW-ANSWER service is mandatory for requesters that support the RENEW service; otherwise it is
not applicable.
NOTE 1 Invocation of the FORWARD service by a responder results in the transmission to the new responder
of an ILL- Request APDU with the forward-flag set to true and the transmission of a Forward-Notification APDU
to the requester. The FORWARD-NOTIFICATION service is an indication service only and is only supported in the
requester role.
NOTE 2 The Shipped, Received, Returned and Checked-In APDUs are optional; they need not be sent even
though the corresponding services are invoked. See A.9.2.
A.9.2 Optional APDUs
This section requests information about the extent to which optional APDUs can be transmitted, and
about the extent to which the implementation requires the receipt of optional APDUs.
It is never an error to send an optional APDU; implementations must always be capable of receiving an
optional APDU. The issues are the extent to which an implementation is capable of sending them, and to
which an implementation requires the receipt of them.
8 © ISO 2014 – All rights reserved

---------------------- Page: 13 ----------------------
ISO 10161-2:2014(E)

A.9.2.1 Requester role
A.9.2.1.1 Capabilities on transmission
Indicate the value(s) transmitted for each of the parameters of the data type Requester-Optional-
Messages-Type.
Ref Parameter Value
1 can-send-RECEIVED TRUE/FALSE
2 can-send-RETURNED TRUE/FALSE
3 requester-SHIPPED
3.1 - requires [ ]
3.2 - desires [ ]
3.3 - neither [ ]
4 requester-CHECKED-IN
4.1 - requires [ ]
4.2 - desires [ ]
4.3 - neither [ ]
A.9.2.1.2 Requirements on receipt
Indicate the value(s) supported on receipt for each parameter of the data type Responder-Optional-
Messages-Type.
Ref Parameter Value
1 can-send-SHIPPED TRUE/FALSE
2 can-send-CHECKED-IN TRUE/FALSE
3 responder-RECEIVED
3.1 - requires [ ]
3.2 - desires [ ]
3.3 - neither [ ]
4 responder-RETURNED
4.1 - requires [ ]
4.2 - desires [ ]
4.3 - neither [ ]
© ISO 2014 – All rights reserved 9

---------------------- Page: 14 ----------------------
ISO 10161-2:2014(E)

A.9.2.2 Responder role
A.9.2.2.1 Capabilities on transmission
Indicate the value(s) transmitted for each of the parameters of the data type Responder-Optional-
Messages-Type.
Ref Parameter Value
1 can-send-SHIPPED TRUE/FALSE
2 can-send-CHECKED-IN TRUE/FALSE
3 responder-RECEIVED
3.1 - requires [ ]
3.2 - desires [ ]
3.3 - neither [ ]
4 responder-RETURNED
4.1 - requires [ ]
4.2 - desires [ ]
4.3 - neither [ ]
A.9.2.2.2 Requirements on receipt
Indicate the value(s) supported on receipt for each of the parameters of the data type Requester-
Optional-Messages- Type.
Ref Parameter Value
1 can-send-RECEIVED TRUE/FALSE
2 can-send-RETURNED TRUE/FALSE
3 requester-SHIPPED
3.1 - requires [ ]
3.2 - desires [ ]
3.3 - neither [ ]
4 requester-CHECKED-IN
4.1 - requires [ ]
4.2 - desires [ ]
4.3 - neither [ ]
A.10 Support for APDU parameters
The base standard, ISO 10161-1:2014, 10.1 g), requires that an implementation shall be capable of
receiving APDUs with data for all parameters. This section, therefore, deals with the requirements for
support of parameters in sent APDUs.
NOTE This does not imply that all parameters shall necessarily be acted upon, nor that the capabilities
implicit in different values of a parameter shall necessarily be implemented. For instance, all implementations,
receiving an ILL-Request APDU must be prepared to accept all values of the parameter permission-to-chain; this
does not imply that all implementations must support chaining. What local action is taken by an implementation
or a user in response to a value of a parameter, other than the maintenance of timers and variables as specified in
the protocol, is not addressed by ISO 10161-1.
Mandatory support for a parameter thus requires that an implementation shall always be capable
of sending data for that parameter and, that if the implementation has or can generate data for that
10 © ISO 2014 – All rights reserved

---------------------- Page: 15 ----------------------
ISO 10161-2:2014(E)

parameter then it shall always send it. For instance, the transaction-id parameter is mandatory in all
APDUs, and implementations shall always send data in this parameter; however, the client-id parameter
in the Shipped APDU is also mandatory, but data can only be sent in this parameter if a client-id was
provided in the original ILL-Request — if this data was provided, then the parameter must be sent.
Indicate in the tables below the degree of support or otherwise for the APDU parameters as defined
in Clause 9 of ISO 10161-1:2014. If the implementation supports different values (or has different
constraints) for different roles, this should be indicated.
A.10.1 ILL-Request-APDU
Ref Parameter D I Reference, usage or range of values
1 protocol-version-num m [ ]
2 transaction-id m [ ] see A.11 ref.1
3 service-date-time m [ ] see A.11 ref.2
4 requester-id cc [ ] see A.11 ref.3
5 responder-id cc [ ] see A.11 ref.4
6 transaction-type c1 [ ] see A.7
7 delivery-address o [ ]
7.1 - postal-address o [ ]
7.1.1 – name-of-person-or-institution o [ ] see A.12 ref.5
7.1.2 – extended-postal-delivery- o [ ]
address
7.1.3 – street-and-number o [ ]
7.1.4 – post-office box o [ ]
7.1.5 – city o [ ]
7.1.6 – region o [ ]
7.1.7 – country o [ ]
7.1.8 – postal-code o [ ]
7.2 - electronic-address o [ ]
7.2.1 – telecom-service-ide
...