-- Module Prenegotiation-Operations-and-Errors (Q.2984:12/1999) Prenegotiation-Operations-and-Errors {itu-t recommendation q 2984 prenegotiation-operations-and-errors(1)} DEFINITIONS AUTOMATIC TAGS ::= BEGIN EXPORTS preNegotiate, PrenegotiationProposal, prenegotiationAlert; IMPORTS OPERATION, ERROR FROM Remote-Operations-Information-Objects {joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} CallSegmentId FROM CC-Operations {itu-t recommendation q 2981 cc-operations(1)} BearerId FROM Call-Object-Class-Definitions {itu-t recommendation q 2981 call-object-class-definitions(5)}; PrenegotiationOperations OPERATION ::= {preNegotiate | prenegotiationAlert} preNegotiationOperationsDefinitions OBJECT IDENTIFIER ::= {itu-t recommendation q 2984 prenegotiation-operations-definitions(2)} preNegotiate OPERATION ::= { ARGUMENT SEQUENCE {prenegotiationProposal PrenegotiationProposal, callAssociation CHOICE {callSegmentId CallSegmentId, callId CallIdValue}} RESULT SEQUENCE {prenegotiationProposal PrenegotiationProposal, callAssociation CHOICE {callSegmentId CallSegmentId, callId CallIdValue}} RETURN RESULT TRUE ERRORS {prenegotiateErrorSimple | prenegotiateErrorItemized} SYNCHRONOUS FALSE ALWAYS RESPONDS TRUE CODE global:{preNegotiationOperationsDefinitions 1} } CallIdValue ::= OCTET STRING(SIZE (1..3)) PrenegotiationProposal ::= SEQUENCE OF ConnectionProposal ConnectionProposal ::= SEQUENCE { connectionSubject ConnectionSubject, connectionReference ConnectionNumber, connectionCallRelation UserMandatory DEFAULT FALSE, bearerId BearerId OPTIONAL } ConnectionSubject ::= CHOICE { connectionProposal Proposal, connectionAccept Accept } ConnectionNumber ::= INTEGER(1..127) UserMandatory ::= BOOLEAN Accept ::= SEQUENCE {accept BOOLEAN, alternativeNo INTEGER OPTIONAL } -- TRUE if proposal is accepted and therefore no counterproposal necessary -- FALSE if proposal is rejected and no counterproposal is possible for UserOptional Connection -- alternativeNo specifies the accepted alternative Proposal ::= SEQUENCE { bearerEstDirection BearerEstDirection, mostPreferredProposal MostPreferredProposal, alternatives SEQUENCE OF Alternative OPTIONAL } BearerEstDirection ::= ENUMERATED { noSpecificRequirements(0), exclusiveByPrenegInvokingEntity(1), exclusiveByPrenegRemoteEntity(2), preferablyByPrenegRemoteEntity(3) } Alternative ::= SEQUENCE { alternativeProposal SEQUENCE OF ProposedItem, alternativeNo INTEGER(1..127) } -- alternativeNo reflects the priority of the alternatives MostPreferredProposal ::= SEQUENCE OF ProposedItem -- specifies one connection with minimum proposal ProposedItem ::= SEQUENCE { item InformationElement, modificationPossible BOOLEAN OPTIONAL } InformationElement ::= OCTET STRING(SIZE (4..4095)) -- embedded DSS2 Information Elements -- information elements are listed in 9.2.1.3 -- maximum value depends on information element preNegotiationOperationsErrors OBJECT IDENTIFIER ::= {itu-t recommendation q 2984 prenegotiation-operations-errors(3)} prenegotiateErrorSimple ERROR ::= { PARAMETER CHOICE {callSegmentId CallSegmentId, callId CallIdValue} CODE global:{preNegotiationOperationsErrors 1} } prenegotiateErrorItemized ERROR ::= { PARAMETER PrenegotiateErrorItemizedParam CODE global:{preNegotiationOperationsErrors 2} } PrenegotiateErrorItemizedParam ::= SEQUENCE { callAssociation CHOICE {callSegmentId CallSegmentId, callId CallIdValue}, listOfConnectionErrors SEQUENCE OF ConnectionError } ConnectionError ::= SEQUENCE { connectionSubject ENUMERATED {unspecified(0), compatibleAndCurrentlyUnavailable(1), incompatible(2), ... }, connectionReference ConnectionNumber } prenegotiationAlert OPERATION ::= { RETURN RESULT FALSE SYNCHRONOUS FALSE ALWAYS RESPONDS FALSE CODE global:{preNegotiationOperationsDefinitions 2} } END -- Prenegotiation-Operations-and-Errors -- Generated by Asnp, the ASN.1 pretty-printer of France Telecom R&D
Language:English
Score: 1028429.5
-
https://www.itu.int/wftp3/Publ...tion-Operations-and-Errors.asn
Data Source: un
Prenegotiation-Operations-and-Errors (Q.2984:12/1999)
-- Module Prenegotiation-Operations-and-Errors (Q.2984:12/1999) -- See also ITU-T Q.2984 (12/1999) -- See also the index of all ASN.1 assignments needed in this document
Prenegotiation-Operations-and-Errors {itu-t recommendation q 2984 prenegotiation-operations-and-errors(1)} DEFINITIONS
AUTOMATIC TAGS ::= BEGIN
EXPORTS preNegotiate, PrenegotiationProposal, prenegotiationAlert; IMPORTS OPERATION, ERROR FROM Remote-Operations-Information-Objects {joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} CallSegmentId FROM CC-Operations {itu-t recommendation q 2981 cc-operations(1)} BearerId FROM Call-Object-Class-Definitions {itu-t recommendation q 2981 call-object-class-definitions(5)}; PrenegotiationOperations OPERATION ::= { preNegotiate
|
prenegotiationAlert } preNegotiationOperationsDefinitions OBJECT IDENTIFIER ::= {itu-t recommendation q 2984 prenegotiation-operations-definitions(2)} preNegotiate OPERATION ::= { ARGUMENT SEQUENCE {prenegotiationProposal PrenegotiationProposal , callAssociation CHOICE {callSegmentId CallSegmentId , callId CallIdValue }} RESULT SEQUENCE {prenegotiationProposal PrenegotiationProposal , callAssociation CHOICE {callSegmentId CallSegmentId , callId CallIdValue }} RETURN RESULT TRUE ERRORS { prenegotiateErrorSimple
|
prenegotiateErrorItemized } SYNCHRONOUS FALSE ALWAYS RESPONDS TRUE CODE global:{ preNegotiationOperationsDefinitions 1} } CallIdValue ::= OCTET STRING ( SIZE
(1..3) )
PrenegotiationProposal ::= SEQUENCE
OF
ConnectionProposal
ConnectionProposal ::= SEQUENCE { connectionSubject ConnectionSubject , connectionReference ConnectionNumber , connectionCallRelation UserMandatory
DEFAULT
FALSE , bearerId BearerId
OPTIONAL } ConnectionSubject ::= CHOICE { connectionProposal Proposal , connectionAccept Accept } ConnectionNumber ::= INTEGER (1..127)
UserMandatory ::= BOOLEAN
Accept ::= SEQUENCE {accept BOOLEAN , alternativeNo INTEGER
OPTIONAL } -- TRUE if proposal is accepted and therefore no counterproposal necessary -- FALSE if proposal is rejected and no counterproposal is possible for UserOptional Connection -- alternativeNo specifies the accepted alternative Proposal ::= SEQUENCE { bearerEstDirection BearerEstDirection , mostPreferredProposal MostPreferredProposal , alternatives SEQUENCE
OF
Alternative
OPTIONAL } BearerEstDirection ::= ENUMERATED { noSpecificRequirements(0), exclusiveByPrenegInvokingEntity(1), exclusiveByPrenegRemoteEntity(2), preferablyByPrenegRemoteEntity(3) } Alternative ::= SEQUENCE { alternativeProposal SEQUENCE
OF
ProposedItem , alternativeNo INTEGER (1..127) } -- alternativeNo reflects the priority of the alternatives MostPreferredProposal ::= SEQUENCE
OF
ProposedItem
-- specifies one connection with minimum proposal ProposedItem ::= SEQUENCE { item InformationElement , modificationPossible BOOLEAN
OPTIONAL } InformationElement ::= OCTET STRING ( SIZE
(4..4095) ) -- embedded DSS2 Information Elements
-- information elements are listed in 9.2.1.3 -- maximum value depends on information element preNegotiationOperationsErrors OBJECT IDENTIFIER ::= {itu-t recommendation q 2984 prenegotiation-operations-errors(3)} prenegotiateErrorSimple ERROR ::= { PARAMETER CHOICE {callSegmentId CallSegmentId , callId CallIdValue } CODE global:{ preNegotiationOperationsErrors 1} } prenegotiateErrorItemized ERROR ::= { PARAMETER PrenegotiateErrorItemizedParam CODE global:{ preNegotiationOperationsErrors 2} } PrenegotiateErrorItemizedParam ::= SEQUENCE { callAssociation CHOICE {callSegmentId CallSegmentId , callId CallIdValue }, listOfConnectionErrors SEQUENCE
OF
ConnectionError } ConnectionError ::= SEQUENCE { connectionSubject ENUMERATED {unspecified(0), compatibleAndCurrentlyUnavailable(1), incompatible(2), ... }, connectionReference ConnectionNumber } prenegotiationAlert OPERATION ::= { RETURN RESULT FALSE SYNCHRONOUS FALSE ALWAYS RESPONDS FALSE CODE global:{ preNegotiationOperationsDefinitions 2} } END -- Prenegotiation-Operations-and-Errors
-- Generated by Asnp, the ASN.1 pretty-printer of France Telecom R&D
Language:English
Score: 1022851.6
-
https://www.itu.int/wftp3/Publ...ion-Operations-and-Errors.html
Data Source: un
ITU
INTERNATIONAL TELECOMMUNICATION UNION Document: WG-Terminology-2/5 Date: 22 September 2008
COUNCIL WORKING GROUP ON TERMINOLOGY: USE IN THE CONSTITUTION AND CONVENTION
English only
2nd Meeting, Geneva — 23-24 September 2008
Working Group on Terminology: Use in the Constitution and Convention
Contribution from the Syrian Arab Republic on possible modifications to Resolution 67 (Kyoto, 1994)
Updating of definitions
Syria believes that the Council Working Group on Resolution 142 (Antalya, 2006) need to address the content of the Resolution in order to propose a revised version, on the assumption that the work of the Group should continue in the future taking into consideration the need to agree on modify definitions in the six languages as a result of the activities (based on the results of the work on Resolution 154 (Antalya, 2006) as well as Resolution ITU-R 36-2, and a possible relevant Resolution by the WTSA-08 on the same subject.
2
RESOLUTION 67 (Kyoto, 1994)
Updating of definitions
The Plenipotentiary Conference of the International Telecommunication Union (Kyoto, 1994),
considering
a) that the Annexes to the Constitution and to the Convention of the International Telecommunication Union (Geneva, 1992) contain definitions of certain terms used in the Constitution, in the Convention and in the Administrative Regulations;
b) that, as a result of technical progress and the development of operating methods, it might be desirable to revise some of these definitions,
instructs the Secretary-General
to submit to the Council any changes accepted by a conference to definitions which are in the Annexes to the Constitution and Convention (Geneva, 1992), for subsequent transmission to the Plenipotentiary Conference for any action the latter may deem appropriate.
3
RESOLUTION 67 (Kyoto, 1994)Antalya, 2006)
Updating of terms and definitions
The Plenipotentiary Conference of the International Telecommunication Union (Kyoto, 1994)Antalya, 2006),
considering
a) that the Annexes to the Constitution and to the Convention of the International Telecommunication Union (Geneva, 1992) contain definitions of certain terms used in the Constitution, in the Convention and in the Administrative Regulations;
b) that, as a result of technical progress and the development of operating methods, it might be desirable to add new terms with relevant definitions or revise some of these definitions,;
c) the urgent need for unifying all terms and definitions in the six languages to be used by the three Sectors and the General Secretariat;
d) the need to carry the maintenance, expansion and updating of these terms and definitions,
instructs the Secretary-General
1 to submit to the Council any changes accepted by a conference to definitions which are in the Annexes to the Constitution and Convention (Geneva, 1992), for subsequent transmission to the Plenipotentiary Conference for any action the latter may deem appropriate.;
2 to submit to the council a proposal to create a unit for the maintenance expansion and updating of the unified centralized database for terms and definitions in the six languages with proper proposal for staffing.
instructs the council
1 to study the proposal of the Secretary General and to create this unit as part of the General Secretariat to be activated as soon as possible.
2 to report to the next plenipotentiary conference on the implementation of this Resolution.
ITU
Contribution from the Syrian Arab Republic on possible modifications to Resolution 67 (Kyoto, 1994)
Updating of definitions
RESOLUTION 67 (Kyoto, 1994)
Updating of definitions
Updating of terms and definitions
Language:English
Score: 1018793.75
-
https://www.itu.int/council/gr...Mod-to-Res%2067_Kyoto-1994.pdf
Data Source: un
Preliminary Functional System Definition
Justify and Document
Functional System Definition (Scope, Functions, Interfaces etc.)
(...) The expert judgement should take into account that the contribution of all the broadly acceptable risks does not exceed a defined proportion of the overall risk.
6.2.4 It is expected that the type of hazards classified as broadly acceptable are those that could be considered as catastrophic hazards such as a meteor strike, tsunami etc. but that are sufficiently unlikely to occur such that they constitute a broadly acceptable risk.
6.2.5 During the hazard identification, safety measures may be identified. (...) Annex I
Preliminary Functional System Definition
Safety significant
change
Yes
No Justify and Document
Broadly Acceptable
Risk
Yes
H A
Z A
R D
I D
E N
TI FI
C A
TI O
N A
N D
C
LA SS
IF IC
A TI
O N Hazard Identification
(What can happen?
Language:English
Score: 1014491.9
-
https://www.icao.int/NACC/Docu...fetyMethodOnRiskEvaluation.pdf
Data Source: un
Tables 1-4 and 1-5 (Content of training course), Part 7;1.1.2 (Acceptance procedures) and Part 7;4.5 which states ‘An operator must report any occasion when undeclared or misdeclared dangerous goods are discovered in cargo or mail…’. (...) ACTION BY THE DGP-WG
2.1 The DGP-WG is invited to add the following definitions to Part 1; 3.1:
. . .
Undeclared dangerous goods. (...) Dangerous goods offered for transport by air where:
a) they are incorrectly described on the dangerous goods transport document, such that had they been correctly
described, they would not be have been acceptable for carriage; or
b) they are found, after the acceptance check required by 7;1.3, not to have complied with the Technical Instructions.
Language:English
Score: 1001136.9
-
https://www.icao.int/safety/Da...011/DGPWG.2011.WP.053.2.en.pdf
Data Source: un
Green (desirable): NFI is above zero for past 3 consecutive years
⃝
5a
Permanent crops (more than one year or country definition) under greenhouses or high shelters
6
.
0
0
h
a
Yellow (acceptable): NFI is above zero for at least 1 of the past 3 consecutive years
⃝
5b
Permanent crops (more than one year or country definition) outdoors or under low shelters
.
(...) Reference year:
Last calendar year
Table 4.3
(Read all options and fill in all that apply)
HID
Soil erosion
Reduction in soil fertility
Waterlogging
Salinization
Other
Agricultural area
Agricultural area affected
Area affected
Sustainability status
Area of the holding
Unit of measure
1
No
Yes
Yes
No
No
9
5
55.56%
Non-sustainable
⃝
1a
Temporary crops (less than one year or country definition) under greenhouses or high shelters
.
.
.
.
2
No
No
No
No
No
15
0
0.00%
Desirable
⃝
1b
Temporary crops (less than one year or country definition) outdoors or under low shelters
.
.
.
.
.
3
Yes
Yes
No
No
No
20
1.9
9.50%
Desirable
⃝
2
Temporary fallow
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
No
Yes
Yes
No
No
14
3.5
25.00%
Acceptable
⃝
3
Temporary meadows and pastures
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
.
0
0
h
a
5
Yes
Yes
No
No
Yes
2
0.1
5.00%
Desirable
⃝
4
Kitchen gardens and backyards
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
Yes
No
Yes
No
No
17
0.5
2.94%
Desirable
⃝
5a
Permanent crops (more than one year or country definition) under greenhouses or high shelters
.
.
.
6
.
0
0
h
a
7
No
No
Yes
Yes
No
3
3
100.00%
Non-sustainable
⃝
5b
Permanent crops (more than one year or country definition) outdoors or under low shelters
.
.
.
.
8
No
No
Yes
No
No
23
3
13.04%
Acceptable
⃝
6
Permanent meadows and pastures
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
Yes
No
No
Yes
Yes
8
1
12.50%
Acceptable
Total agricultural area of the holding
9
.
0
0
h
a
10
Yes
Yes
No
Yes
No
2
0.1
5.00%
Desirable
Step 4 - Sum the agriculture areas according to the sustainability status and divide it by the total agriculture land area
Table 4.4
Sustainability status
Agriculture area in Ha
Proportion of agriculture area
Desirable
56
50%
Acceptable
45
40%
Unsustainable
12
11%
Total
113
100%
5. (...) Table 6.4
Total agricultural area of the holding
9
.
0
0
h
a
HID
Agriculture area in Ha
Sustainability Status
1
9
Acceptable
2
15
Non-sustainable
3
20
Acceptable
4
14
Desirable
5
2
Non-sustainable
6
17
Desirable
7
3
Acceptable
8
23
Acceptable
9
8
Desirable
10
2
Desirable
Step 5 - Sum the agriculture areas according to the sustainability status and divide it by the total agriculture land area
Table 6.5
Sustainability status
Agriculture area in Ha
Proportion of agriculture area
Desirable
41
36%
Acceptable
55
49%
Unsustainable
17
15%
Total
113
100%
7.
Language:English
Score: 999567.8
-
https://www.fao.org/fileadmin/...culation_11Sub-indicators.xlsx
Data Source: un
INTRODUCTION
1.1 Since there is no universally accepted definition for an eVisa or an electronic travel authorization, this paper proposes introducing the term “Electronic Travel System” (ETS) to describe and
define the automated process for authorizing and verifying a passenger’s acceptance for travel to a
country, in lieu of the processes involved in standard counterfoil paper visas.
1.2 The purpose of implementing an ETS is to expedite the pre-vetting and acceptance of low risk passengers into a country, while providing a secure method for applicants, governments, and airlines
to verify the acceptance for travel. (...) RECOMMENDATIONS
3.1 The Facilitation Panel is invited to agree with the introduction of:
a) a definition in Chapter 1,
b) a subsection “Electronic Travel Systems” in the newly introduced Chapter 9 containing six new Recommended Practices.
— — — — — — — —
FALP/9-WP/12
- 4 -
APPENDIX
Amend Annex 9 as follows:
Chapter 1: Definitions and general principles
A. Definitions
Electronic Travel Systems (ETS). The automated process for the lodgement, acceptance and verification
of a passenger’s authorization to travel to a State, in lieu of the standard counterfoil paper visa.
Language:English
Score: 988478.7
-
https://www.icao.int/Meetings/...tronic-Travel-Systems_IATA.pdf
Data Source: un
However, with no internationally accepted definition for a Visa, the term has failed to gain wider international recognition.
1.3 Recognizing there is no universally-accepted definition or guidance for States who wish to implement either an electronic visa (eVISA), electronic travel authority (ETA), or pre-approval for visa issuance on arrival system, a working group within IATA/CAWG was created. (...) The working group found that there were some common practices in the area of pre-vetting, acceptance and verification to determine a traveller’s acceptance for travel to a State. However, since there is no universally accepted definition for an eVisa or an ETA, the working group began drafting an information paper to introduce a generic term “Electronic Travel System” (ETS) to best describe these programs and make the recommendation that an ETS be considered an automated process for the lodgement, acceptance and verification of an individual’s authorization to travel to a country.
1.5 The working group also reviewed Australia’s implementation of an ETA in 1996, and considered the Australian ETA to be a model of how countries can introduce and integrate all of the elements for an ETS.
1.6 The discussion points below highlight elements from the IATA CAWG information paper.
2.
Language:English
Score: 988142.3
-
https://www.icao.int/Meetings/...4IATA%20CAWG%20ETS%20FALP8.pdf
Data Source: un
INADMISSIBLE PERSONS
Relevant definitions ----------------------- 1. Notification of inadmissibility 2. (...) INADMISSIBLE PERSONS
Relevant definitions 1. Notification of inadmissibility 2. Consultation on removal 3. (...) INADMISSIBLE PERSONS
6. Obligation to accept for examination
● 5.12 A Contracting State shall accept for examination a person removed from a State where he was found inadmissible, if this person commenced his journey from its territory.
Language:English
Score: 987306.6
-
https://www.icao.int/MID/Docum...admissiblePersonsDeportees.pdf
Data Source: un
-- Module UsageMeteringDataInfo (X.742:04/1995) UsageMeteringDataInfo {joint-iso-itu-t ms(9) function(2) part10(10) asn1Modules(2) 2} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS UsageInfo; IMPORTS DMI-TYPE-IDENTIFIER FROM Attribute-ASN1Module {joint-iso-itu-t ms(9) smi(3) part2(2) asn1Module(2) 1}; UMF-USAGE ::= DMI-TYPE-IDENTIFIER UsageInfo ::= SEQUENCE { serviceType UMF-USAGE. (...) If an XxxRequestType is specified in a -- specialization, zero or more request components may appear in a value of the XxxUsageData. -- -- The definition of the service-specific syntax to be included in this block, shall include the -- following information: -- service request information which identifies the type of service requested and also any -- additional service parameters, note that this information can be very detailed and complex -- depending on the service type and the types of request that the service supports (e.g. -- destination addresses, electronic mail message information, directory numbers, feature -- codes). -- and the following information may be provided: -- a usage measurement (time, volume); -- a time stamp (date and time). -- accept XxxAcceptType, -- The accept block identifies the details of what service was provided and the associated usage. -- The XxxAcceptType may be omitted from specializations not requiring it. If an XxxAcceptType -- is specified in a specialization, zero or more accept components may appear in a value of the -- XxxUsageData. -- -- The definition of the service-specific syntax to be included in this block, shall include the -- following information: -- service information which identifies the type of service provided and also any additional service -- parameters; -- a usage measurement; -- a time stamp. -- complete XxxCompleteType, -- The complete block identifies the details of the end of some instance of utilization.
Language:English
Score: 986584.6
-
https://www.itu.int/wftp3/Publ...1995/UsageMeteringDataInfo.asn
Data Source: un
