On Thu, 29 November 2001, Bancroft Scott wrote:
>
> On 28 Nov 2001, Patrick Henry wrote:
>
> > On Wed, 28 November 2001, "Bujji krishna R B" wrote:
> >
> > >
> > > Hello,
> > > I have a doubt regarding the PER encoding of Information Object
> > > Values.
> > >
> > >
> > > FUNCTION ::= CLASS {
> > >
> > > &ArgumentType,
> > > &ResultType DEFAULT NULL,
> > > &Errors ERROR NULL,
> > > &Code INTEGER UNIQUE -- ERROR should be &code
> > > }
> > >
> > > The Above definition of FUNCTION is from the ASN.1 book by Olivier
> > > Dubission.
> > >
> > > funct1 FUNCTION ::= {
> > > &ArgumentType SEQUENCE {a INTEGER, b INTEGER},
> > > &ResultType INTEGER,
> > > &Code 1
> > > }
> > >
> > > funct2 FUNCTION ::= {
> > > &ArgumentType CHOICE {a INTEGER, b INTEGER},
> > > &ResultType INTEGER,
> > > &Code 2
> > > }
> > >
> > > MyFunction{FUNCTION:funct } ::= SEQUENCE { -- ERROR should be Funct
> > > opcode FUNCTION.&Code({funct}),
> > > argument FUNCTION.&ArgumentType({funct} {@Opcode})
> > > }
>
> Minor points: "funct" should start with an upper case letter and "@Opcode"
> should be "@opcode".
>
> > > Is it true that argument field in MyFunction is encoded as an OpenType (ie)
> > > Length encoding followed by the encoding of either SEQUENCE or INTEGER
> > > depending on Opcode.
> >
> > Yes, MyFunction is an open type.
>
> No, MyFunction is a parameterized type that resolves to a SEQUENCE type.
> "argument" is an open type, not MyFunction.
This term "open type" is used ambiguously in the literature, sometimes meaning the
"hole" as you indicate here, sometimes meaning the type containing the hole, whether
the containing type is parameterized or not. Personally I prefer to think of an open
type as the type containing the hole, not vice versa: it is "open" precisely because
it contains a "hole".
>
> > > So Can I rewrite MyFunction as follows
> > >
> > > MyFunction ::= SEQUENCE {
> > > opcode INTEGER,
> > > argument OCTET STRING
> > > }
> > >
> >
> > No, I certainly hope not!
>
> If PER is being used this will work. If BER, no.
>
> > Assuming an object-set,
> >
> > Funct FUNCTION ::= {funct1 | funct2}
> >
> > you could re-write two specific instances of MyFunction,
> >
> > MyFunction-1 ::= SEQUENCE {
> > opcode INTEGER(1),
> > argument SEQUENCE { a INTEGER, b INTEGER }
> > }
> >
> > and
> >
> > MyFunction-2 ::= SEQUENCE {
> > opcode INTEGER(2),
> > argument CHOICE { a INTEGER, b INTEGER }
> > }
> >
>
> If one REALLY wanted to use such an "unusual" approach to expanding a
> parameterized type whose components are constrained using an information
> object set, what you show here would work for BER and DER, but not for
> other encoding rules.
Ignore that this example is parameterized and you'll see that the problem also applies
to resolving any "open" type: a compiler must be able to distinguish among the various
possible expansions depending upon the components of a given value. Again, I don't see
how/why the encoding rules should have an effect on the abstract notation.
>
> > I assume that the compiler will be smart enough to encode such values
> > according to these re-written types no matter what encoding rules are
> > chosen.
>
> Nope! If you rewrite the ASN.1 as Krishna suggests it will work for PER
> but not other encoding rules.
Your approach begs the question, How dow a reciever parse an open type if the hole is
encoded as a typeless blob?
Patrick
>
> -------------------------------------------------------------------------
> Bancroft Scott Toll Free :1-888-OSS-ASN1
> OSS Nokalva International:1-732-302-0750
> [EMAIL PROTECTED] Tech Support :1-732-302-9669 x-1
> 1-732-302-9669 x-200 Fax :1-732-302-0023
> http://www.oss.com
Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com
