Hi, The "CONSTRAINED BY" does not affect the rules for encoding the OCTET STRING itself. It just indicates what the "value" carried by the OCTET STRING must be. Please note what X.690, clause 8.1.1.4 states:
8.1.1.4 Encodings specified in this Recommendation | International Standard are not affected by either the ASN.1 subtype notation or the ASN.1 type extensibility notation. NOTE - This means that all constraint notation is ignored when determining encodings, and all extensibility markers in CHOICE, SEQUENCE and SET are ignored, with the extensions treated as if they were in the extension root of the type. ---------------------------------------------------------------------------- Paul E. Thorpe Toll Free : 1-888-OSS-ASN1 OSS Nokalva International: 1-732-302-0750 Email: [EMAIL PROTECTED] Tech Support : 1-732-302-9669 http://www.oss.com Fax : 1-732-302-0023 On Fri, 4 Apr 2003, Paresh Raote wrote: > Hi, > > I have a question about BER encoding of an > octet-string that is 'CONSTRAINED BY' in the following > way. > > This is from GSM CAMEL Application Part (CAP) > specification GSM 09.78. > > AChBillingChargingCharacteristics ::= > OCTET STRING (SIZE(minAChBillingChargingLength .. > maxAChBillingChargingLength)) > (CONSTRAINED BY {-- shall be the result of the > BER-encoded value of the type > CAMEL-AChBillingChargingCharacteristics --}) > > -- The AChBillingChargingCharacteristics parameter > specifies the charging related information to > -- be provided by the gsmSSF and the conditions on > which this information has to be reported back > -- to the gsmSCF with the ApplyChargingReport > operation. The value of the > -- AchBillingChargingCharacteristics of type OCTET > STRING carries a value of the ASN.1 data type : > -- CAMEL-AchBillingChargingCharacteristics. The > normal encoding rules are used to encode this > -- value. > -- The violation of the UserDefinedConstraint shall > be handled as an ASN.1 syntax error. > > CAMEL-AChBillingChargingCharacteristics ::= CHOICE { > timeDurationCharging [0] SEQUENCE { > maxCallPeriodDuration [0] INTEGER > (1..864000), > releaseIfdurationExceeded [1] > ReleaseIfDurationExceeded OPTIONAL, > tariffSwitchInterval [2] INTEGER > (1..86400) > OPTIONAL > } > } > > Will the octet-string tag be a constructed tag or will > it remain as primitive. > > X.690 section 8.7, says, that octet-strings can have > constructed encoding. But this is for the case where > the octet-string is segmented. Each segment has its > own tag-length-value, where the tag is always 4 > (UNIVERSAL OctetString). > > I think the encoding should be a, as per X.690, 8.7. > However since the octet-string 'contains' the encoding > of a sequence, it could be considered to be a > constructed encoding. > > If anyone has encountered such a scenario and knows > what the right encoding is, please let me know. > > Or better still, if anyone has encountered this in GSM > 09.78 CAP messages (This is for ApplyCharging and > ApplyCharging CAP messages), please let me know. > > Thanks, > Paresh > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - File online, calculators, forms, and more > http://tax.yahoo.com >
