Logan,
I am saying that most and possibly all fielded ASN.1 PER decoders ignore the lengths and encapsulated values of all NULL CHOICE components that are not in the extension root--they blindly skip over them because there is nothing of interest therein. What possible use could there be in a decoder checking the length and contents of an empty open type?
I suppose it depends on what you mean by "early stage," but H.323v3 was Decided over a year ago and v3 products have probably been shipping for months now. I'd even be hard pressed to say that H.323v4 is in an early stage. H.323v5, however... :-)
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Logan Modahala [mailto:lmodahal@cisco.com] Sent: Monday, October 09, 2000 11:54 AM To: Paul Long Cc: Mailing list for parties associated with ITU-T Study Group 16; h323implementors@imtc.org; h323implementors@pulver.com Subject: Re: Error in H.323v3 ASN.1
Paul,
With extension addition fields, I do understand that the encoding is OpenType and the OpenType field's encoding length is included. But my point is that if the field is encoded by the peer EP, how does the ASN.1 decoder know whether to ignore the entire field or decode the OpenType field. If the field is to be ignored, then fine. If the field is not to be ignored, the the types must match between the two entities for a field occupying the same position in the ordering.
What you are proposing can only be achieved if the ASN.1 compiler supports a directive(such as the RELAXPER decoder flag) to inform the encode/decode library to ignore a particular field.
I am not sure if I will support this, though. Personally, H323v3 is in it early stage and let us correct it the right way. We have been in this situation.
- Logan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com