Prasad Vasa wrote:
>
> Hello ,
> Is it allowed to use ANY in the new ASN.1 (97) descriptions?
NO. By the way, 97 is considered a bit old these days! The current
version is the 2002 version. This is expected to be finally approved by
ITU-T in the middle of July (a couple of weeks away), and by ISO in late
Summer. The text will be freely available as a pre-published ITU-T
Recommendation in the next two or three weeks. However, for the purpose
of this e-mail, 2002 is the same as 97. (For those that might be
interested, 2002 contains a number of new features such as a pattern
constraint and an OCTET STRING (CONTAINING .....) construct, but is
fully backward compatible - any ASN.1 that conforms to 97 conforms to
2002. People are encouraged to reference 2002 in any
about-to-be-published standards.)
> If not can you please specify subtitution for this structure( esp. ANY)?
>
> E.g.
>
> XXArg ::= SEQUENCE {
> errorId Error,
> cause ANY OPTIONAL}
The recommended change is:
XXArg ::= SEQUENCE {
errorId Error,
cause OPEN.&Type OPTIONAL}
with
OPEN ::= CLASS {&Type }
This says that the field is an information object of a class that simply
contains a type definition (no identification associated with the type).
It is important to recognise that in PER, you just cannot find the end
of an encoding if you don't know what the type is whose value is being
encoded. This is largely why ANY was withdrawn. In practice, however,
use of ANY means that the type used for the field is
implementation-dependent, and will be determined by bilateral agreement
(calling addresses), whether it is raining or not, or whatever!
The above could be modified to:
XXArg ::= SEQUENCE {
errorId Error,
cause OPEN.&Type ({{...}}) OPTIONAL}
which makes it clear to a tool (and to a very knowledgeable reader!)
that the actual type to be used is implementation dependent and can be
different in every instance of communication. But the additional syntax
does not read well, is not necessary, and adds little, except perhaps
when using some tools. The added syntax is not recommended!
John L
> Warm regards,
> Vasa
>
> -----Original Message-----
> From: Ed Day [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 05, 2002 10:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [ASN.1] Question on XER encoding of SEQUENCE OF element
> types
>
> Hi John,
>
> > However, I think your question is slightly obscure! Any value of B (as
> > the root type) will start <B> and end </B>. But if we have B embedded
> > in a sequence:
> >
> > C::= SEQUENCE {
> > .......
> > comp B,
> > .......
> > }
> >
> > then we would get the fragment:
> >
> > <comp><a>1</a><a>29</a><a>3</a></comp>
>
> True, but the issue is not on a SEQUENCE, it is on a SEQUENCE OF where the
> rules are not as clear (at least to me). No matter what you have in a
> SEQUENCE, the element name tag always replaces the type name tag (unless it
> is unnamed which is now illegal anyway). In SEQUENCE OF, sometimes typename
> is used as an explicit tag, sometimes it is not. The proposed ammended text
> would make it clear.
>
> Regards,
>
> Ed
>
> ----- Original Message -----
> From: "John Larmouth" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Thursday, July 04, 2002 5:29 AM
> Subject: Re: [ASN.1] Question on XER encoding of SEQUENCE OF element types
>
> > (I am copying this to asn1edit, as it may need to be registered as a
> > defect.)
> >
> >
> > Ed, text that covers defined types:
> >
> > 25.10 If the first alternative of "XMLDelimitedItem" is used, then if
> > the component of the sequence-of type (after ignoring any tags) is a
> > "typereference" or an "ExternalTypeReference", then the
> > "NonParameterizedTypeName" shall be that "typereference" or
> > "ExternalTypeReference", otherwise it shall be the "xmlasn1typename"
> > specified in Table 4 corresponding to the built-in type of the
> > component.
> >
> > But this relates only to the tag to be used *if* XMLDelimiteditem" is
> > needed. For a CHOICE type, it is NOT needed.
> >
> > The problem is really with 25.5, which says
> >
> > where the "Type" of the component is listed in ....
> >
> > but should in fact say
> >
> > where the type of the component (after de-referencing of any type
> > references) is listed in ....
> >
> > I think this should be regarded as a defect, and mended in due course.
> >
> > However, I think your question is slightly obscure! Any value of B (as
> > the root type) will start <B> and end </B>. But if we have B embedded
> > in a sequence:
> >
> > C::= SEQUENCE {
> > .......
> > comp B,
> > .......
> > }
> >
> > then we would get the fragment:
> >
> > <comp><a>1</a><a>29</a><a>3</a></comp>
> >
> > John L
> >
> >
> >
> > > Ed Day wrote:
> > >
> > > Hi,
> > >
> > > In looking at Clause 25 of the 2002 X.680 pre-release, I am unable to
> > > determine how an element of a SEQUENCE OF type is to be encoded when a
> > > defined type that references one of the ValueList case types is
> > > referenced. For example:
> > >
> > > A ::= CHOICE {
> > > a INTEGER,
> > > b BOOLEAN
> > > }
> > >
> > > B ::= SEQUENCE OF A
> > >
> > > Would a single element of choice a with value 1 be encoded as
> > > <A><a>1</a></A> or <a>1</a>?
> > >
> > > 25.6 through 25.8 talk about TaggedType, ConstrainedType, and
> > > SelectionType rules, but I see no mention of DefinedType. Am I
> > > missing something?
> > >
> > > Regards,
> > >
> > > Ed Day
> > > Principal Engineer
> > > Objective Systems, Inc.
> > > [EMAIL PROTECTED]
> > > (484) 875-3020 (main)
> > > (610) 608-4930 (mobile)
> > > (610) 321-0361 (fax)
> > > (877) 307-6855 (toll-free)
> > >
> > >
> > >
> >
> > --
> > Prof John Larmouth
> > Larmouth T&PDS Ltd
> > (Training and Protocol Development Services)
> > 1 Blueberry Road
> > Bowdon [EMAIL PROTECTED]
> > Cheshire WA14 3LS Tel: +44 161 928 1605
> > England Fax: +44 161 928 8069
--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Development Services)
1 Blueberry Road
Bowdon [EMAIL PROTECTED]
Cheshire WA14 3LS Tel: +44 161 928 1605
England Fax: +44 161 928 8069
