---------------------------------------------------
Comparison CSTS-FW ASN1 definitions between:
  old version = 921x1r2[Draft_20150708]_ASN.1.ori.asn
  new version = SFW_ASN1_20160901.asn
---------------------------------------------------
for following PDUs:
- Association Control PDUs
- Buffered Data Delivery  PDUs
- Information Query PDUs


#1) Difference found in BindInvocation / serviceInstanceIdentifier
------------------------------------------------------------------
Old version of serviceInstanceIdentifier:
ServiceInstanceIdentifier	::=	SEQUENCE
{	spacecraftId			PublishedIdentifier
,	facilityId			PublishedIdentifier
,	serviceType			FunctionalResourceType
,	serviceInstanceNumber		FunctionalResourceInstanceNumber
}

New version of serviceInstanceIdentifier:
ServiceInstanceIdentifier	::=	SEQUENCE
{	spacecraftId			PublishedIdentifier
,	facilityId			PublishedIdentifier
,	serviceType			PublishedIdentifier			<- 
,	serviceInstanceNumber		IntUnsigned				<- was in old version:  FunctionalResourceInstanceNumber note: not equivalent IntUnsigned = INTEGER (0 .. 4294967295) and IntPos = INTEGER (1 .. 4294967295)
}

Differences:
:) serviceType was in old version from type 'FunctionalResourceType' and is in new version from type "PublishedIdentifier"
   This is not a problem because 'FunctionalResourceType' ::= 'PublishedIdentifier'
:( serviceInstanceNumber was in old version from type 'FunctionalResourceInstanceNumber' and is in new version from type "IntUnsigned"
   This could be a problem because of the following:
   FunctionalResourceInstanceNumber ::= IntPos ::= INTEGER (1 .. 4294967295)
   IntUnsigned ::= INTEGER (0 .. 4294967295)


#2) Difference found in ReturnBuffer / notifyInvocation / eventValue / qualifiedValues / valid / typeAndValue (or SEQUENCE OF TypeAndValue) (or SET OF TypeAndValue)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
Old version of TypeAndValue:
TypeAndValue					::=	CHOICE
{	integer					[0]	SEQUENCE OF INTEGER
,	integerPositive				[1]	SEQUENCE OF IntPos
,	intUnsigned				[2]	SEQUENCE OF IntUnsigned
,	duration				[3]	SEQUENCE OF Duration
,	characterString				[4]	SEQUENCE OF VisibleString
,	boolean					[5]	SEQUENCE OF BOOLEAN
,	octetString				[6]	SEQUENCE OF OCTET STRING
,	float					[7]	SEQUENCE OF REAL
,	time					[8]	SEQUENCE OF Time
,	enumerated				[9]	SEQUENCE OF Enumerated
,	objectIdentifier			[10]	SEQUENCE OF OBJECT IDENTIFIER
,	typeAndValueExtension			[100]	Embedded
}

New version of TypeAndValue:
TypeAndValue					::=	CHOICE
{	integer					[0]	SEQUENCE OF INTEGER
,	integerPositive				[1]	SEQUENCE OF IntPos
,	intUnsigned				[2]	SEQUENCE OF IntUnsigned
,	duration				[3]	SEQUENCE OF Duration
,	characterString				[4]	SEQUENCE OF VisibleString
,	boolean					[5]	SEQUENCE OF BOOLEAN
,	octetString				[6]	SEQUENCE OF OCTET STRING
,	float					[7]	SEQUENCE OF REAL
,	time					[8]	SEQUENCE OF Time
,	enumerated				[9]	SEQUENCE OF INTEGER
,	objectIdentifier			[10]	SEQUENCE OF OBJECT IDENTIFIER
,	publishedIdentifier			[11]	SEQUENCE OF PublishedIdentifier
,	typeAndValueExtension			[100]	Embedded
}

Differences:
:) enumerated was in old version from type 'SEQUENCE OF Enumerated' and is in new version from type "SEQUENCE OF INTEGER"
   This should not be a problem because in the old version Enumerated ::= IntUnsigned ::= INTEGER (0 .. 4294967295) and in the new version it is defined as INTEGER, but it is an enumeration so the range of value should be enough
:( In the old version the choice [11] has not existed. So if we use an event that has a reference to a PublishedIdentifier in the new version, this could be a big problem with the old framework!!!
   A solution here could be a limitation of the prototype not to use the CHOICE [11] but [10] instead because PublishedIdentifier ::= OBJECT IDENTIFIER


#3) Differences found in ProductionStatus type
-----------------------------------------------
Old version of ProductionStatus:
ProductionStatus			::=	INTEGER
{		configured				(0)
,		operational				(1)
,		interrupted				(2)
,		halted					(3)
}

New version for ProductionStatus type
------------------------------------
ProductionStatus			::=	SEQUENCE (SIZE (1)) OF INTEGER
{		configured				(0)
,		operational				(1)
,		interrupted				(2)
,		halted					(3)
}

Differences:
:) this should not be a problem because I think both definition are coded on the same way.


#4) Differences found between service identifiers
-------------------------------------------------
Old version service identifiers:
svcProductionStatus 				OBJECT IDENTIFIER 	::= {svcParametersId 1}
svcProductionConfigured 			OBJECT IDENTIFIER	::= {svcEventsId 1}
svcProductionInterrupted 			OBJECT IDENTIFIER	::= {svcEventsId 2}
svcProductionHalted 				OBJECT IDENTIFIER	::= {svcEventsId 3}
svcProductionOperational 			OBJECT IDENTIFIER	::= {svcEventsId 4}
svcProductionConfigurationChange		OBJECT IDENTIFIER 	::= {svcEventsId 5}

New version service identifiers:
svcProductionStatus 				OBJECT IDENTIFIER 	::= {svcParametersId 1}
svcProductionStatusVersion1			OBJECT IDENTIFIER	::= {svcProductionStatus 1}
svcProductionStatusChange 			OBJECT IDENTIFIER	::= {svcEventsId 1}
svcProductionStatusChangeVersion1		OBJECT IDENTIFIER	::= {svcProductionStatusChange 1}
svcProductionConfigurationChange		OBJECT IDENTIFIER 	::= {svcEventsId 2}
svcProductionConfigurationChangeVersion1	OBJECT IDENTIFIER 	::= {svcProductionConfigurationChange 1}

Differences:
:( This is a problem because the event name of the basic NOTIFY have been modified. 
   I think they are coming from ASN1 and can not be modified in the API code.