Folks,
In trying to tie up some loose ends in my ASN.1 compiler implementation
I've come across some situations where the interplay between
parameterization
and ambiguity in the notation becomes problematic. The ASN.1 specifications
don't provide sufficient detail for me to determine how to resolve the
problems.
--------------------------------------------------------------------------
Consider the following type definition:
Foobar { TYPE, TYPE:foobar } ::= SEQUENCE {
field1 TYPE DEFAULT foobar,
field2 INTEGER { first (foobar) }
}
X.683 specifies that the DummyReference foobar hides any other Reference
with the same name on the right hand side of the "::=", however the foobar
following the DEFAULT isn't necessarily a Reference, so it may or may not
be hidden.
If TYPE is an INTEGER type with a NamedNumberList then the foobar following
the DEFAULT could be either an identifier or a Reference (I put field2
into the definition so that in the former case the type definition would
not become illegal because the DummyReference name foobar is no longer
"used" within scope).
There are three ways I can think of for dealing with this situation:
(1) Assume any use of the DummyReference name within scope is a Reference
even if it is in a position where a Reference would not be valid.
This strategy would make the following type definition illegal because the
foobar in the NamedNumberList would be assumed to be a valuereference
instead of an identifier:
Foobar { TYPE, TYPE:foobar } ::= SEQUENCE {
field1 INTEGER { foobar(1) } DEFAULT foobar
}
(2) If any of the interpretations of the use of a DummyReference name is
a Reference then immediately throw away the non-Reference interpretations.
Note that in general there may still be some ambiguity about which *kind*
of Reference it is (e.g. a valuereference versus an objectreference).
This strategy would allow the following type definition because the
foobar in the NamedNumberList can't possibly be a Reference:
Foobar { TYPE, TYPE:foobar } ::= SEQUENCE {
field1 INTEGER { foobar(1) } DEFAULT foobar
}
The foobar following DEFAULT would be interpreted as a valuereference.
(3) If any of the interpretations of the use of a DummyReference name is a
Reference of the appropriate kind then immediately throw away the
alternative
interpretations (and conversely, disregard any interpretation of an
ambiguously used name that is a Reference of the wrong kind). This strategy
would allow the following type definition because only the foobar in the
definition of field2 is a Reference of the appropriate kind (i.e. an
objectreference):
Foobar { TYPE-IDENTIFIER:foobar } ::= SEQUENCE {
field1 [0] ENUMERATED { foo, bar, foobar } DEFAULT foobar,
field2 [1] foobar.&Type
}
I'm uneasy about this strategy because it depends on knowing what kind a
DummyReference name is (e.g. is it a valuereference or an objectreference?),
and there may not be sufficient information to hand to disambiguate the
reference.
Which strategy should I follow? Have I missed something, or is there a
deficiency in the ASN.1 specification ?
--------------------------------------------------------------------------
Consider this type definition:
Foobar { FOOBAR } ::= SEQUENCE {
field1 [1] INTEGER (CONSTRAINED-BY{ FOOBAR })
}
It isn't possible to decide whether FOOBAR is an information object class or
a type from the type definition alone. It can only be determined when
Foobar is referenced with actual parameters.
Should such an ambiguous assignment be rejected outright, should it be
disambiguated by its first usage, or should all references with either a
type or a defined object class as the actual parameter be allowed ?
Regards,
Steven
