still difficulty within the UCLA proposal "Generic Uneven Level P rotection(ULP)"
Gero.X.Baese at MCHP.SIEMENS.DE
Tue Oct 10 10:00:25 EDT 2000
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... :-)
Smith Micro Software, Inc.
From: Logan Modahala [mailto:lmodahal at 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 at imtc.org; h323implementors at pulver.com
Subject: Re: Error in H.323v3 ASN.1
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
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com
More information about the sg16-avd