"Bhan, Deepa" wrote:
>
> Hi Egon,
> Thanks for your reply. I now go on to another aspect that i need to
> understand.In my earlier mail i left out the below portion of the ASN.1
> syntax, where an example of the the Information object class 'Extensions' is
> presented namely the 'firstExtension'.
>
> -- Example of addition of an extension named 'Some Network Specific
> Indicator' of type
> -- BOOLEAN, with criticality 'abort' and to be identified as extension
> number 1
> -- Example of definition using the above information object class:
> --
> -- SomeNetworkSpecificIndicator EXTENSION ::= {
> -- EXTENSION-SYNTAX BOOLEAN
> -- CRITICALITY abort
> -- IDENTIFIED BY local: 1
> -- }
>
> -- Example of transfer syntax, using the ExtensionField datatype as
> specified in subclause 5.
> -- Assuming the value of the extension is set to TRUE, the extensions
> parameter
> -- becomes a Sequence of type INTEGER ::= 1, criticality ENUMERATED ::= 1
> and value [1]
> -- EXPLICIT BOOLEAN ::= TRUE.
> --
> -- Use of Q.1400 [28] defined Extension is for further study.
> -- In addition the extension mechanism marker is used to identify the future
> minor additions
> -- to CAP.
>
> firstExtension EXTENSION ::= {
> EXTENSION-SYNTAX NULL
> CRITICALITY ignore
> IDENTIFIED BY local: 1
> }
> -- firstExtension is just an example
> As mentioned earlier the spec. defins the supported extensions as
>
> SupportedExtensions {PARAMETERS-BOUND : bound} EXTENSION ::=
> > {firstExtension, ...
> > -- full set of network operator extensions --
>
> Does this throw any more light on how to interpret the constraint or is it
> still erroneous?
The table constraint is syntactically erroneous, for it cannot be
parameterized (see below).
> -----Original Message-----
> From: Egon Andersen, Talura [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 11, 2000 1:54 AM
> To: Bhan, Deepa
> Subject: Re: A few questions regarding the infomation object classes in
> 3G29-0 78 v3.5.0-CAP implementaion.
>
> Hi Deepa Bhan,
>
> Specifications are not easier to understand, when there are syntactical
> errors in them! (See below.) Please anyone, argue with or against me on
> this, as I've seen this error in other specs too!
>
> Your question is answered below
>
> Bhan, Deepa wrote:
> >
> > Hi:
> > I am studying the Cap spec. and there are a couple of things that i do not
> > understand well
> >
> > 1. Extension field
> >
> > ExtensionField {PARAMETERS-BOUND : bound} ::= SEQUENCE {
> > type EXTENSION.&id ({SupportedExtensions {bound}}),
> >
> > -- shall identify the value of an EXTENSION type
> > criticality CriticalityType DEFAULT ignore,
> > value [1] EXTENSION.&ExtensionType
> >************> ({SupportedExtensions {bound}}{@type}),
> >************> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >************> This should be: DefinedObjectSet, but it isn't!
> > ...
Correct. A Table Constraint cannot reference a parameterized information
object set. As far as I remember, these are things Bancroft Scott and me
have asked to change in the new version of the standard from which they
are extracted.
--
Olivier DUBUISSON
france telecom R&D
_ DTL/MSV - 22307 Lannion Cedex - France
( ) tel: +33 2 96 05 38 50 - fax: +33 2 96 05 39 45
/.\/ --------------------------------------
\_/\ Site ASN.1 : http://asn1.elibel.tm.fr/
