Re: [ASN.1] SET OF encoded with length=0
On Tue, 4 Nov 2003, Norbert van Bolhuis wrote:
Is it allowed to encode (BER) a SET OF
with length_byte=0 ?
Yes.
Bancroft
So, for example:
300a80065678901234563100
Class =CLASS_UNIVERSAL
Constructed
Type =SEQUENCE,SEQUENCE_OF
Length =10
{
Class =CLASS_CONTEXT_SPECIFIC
Type =NONE_0
Length =6
Val=0x567890123456
Translated =567890123456
Class =CLASS_UNIVERSAL
Constructed
Type =SET,SET_OF
Length =0
}
RE: [ASN.1] Unexpected error
On Wed, 23 Jul 2003, Bruno Konik wrote: My understanding of X681 9.8 quoted there: - A VariableTypeValueFieldSpec specifies that the field is a variable-type value field (see 3.4.21): VariableTypeValueFieldSpec ::= valuefieldreference FieldName ValueOptionalitySpec? The name of the field is valuefieldreference. The FieldName (see 9.14), which is relative to the class being specified, shall be that of a type field; the type field which is either in the same information object as the value field, or is linked by the chain of object fields whose references appear in the FieldName, will contain the type of the value. (All link fields whose field references appear in the FieldName shall be object fields.) The ValueOptionalitySpec, if present, specifies that the value may be omitted in an information object definition, or, in the DEFAULT case, that omission produces the following Value. The ValueOptionalitySpec shall be such that: a)if the type field denoted by the FieldName has a TypeOptionalitySpec of OPTIONAL, then the ValueOptionalitySpec shall also be OPTIONAL; and b)if the ValueOptionalitySpec is DEFAULT Value, then the type field denoted by the FieldName shall have a TypeOptionalitySpec of DEFAULT Type, and Value shall be a value of that type. - is that in the case of : ResultType DEFAULT NULL, result-if-error ResultType DEFAULT NULL, is the right writing according to b) above since NULL is the value of NULL type. I don't see why adding NULL or : NULL. Comments? Yes, you are right. - 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
Re: [ASN.1] Interpretation?
On Tue, 24 Jun 2003, Ramaswamy wrote:
Hi,
This was my initial understanding but when we consider the Type PL2 and
the value pl2 we can observe that the value 6 does not conform to the
constraint and the syntax checkers did not fret about this. Please clarify.
Thanking you.
The tool should have reported an error.
-
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
Yours Sincerely
Ramaswamy
- Original Message -
From: Olivier Dubuisson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, June 24, 2003 1:11 PM
Subject: Re: [ASN.1] Interpretation?
Ramaswamy wrote:
Hi,
As part of my learning of ASN.1 I wrote the following ASN.1 spec, so
this code serves no other purpose that aid in my understanding of the
ASN.1 language. Pls read thru the following spec -
ParameterList DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
--ParameterList1 { hehe } ::= hehe
ValueSet INTEGER ::= { 1|3|5|7|9 }
ParameterList2 { Governor , Governor:Type } ::= SEQUENCE
{
value Type
}
ParameterList3 { Governor, Governor:value } ::= SEQUENCE
{
val Governor DEFAULT value
}
PL2 ::= ParameterList2 {INTEGER, {1|2|3|4|5}}
PL3 ::= ParameterList3 {REAL,0}
pl2 PL2 ::= { value 6 }
END
I understand that PL3 is equivalent to the following
PL3 ::= SEQUENCE
{
val REAL DEFAULT 0
}
If the above interpretation is correct then how is PL2 to be
interpreted??
PL2::= SEQUENCE {
value INTEGER (1|3|5|7|9) }
--
Olivier DUBUISSON
france telecom RD
DTL/TAL - 22307 Lannion Cedex - France
t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/
Re: [ASN.1] Interpretation?
On Mon, 23 Jun 2003, Ramaswamy wrote:
Hi,
I have some observations and based on those I have the following
queries. I had improved the prev ASN.1 spec for the analysis. Pls find the
spec here -
ParameterList DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
--ParameterList1 { hehe } ::= hehe
ValueSet INTEGER ::= { 1|3|5|7|9 }
ParameterList2 { Governor , Governor:Type } ::= SEQUENCE
{
value Type
}
ParameterList3 { Governor, Governor:value } ::= SEQUENCE
{
val Governor DEFAULT value
}
VS ::= SEQUENCE
{
val1 ValueSet
}
PL2-1 ::= ParameterList2 {INTEGER, {0..100}}
PL2-2 ::= ParameterList2 {REAL, {0|PLUS-INFINITY|MINUS-INFINITY}}
PL2-3 ::= ParameterList2 {BIT STRING(SIZE(65536)), {'0'H|'1'H|'2'H|'3'H}}
PL3-1 ::= ParameterList3 {REAL,0}
PL3-2 ::= ParameterList3 {INTEGER,10}
pl2-1 PL2-1 ::= { value 6 }
pl2-2 PL2-2 ::= { value { mantissa 1, base 2, exponent 10 } }
END
I am not convinced about the interpretation of PL2 presented before for
the following reasons. Kindly correct if my inference is mistaken. This code
is interpreted differently by different syntax checkers. In one case the
value 'field' of PL2-1, PL2-2, PL2-3 were considered as OpenType, and in
another place it was the 'Governor' alone that was considered not the 'Type'
that is governed by the 'Governor'. To be precice PL2-1 was INTEGER, PL2-2
was REAL and PL2-3 was BIT STRING(SIZE(65536)). This I infered from the fact
that in the value - assignment pl2-2 the real value specified is not within
the limits (single value's) of the value set and the syntax checker did not
mention anything about the same. This led me to infer that the ValueSet
given for 'Type' is not considered at all. I'm not very sure of the
behaviour I mentioned in the few sentences above, but this is my inference.
In my understanding the ASN.1 language specifies as to what is OpenType
and what is not. And further for the the 'val1' field of Type 'VS' the
ValueSet mentioned were taked into consideration. Would the following
inference be valid - If a ValueSet is passed as a parameter and it
representes a type within a constructed type (SEQ/SET/CHOICE not an object
class) then, only the type(governor) is considered and not the value set
itself. I understand that this cannot be the case for an ObjectSet since an
ObjectSet would only be used in an ObjectClass. Kindly explain.
Both tools that you are using are in error. See the following from
ITU-T X.680 (2002), clause B.6.4:
B.6.4 If a Type is supplied as an actual parameter for a dummy
parameter which is a value set dummy parameter, then all values of that
Type are required to have value mappings to values in the governor of
the value set dummy parameter. The actual parameter selects the total
set of values in the governor which have mappings to the Type.
So, PL2 below evaluates to:
PL2 ::= SEQUENCE
{
value INTEGER (1|3|5|7|9)
}
-
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
- Original Message -
From: Bancroft Scott [EMAIL PROTECTED]
To: Ramaswamy [EMAIL PROTECTED]
Sent: Monday, June 23, 2003 5:06 PM
Subject: Re: [ASN.1] Interpretation?
On Mon, 23 Jun 2003, Ramaswamy wrote:
Hi,
As part of my learning of ASN.1 I wrote the following ASN.1 spec, so
this code serves no other purpose that aid in my understanding of the ASN.1
language. Pls read thru the following spec -
ParameterList DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
--ParameterList1 { hehe } ::= hehe
ValueSet INTEGER ::= { 1|3|5|7|9 }
ParameterList2 { Governor , Governor:Type } ::= SEQUENCE
{
value Type
}
ParameterList3 { Governor, Governor:value } ::= SEQUENCE
{
val Governor DEFAULT value
}
PL2 ::= ParameterList2 {INTEGER, {1|2|3|4|5}}
PL3 ::= ParameterList3 {REAL,0}
pl2 PL2 ::= { value 6 }
END
I understand that PL3 is equivalent to the following
PL3 ::= SEQUENCE
{
val REAL DEFAULT 0
}
If the above interpretation is correct then how is PL2 to be
interpreted?? Is it just the type that is considered, in which case
what happens to the ValueSet specified. Thanking you.
It is interpreted the same as if you had defined Type as a
valuesetreference and ParameterList2 were not parameterized.
Or put another way:
PL2 ::= SEQUENCE
{
value INTEGER (1|3|5|7|9)
}
-
Bancroft Scott Toll Free:1-888-OSS-ASN1
OSS Nokalva International:1-732-302-0750
Re: [ASN.1] problem with t.128 asn
On Thu, 7 Nov 2002, Alex Komissarov wrote:
Hello all,
I'm having problem compiling t.128 asn's (using tool from
http://asn1.elibel.tm.fr/en/tools/asnp/index.htm):
First problem (t.128-base.asn1):
-- Bit Flag Types
ExtraTextFlags ::= BIT STRING
{
opaqueRectangle (1),
clipToRectangle (2),
deltaXPresent (15),
...
}
-- syntax error : an extension marker ... can't be used within a BIT
STRING type (note that such a type is implicitly extensible)
The error message is correct. Extension markers are not allowed in a
NamedBitList.
Second problem:
ROP2 ::= Integer8
{
-- syntax error : in the actual parameter list
r2BLACK (1),
r2DPon (2),
The error message is correct. A NamedNumberList can only be applied to
built-in type INTEGER.
Third problem:
ROP3 ::= Integer8
{
-- syntax error : in the actual parameter list
r3BLACK ('00'H),
The error message is correct. Again, a NamedNumberList can only be
applied to built-in type INTEGER.
Source files located at: www.ixresearch.com/t.128-legacy.asn1 and
www.ixresearch.com/t.128-base.asn1
I'm new to this, and still reading relevant books. Syntax seems ok???
No, the syntax is incorrect.
If someone has ready-to-use T.12x ASN, I'll really appreciate it...
I'll send you a copy.
-
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
[ASN.1] Re: asn1xml Parser of XML Vs. ASN
On Fri, 11 Oct 2002, Andrew Fan wrote: Bancroft Scott wrote: On Fri, 11 Oct 2002, Andrew Fan wrote: Hi, In XML technologies, there are some tools or protocols like SAX/SAX2, DOM which can dynamicly parse XML stream, shipped XML schema or DTD syntax, which make XML applications have quite good flexibilities and extensibilities. In some sense, ASN Modules definitions something like XML schema or DTD, and the encoded ASN contents something like XML document, may be there will be something like XML parser, events interfaces or trees interfaces. If we can do this, I believe that ASN will have a more comprehensive process. :-) At present, most of the ASN parsers just parser the ASN synatx presentation into structs or classes in the form of C/C++, Java, etc., which have some limitations compared by XML parser. The OSS Compile-And-Go Library (CAGL) allows you to parse ASN.1 modules at runtime, and instead of generating C structs or Java/C++ classes, etc., you can immediately use the OSS IAAPI library functions (included with the OSS ASN.1 Tools at no added cost) to create values, encode them, and decode messages. The CAGL produces no output files for you to compile or link with. Among the benefits of this solution is that it makes it easy for you to implement applications such as ASN.1 value editors, protocol analyzers and use encoders/decoders which can work with any ASN.1 module without need to change or rebuild the application program. The model is analogous to that of DOM, in that it allows you to parse an ASN.1 module(s) and then use this result to immediately parse either XML documents or PER, BER or DER messages, and convert between these if you wish. That's what I'm searching for. Can I get an free evaluation version? Please send such queries to the product vendor, in this case [EMAIL PROTECTED] I have visit http://www.oss.com/products/tools.html , but I found no introductions of CAGL. Oversight. It is being added. While the CAGL functions have been in use for a couple years in OSS's ASN-1Step, it was only recently productized due to demand. Another questions, if OSS has tools like XML DOM or XML SAX, why not open the interfaces and make it standard, just like DOM and SAX? If so, I think that ASN1, certainly OSS too, will gain more comprehensive and more wide marketing. ASN have more advantages than XML if it also have enough toolkits and open enough like XML. It certainly is possible for ASN.1 tool vendors to adopt a true DOM or true SAX (standard) interface, and there has been some discussion along this line, but nothing has come of it so far. - 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
[ASN.1] Re: AW: asn1xml Parser of XML Vs. ASN
On Fri, 11 Oct 2002, Hellmann Peter (ext) wrote: Hi, does someone know if there is a tool out there that creates BER coded ASN.1 files to appropriate XML files in order to have a more understandable view of the data in the file? Thanks for any hints and links, If you are looking for a GUI tool to convert a file from BER or PER to XML, then the latest version of OSS ASN-1Step will do this without your needing to write any code. Another option: Using the OSS ASN.1 Tools, if you wish to write a simple program to convert from BER or PER to XML all you have to do, literally, are three calls: ossDecode();// Decode from BER or PER to internal format ossSetEncodingRules(world, OSS_XER); ossEncode();// Encode from internal format to XML It is that easy. The output from the ossEncode() will be an XML document that you can then write to a file, display or whatever. If you specify the -xsl option the OSS ASN.1 compiler will generate a default XML stylesheet that allows you to easily customize how the XML document is displayed. You can also specify -dtd to instruct the compiler to generate an XML DTD that many 3rd party XML tools use for validation. If you have product-specific questions please send them to the vendor, in this case [EMAIL PROTECTED] - 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
Re: [ASN.1] ROSE and associated semantics
On Fri, 11 Oct 2002, Bernard Kufluk wrote:
Hi,
I have the problem of receiving a message like this:-
--
| ROSE OPERATION | ARGUMENT |
--
The architecture I am looking to implement:-
1. Decode the header and identify the operation value
2. Use the operation value to decided which plug in to pass the raw
undecoded argument to.
3. Decode the argument in the plug in and act appropriately.
This seems to be a typical OSI style model - the first layer decoding the
outer part of the message; and then passing the inner message on to a
further layer.
However when I came to implement this - I find that I cannot find an
appropriate way to specify the argument part of the rose message - apart
from OCTET STRING. OCTET STRING seems to be frowned upon as an outmoded
way of specifying the hole in the packet.
The ROSE ASN.1 definitions seem to be geared towards defining the whole
packet at decode time - you cannot decode some of the packet without a
knowledge of the contents.
The design described above gives two stage decode - so that the orginal
layer that receives the message does not need to include the ASN.1 for the
argument. This means that I can then add future plug-in's without having
to change any code in original layer.
Does anyone have an answer to this ? (or should I use OCTET STRING *or*
change my architecture to decode the whole packet in one go ?)
argument is defined as an open type:
argumentOPERATION.ArgumentType ({Operations} {@opcode})
You will not be able to decode the contents of the open type until you use
opcode to determine the type of the value being carried by argument.
This gives you precisely what you are looking for.
-
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
Re: [ASN.1] Class definitions in ASN
On Mon, 7 Oct 2002, Bernard Kufluk wrote:
Hi,
Trying to get to grips with asn definitions... .
I have something that looks like this:-
RoseAPDU {InvokeId:InvokeIdSet, OPERATION:Invokable, OPERATION:Returnable}
::= CHOICE
{
invoke [1] Invoke {{InvokeIdSet}, {Invokable}},
returnResult [2] ReturnResult {{Returnable}},
returnError [3] ReturnError {{Errors{{Returnable,
reject [4] Reject
}
(CONSTRAINED BY { -- must conform to the above definition -- }
! RejectProblem : general-unrecognisedPDU)
and when compiled (with the OSS compiler and the relevent supporting files)
I'm not getting an APDU, or any structure in the header file for this
definition.
Can someone please tell me why ?
The [EMAIL PROTECTED] mailing list is for ASN.1-related questions that are not
specific to any vendor product. OSS provides tech support 24 hours a day
7 days a week; please send OSS tech support questions to [EMAIL PROTECTED]
I have forwarded your question to OSS tech support and you will be hearing
from them shortly.
-
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
RE: [ASN.1] Abount definite and indefinite lenght encoding
On Thu, 12 Sep 2002, Pino Roberto wrote: I'm sorry for the misunderstanding...I used always the word decoder but what I want to know is abount the encoder and about encoding function... I understood that in the encoded file a structure is recognized as encoded with indefinite lenght if the tag 80 is found... But my problem was how to tell to the encoder that a structure has to be encoded with indefinite lenght and that another structure must be encoded with definite lenght within the same file. For example which is the ASN.1 definition for a structure like this: main_structure (to be encoded in indefinte way) field1 octet_string[10] (to be encoded in definite way) field2 any_substructure_type (to be encoded in definite way) This a tool-specific matter and so is inappropriate for this list. Check with the maker of the encoder that you are using. - 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
Re: [ASN.1] New ASN.1 Tool for 3GPP from Zesium
On Fri, 13 Sep 2002, Rick Reed TSE wrote: DUBUISSON Olivier at [EMAIL PROTECTED] wrote on 09/09/2002 16:22: This list is not dedicating to any particular tool. Such questions/ remarks should not be sent to this reflector which is dedicated to technical questions on ASN.1. I am a little surprised at the reaction to these messages. It seems to me to be an appropriate list to announce the availability of tools. When the list was created many years ago it was with the intent to serve as a forum for technical non-vendor-specific discussions. This has not changed. If the list IS intended for just technical discussion then: 1. Why doesn't the list have a more appropriate name (such as ASN1techdisc); It did not cross my mind at the time the list was set up, nor did anyone make such a suggestion. Since there were no ASN.1-specific list at the time, asn1 seemed a fine name. 2. What do I find the list for discussion related to ASN.1 that is non-technical? There is no such list at the moment. Product announcements typically go to the France Telecom web site, where they are listed. I think FT would be a good place to host an asn1-announce mailing list. Hmmm ..., or perhaps the ASN.1 Consortium would also be a good place for such a list. - 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
Re: [ASN.1] Abount definite and indefinite lenght encoding
On Wed, 11 Sep 2002, Pino Roberto wrote: Hi, I would like to know if it's possible with ASN.1, use different lenght encodings for structure in the same file. For example, is possible encoding a structure with indefinite lenght encoding and another (may be a substructure of the first one) with definite lenght encoding? Yes, with BER the encoder is free to choose either definite or indefinite length encodings. And if it's possibile, how can the encoder recognize structures to be encoded with definite lenght encoding from structures with indefinite lenght encoding? Is there any ASN.1 tag to use? Thanks, bye, Roberto I take it that you meant to say how can the decoder Yes? If yes, it can tell whether definite or indefinite length encoding was used based on whether the length field has a value of hex 80. If you meant how can the encoder ..., check with the provider of the tool that you are using. - 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
Re: R: [ASN.1] Abount definite and indefinite lenght encoding
On Wed, 11 Sep 2002, Pino Roberto wrote: Thanks for the answers... My second question was How can I tell to the decoder that a structure must be encoded with indefinite lenght and that another must be encoded with definite lenght within the same input file? Is there any standard identifier in the ASN.1 definition of the structure to use?. My question was about the ASN1 syntax to say that a structure must be encoded with indefinite lenght. You don't tell the decoder that a value was encoded using the definite or indefinite length form. X.690 (BER) requires all decoders that conform to the BER standard to support both definite and indefinite length encodings. The BER decoder can determine which value is encoded using the definite or indefinite length form because the encodings are self-descriptive. A length of hex 80 says it is using the indefinite length form, and anything else says it is the definite length form. Bancroft -Messaggio originale- Da: Bancroft Scott [mailto:[EMAIL PROTECTED]] Inviato: mercoledì 11 settembre 2002 14.33 A: '[EMAIL PROTECTED]' Oggetto: Re: [ASN.1] Abount definite and indefinite lenght encoding On Wed, 11 Sep 2002, Pino Roberto wrote: Hi, I would like to know if it's possible with ASN.1, use different lenght encodings for structure in the same file. For example, is possible encoding a structure with indefinite lenght encoding and another (may be a substructure of the first one) with definite lenght encoding? Yes, with BER the encoder is free to choose either definite or indefinite length encodings. Of course, if an application profile dictates that only one or the other must be used, then you are obliged to use the specified one. And if it's possibile, how can the encoder recognize structures to be encoded with definite lenght encoding from structures with indefinite lenght encoding? Is there any ASN.1 tag to use? Thanks, bye, Roberto I take it that you meant to say how can the decoder Yes? If yes, it can tell whether definite or indefinite length encoding was used based on whether the length field has a value of hex 80. If no, check with the provider of the tool that you are using. - 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
[ASN.1] [xcbf] Re: Biometrics web service (fwd)
Hi,
I think the asn1 list might find the following discussion interesting.
It occurred on XML Common Biometric Format discussion list (xcbf).
XCBF describes its messages in ASN.1, and encodes them in the XML
Encoding Rules of ASN.1 (XER).
Bancroft
-- Forwarded message --
Date: Sun, 28 Jul 2002 12:47:21 +0100
From: John Larmouth [EMAIL PROTECTED]
To: Phil Griffin [EMAIL PROTECTED]
Cc: xcbf [EMAIL PROTECTED]
Subject: [xcbf] Re: Biometrics web service
Phil Griffin wrote:
John,
Looking at a proposed ASN.1 based WSDL web service for
biometrics for an X9.84 meeting next week in California
and I have a question. Isn't
xsd:complexType name=PrivacyHTTPResponseType
xsd:sequence
xsd:element
name=privacyObjectResponse type=xsd:string/
/xsd:sequence
/xsd:complexType
the same thing as saying something like
PrivacyHTTPResponseType ::= SEQUENCE {
privacyObjectResponse UTF8String
}
Seems that it would be. It's just hard to imagine why
anyone would want to use the former instead of the
later. Maybe it's what I'm used to seeing, but the
later would seem to be arguably easier to read, write,
and comprehend.
Yup. This is the thrust of most of my ASN.1/XSD comparisons (see my
LineItemPair in the MoU presentation). The bit I like in the XSD is the
word complexType!
Maybe I've overlooked something. I recall your mentioning
something during a break in Baltimore at the MoU MG meeting
last week about the ability to carry all of the UTF8
characters in XML that are allowed in ASN.1 encodings. Do
you recall this discussion?
This is a very techie issue. XML forbids (if you believe in the letter
of the W3C law) the transmission of control characters except for a very
few such as CR and LF and TAB and SP. You cannot even (legally) use the
hex; notation to represent them. This is forbidden.
ASN.1 allows you to write, for example, bel/, or stx/, and can
transfer a pure binary string (such as an authenticator) in this way.
XSD is incapable of transmitting full UNICODE | ISO 10646, because
XML is incapable of representing control characters (without additional
specification such as the ASN.1 spec).
Alessandro tells me this has been aired in the XML discussion groups,
and will NOT be mended - they think an XML document should be pure
human-readable graphics characters.
Of course, you can always use a BASE64 encoding for pure binary to
represent a character string, but that is a hell of a lot less efficient
than the ASN.1 transfer with straight Unicode and the bel/ etc tags
for the occasional control character.
John L
To subscribe or unsubscribe from this elist use the subscription
manager: http://lists.oasis-open.org/ob/adm.pl
Re: [ASN.1] doubts about context tag
On Thu, 18 Jul 2002, tong wrote:
HI all
again GSM-MAP
example:
UpdateLocationArg ::= SEQUENCE {
msi MSI,
msc-Number [1] ISDN-AddressString,
vlr-Number ISDN-AddressString,
lmsi[10] LMSI OPTIONAL,
extensionContainerExtensionContainer OPTIONAL,
... ,
vlr-Capability [6] VLR-Capability OPTIONAL }
1 why encode 1,6,10,not continuously?
I don't follow the question. Please rephrase.
2 the order of context why not from small to big ? in this example is 1,10,6.
I don't know (but see my guess below). Perhaps someone who was involved
in the writing of GSM-MAP can give you some insight.
3 why some subtype(vlr-Number) not have context tag?
Some components are not taged because tags are required only when the type
would be ambiguously defined without it. A better question would be, Why
does msc-Number have a tag, for it is not required by ASN.1?. I suspect
that whomever wrote the ASN.1 module thought that by adding tags where
they aren't required by ASN.1 it would somehow help them in manually
writing an encoder/decoder. Another possibility is that somewhere else in
GSM-MAP these components are tagged as you see above, and the person who
defined UpdateLocationArg thought that it would make the definition more
consistent if they were tagged the same here.
4 msc-Number not have OPTIONAL,so must presence,and so use context tag is absolutely
unneeded ?
Correct. As far as ASN.1 goes, there is no need for the tag on
msc-Number. Note that it is required by encoders/decoders since it was
specified in the definition of the UpdateLocationArg type.
-
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
Re: [ASN.1] a doubt about CHOICE?
On Wed, 17 Jul 2002, tong wrote:
hi all
In GSM-MAP(ASN.1BER IMPLICIT),I have a doubt about CHOICE:
example 1:
Ext-SS-InfoList ::= SEQUENCE SIZE (1..maxNumOfSS) OF
Ext-SS-Info
Ext-SS-Info ::= CHOICE {
forwardingInfo [0] Ext-ForwInfo,
callBarringInfo [1] Ext-CallBarInfo,
cug-Info[2] CUG-Info,
ss-Data [3] Ext-SS-Data,
emlpp-Info [4] EMLPP-Info}
Ext-ForwInfo ::= SEQUENCE{
ss-Code SS-Code,
forwardingFeatureList Ext-ForwFeatureList,
extensionContainer [0] ExtensionContainer OPTIONAL,
...}
then begin from Ext-SS-InfoList :0x30 0xXX 0xA0(1010) (0xXX
mean length) Now the 0xA0 mean the tag of forwardingInfo,and next
octet after 0xA0 mean the length of forwardingInfo,is this right?
Yes.
example2:
SubscriberInfo ::= SEQUENCE {
locationInformation [0] LocationInformation OPTIONAL,
subscriberState [1] SubscriberState OPTIONAL,
extensionContainer [2] ExtensionContainer OPTIONAL,
...}
SubscriberState ::= CHOICE {
assumedIdle [0] NULL,
camelBusy [1] NULL,
netDetNotReachable NotReachableReason,
notProvidedFromVLR [2] NULL}
begin from SubscriberInfo: how can we encode the assumedIdle?
0x30 0xXX 0xA1(1011 subscriberState) 0xXX 0x80(1000
assumedIdle) 0x00(length of NULL)
Is the encoding of example 1 and 2 correct?
Yes.
and so example2 is longer than example1,have an extra tag of choice.
CHOICE itself does not have a tag. However, tags applied to CHOICE are
*always* EXPLICIT, even if at the beginning of the module it says that the
tag environment for the module is IMPLICIT.
Bancroft
Re: [ASN.1] WITH-COMPONENTS creates new type or just semanticallyconstrains?
On Wed, 17 Jul 2002, Paul Long wrote:
I have questions about inner subtyping. Given these two type definitions:
Parent ::= SEQUENCE
{
anOptionalThing INTEGER OPTIONAL,
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
Child ::= Parent WITH COMPONENTS { ..., anOptionalThing ABSENT }
does the WITH-COMPONENTS construct essentially create a new type, i.e.,
SEQUENCE
{
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
No.
or does it merely apply a semantic constraint to the existing type, i.e.,
the anOptionalThing is still syntactically OPTIONAL but its _value_ is
constrained to not be present?
The latter.
For a PER encoding, the question could be stated as, is there a
presence bit (set to 0) in the bit-map preamble for the
anOptionalThing component, or is even its presence bit absent?
Inner type constraint is not PER-visible, so it has no effect on the
structure of PER encodings. However, in the example above the presence
bit for anOptionalThing always being zero.
Likewise, would this:
Child ::= Parent WITH COMPONENTS { ..., anOptionalThing PRESENT }
result in this new type:
SEQUENCE
{
anOptionalThing INTEGER,
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
No. It would, however, result in the presence bit for anOptionalThing
always being set to 1.
BTW, WITH ... } should be in parentheses.
-
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
Re: [ASN.1] Blaming ASN.1
On Mon, 1 Jul 2002, Will Bamberg wrote: One thing of interest that surfaced as a result of this close examination is that ASN.1, XML Schema and other similar notations possess similar implementation pitfalls that programmers need to pay close attention to. For this reason, the ITU-T will shortly be making available a document that makes suggestions on things that writers of network application programs should look out for. It sounds like this would be an interesting read. Do you have any details on where I could get this from, or find out when it becomes available, apart from periodically trawling http://www.itu.int/home/index.html? The URL will be posted to this list when it becomes available later this month. Bancroft
Re: [ASN.1] characterString valid set
On Mon, 3 Jun 2002, Edmond G wrote: Hello, In X.680, Table 3 defines the valid char set for each restricted char set. For some of these there are tables which define the valid character set such as NumericString (table 4) or PrintableString(table 5). And there are some other which are defined in a crypted way such VideotexString, GraphicString etc. So I have problem to find the appropriate valid set as defined in table 3 (All G,C sets, register number (?)1 ,156...). Where can I find documents which describes these sets?? As stated in Table 3, The defining registration numbers are listed in 'ISO International Register of Coded Character Sets to be used with Escape Sequences'. You can purchase that document from ISO. - 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
Re: [ASN.1] Is PER unaligned always unaligned?
On Tue, 19 Mar 2002, Ed Day wrote: Hi, There seems to be some question among some groups that we have dealt with whether PER unaligned is always unaligned. It would seem to me that clause 7.7 is quite clear on this point that padding bits are never inserted, It is true that padding bits are never inserted in the case of PER unaligned, except in one case. See X.691 clause 10.1 where it makes it clear that padding bits are inserted when the encoding is that of the outermost type. In other words, when the entire message has been encoded, pad bits are added if needed to have the completed message end on an octet boundary. This also applies to the contents of an open type, which is always encoded in PER as if it were a complete message. but others we have dealt with claim the note in clause 16 on OCTET STRING's indicates padding bits should be inserted because it does not discern between aligned and unaligned forms. It simply states that Octet strings of fixed length less than or equal to two octets are not octet aligned. All other octet strings are aligned. etc... In the above you are pointing to the tutorial note at the top of clause 16, Encoding the octetstring type, which is simply meant to give a tutorial summary of what the clause covers in depth. Please read the normative text - the body of clause 16. Note that it consistently speaks of addition of the octet string value to either the field-list as a bit-field or an octet-aligned bit-field. Once the field-list has been fully created, the fields within it are concatenated with or without padding to form the complete encoding, as specified by clause 10.1. Clause 10.1.2 makes it clear that for the UNALIGNED variant of PER no padding ever occurs, except for the encoding of the outermost type itself. It is also useful to read the definition of field-list in clause 3.7.12, as well as the clarifying note attached to it. This clause makes a clear distinction between adding an encoding into the field-list as either aligned or unaligned, and creation of the complete encoding where pad bits are or are not inserted, as specified by clause 10.1 - 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
Re: [ASN.1] Is PER unaligned always unaligned?
uOn Tue, 19 Mar 2002, Ed Day wrote:
Hi Bancroft,
I'm still a bit confused. The one line that I'm not quite sure of is the
following:
This also applies to the contents of an open type, which is
always encoded in PER as if it were a complete message.
So, for example, let's say I have the following type:
MyType ::= SEQUENCE {
a BOOLEAN,
b TYPE-IDENTIFIER.Type
}
and let's say we have encoded a boolean TRUE value for the open type field
which I believe would be:
00011 xxx
length valuepadding
So would the final encoding now look like (assuming TRUE for the first
boolean):
1000 11xx xyyy
^ length ^
! value2
value 1
x = inner type padding
y = outer type padding
Yes.
Or would alignment be done before the open type is added to the message:
1yyy 0001 1xxx
No. The alignment is applied to the encoded *contents* of the open type
regardless of whether PER ALIGNED or UNALIGNED is in use. There is no
alignment of the open type itself in the case of PER UNALIGNED.
Or am I missing something?
And as far as clause 16 is concerned, would OCTET STRING's ever be aligned?
Since clause 10.1 stipulates that no padding ever occurs, except possibly
at the end of complete encodings, the encoding of no type (including OCTET
STRING) is ever aligned in the case of PER UNALIGNED.
Bancroft
Regards,
Ed
- Original Message -
From: Bancroft Scott [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, March 19, 2002 4:58 PM
Subject: Re: [ASN.1] Is PER unaligned always unaligned?
On Tue, 19 Mar 2002, Ed Day wrote:
Hi,
There seems to be some question among some groups that we have dealt
with whether PER unaligned is always unaligned. It would seem to me
that clause 7.7 is quite clear on this point that padding bits are
never inserted,
It is true that padding bits are never inserted in the case of PER
unaligned, except in one case. See X.691 clause 10.1 where it makes it
clear that padding bits are inserted when the encoding is that of the
outermost type. In other words, when the entire message has been encoded,
pad bits are added if needed to have the completed message end on an octet
boundary. This also applies to the contents of an open type, which is
always encoded in PER as if it were a complete message.
but others we have dealt with claim the note in clause
16 on OCTET STRING's indicates padding bits should be inserted because
it does not discern between aligned and unaligned forms. It simply
states that Octet strings of fixed length less than or equal to two
octets are not octet aligned. All other octet strings are aligned.
etc...
In the above you are pointing to the tutorial note at the top of clause
16, Encoding the octetstring type, which is simply meant to give a
tutorial summary of what the clause covers in depth. Please read the
normative text - the body of clause 16. Note that it consistently speaks
of addition of the octet string value to either the field-list as a
bit-field or an octet-aligned bit-field. Once the field-list has been
fully created, the fields within it are concatenated with or without
padding to form the complete encoding, as specified by clause 10.1.
Clause 10.1.2 makes it clear that for the UNALIGNED variant of PER no
padding ever occurs, except for the encoding of the outermost type itself.
It is also useful to read the definition of field-list in clause 3.7.12,
as well as the clarifying note attached to it. This clause makes a clear
distinction between adding an encoding into the field-list as either
aligned or unaligned, and creation of the complete encoding where pad bits
are or are not inserted, as specified by clause 10.1
-
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
Re: [ASN.1] octet-aligned empty character string using PER
On Wed, 13 Mar 2002, Paul Long wrote: I'm writing a PER library (for the second time). Got a question about character strings. If a string is supposed to be octet-aligned but has length 0, is nothing supposed to be encoded at the next octet boundary? IOW, is there supposed to be zero padding out to the next octet boundary if not already at an octet boundary? I'm guess that we just forget the whole octet-boundary thing if the length is 0 and not encode anything for the string itself (of course) or even do any padding. How is the type constrained? If there is no subtype constraint, the length is encoded on an octet boundary. If there is a constraint, then it depends on the constraint as to whether alignment of the length takes place. If the constraint would typically result in alignment on an octet boundary of the data and it is length 0, clause 10.9.3.3 states: NOTE 2 - The effect of making no addition in the case of n equals zero is that padding to an octet boundary does not occur when these procedures are invoked to add an octet-aligned-bit-field of zero length, unless required by 10.5. - 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
Re: [ASN.1] ANY
On Tue, 5 Mar 2002, Bujji krishna R B wrote:
Hello,
I would like to know if the following ASN.1 construct a valid one.
X ::= SEQUENCE {
id1 OBJECT IDENTIFIER,
id2 OBJECT IDENTIFIER,
parameters1 ANY DEFINED BY id1 OPTIONAL,
parameters2 ANY DEFINED BY id2 OPTIONAL
}
No. It is invalid not only because of the ambiguity of
parameters1/parameters2, but because ANY has not been part of the ASN.1
standard for eight years now, and the 1988 standard which defines it -
X.208, is scheduled for withdrawal this year upon publication of
ASN.1:2002.
Since both ANY fields are OPTIONAL, do we need to have context specific
TAGS for ANY.
Correct. The tag could be PRIVATE or APPLICATION, but context-specific is
(IMHO) preferred.
-
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
Re: [ASN.1] Urgent : Doubt regd. Tagging issues in ASN.1 withoutthe help of any tool
On Wed, 31 Oct 2001, Parag wrote:
MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::= BEGIN
MegacoMessage ::= SEQUENCE
{
authHeader AuthenticationHeader OPTIONAL,
messMessage
}
AuthenticationHeader ::= SEQUENCE
{
secParmIndexSecurityParmIndex,
seqNum SequenceNum,
ad AuthData
}
SecurityParmIndex ::= OCTET STRING(SIZE(4))
SequenceNum ::= OCTET STRING(SIZE(4))
AuthData ::= OCTET STRING (SIZE (12..32))
Message ::= SEQUENCE
{version INTEGER(0..99),
-- The version of the protocol defined here is equal to 1.
mId MId,-- Name/address of message originator
messageBody CHOICE
{
messageErrorErrorDescriptor,
transactionsSEQUENCE OF Transaction
},
...
}
END
The above ASN.1 partial structure is specified for MEGACO. We are
implementing encoding and decoding in BER without the help of any tool
or compiler. We are stuck with the Tagging issues. Kindly specify the
solution and how the tagging is to be carried out for the above
substructure without the help of any tool or compiler.
Why on Earth would you want to do such a thing? There are a lot of
excellent ASN.1 toolkits available, ranging from freeware to industrial
strenth tools. See http://asn1.elibel.tm.fr/en/links/index.htm#tools for
a list of some of them.
Anyway, the module below was generated by using the OSS ASN.1 compiler
-list option. Do yourself a favor and use an existing tool; you will
get to market faster and with a lot fewer bugs.
MEDIA-GATEWAY-CONTROL
DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
MegacoMessage ::= SEQUENCE {
authHeader [0] AuthenticationHeader OPTIONAL,
mess [1] Message
}
AuthenticationHeader ::= SEQUENCE {
secParmIndex [0] SecurityParmIndex,
seqNum [1] SequenceNum,
ad [2] AuthData
}
SecurityParmIndex ::= OCTET STRING (SIZE (4))
SequenceNum ::= OCTET STRING (SIZE (4))
AuthData ::= OCTET STRING (SIZE (12..32))
Message ::= SEQUENCE {
version [0] INTEGER (0..99),
mId [1] MId,
messageBody [2] EXPLICIT CHOICE {
messageError [0] ErrorDescriptor,
transactions [1] SEQUENCE OF Transaction
},
...
}
ErrorDescriptor ::= INTEGER
Transaction ::= INTEGER
MId ::= INTEGER
END
-
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
Re: [ASN.1] open type field encoding
On Sat, 2 Feb 2002, naoki hashimoto wrote:
Hi All,
My question is regarding PER encoding of open type field to be NULL
type.
Is myvalue encoded as follows( in aligned PER )?
0x00 0x01 0x02
0x00 : lenght of open type field encoding
0x01 0x02 : INTEGER value encoding
NULL encodes to no bits. However, X.691 clause 10.1.3 which talks
about how to produce a complete encoding states:
[...]
If the result of encoding the outermost value is an empty bit string,
the bit string shall be replaced with a single octet with all bits set
to 0.
[...]
NOTE - The encoding of the outermost value is the empty bit string if,
for example, the abstract syntax value is of the null type or of an
integer type constrained to a single value.
and X.691 clause 10.2.1 which talks about how to encode an open type
states:
In order to encode an open type field, the value of the actual
type occupying the field shall be encoded to a field-list which shall
then be converted to a complete encoding specified in 10.1 to
produce an octet string of length n (say).
In other words, 10.2.1 is saying that first you encode the value of the
actual type, which in this case is NULL. Since NULL always encodes to
zero bits, you will end up with zero bits at this point in the encoding
process. However, 10.2.1 then goes on to say that the value shall next be
encoded to a field-list which then gets converted into a complete
encoding, and as you can see in 10.1.3, if the result of encoding the
outermost value (in this case, NULL) is an empty bit string, the bit
string gets replaced with a single octet of 0. Thus, the encoding you
show above is incorrect, and the correct encoding is:
0x01 0x00 : open type encoding of NULL:NULL
0x01 0x02 : INTEGER value encoding
-
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
NULLSETTING DEFINITIONS AUTOMATIC TAGS ::= BEGIN
myvalue DefMsg ::={
msgtype NULL:NULL,
msgid2
}
-- ***
-- Message
-- ***
DefMsg ::= SEQUENCE{
msgtype DEFCLASS.Open ({ObjSet}{@msgid}),
msgidDEFCLASS.id({ObjSet})
}
-- ***
-- information object class
-- ***
DEFCLASS ::= CLASS
{
Open,
id INTEGER UNIQUE
}
WITH SYNTAX
{
OPENOpen
ID id
}
-- ***
-- information object set
-- ***
ObjSet DEFCLASS ::= {
objfirst | objsecond, ...
}
objfirst DEFCLASS ::= {
OPENBOOLEAN
ID 1
}
objsecond DEFCLASS ::= {
OPENNULL
ID 2
}
END
Thanks for all
Naoki Hahsimoto
[EMAIL PROTECTED]
Re: [ASN.1] Regarding CSN.1
On Tue, 22 Jan 2002, Parichaya_Shrivastava wrote: Hi all, Can please someone give me some pointers about CSN.1 as well as some information regarding its (CSN.1) compilers ? Sorry for the inconvenience as this may not be right forum to ask this question but I could not gather much info and hence this mail. CSN.1 has nothing to do with ASN.1. If you need to describe an existing binary encoding and you are unable to use BER or PER, then consider using the Encoding Control Notation of ASN.1 (ECN). ECN is also excellent for cases where you wish to create specialized binary encodings that are not covered by BER or PER. See http://asn1.elibel.tm.fr/en/ecn/index.htm for a brief intro to ECN. - 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
Re: [ASN.1] Question on TAGS
On Thu, 3 Jan 2002, Bujji krishna R B wrote: Hello, I would like to know ,how the tags for the following are enoded in BER. X ::= [0] EXPLICIT [1] IMPLICIT INTEGER Y ::= [0] IMPLICIT [1] EXPLICIT BOOLEAN Am I correct , if the tag for X is encoded as [0] [1] and the universal tag of INTEGER is not encoded here because of the IMPLICIT key preceding it. Yes. and the tag for Y is encoded as [0] because IMPLICIT restricts other tags following it to be encoded. Y is encoded as [0] and the universal tag for BOOLEAN. - 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
Re: [ASN.1] What does 'WITH COMPONENTS' mean ?
On Thu, 27 Dec 2001, ASN Dev wrote:
Hi:
I am a ASN.1 newbie and trying to understand the
following ASN.1 declaration
EMBEDDED PDV (WITH COMPONENTS { ...,
identification (WITH COMPONENTS { ...,
presentation-context-id ABSENT,
context-negotiation ABSENT }) })
How do I interpret 'WITH COMPONENTS' in the above
declaration ? What exactly does 'WITH COMPONENTS' imply ?
Thanks for your time in advance.
Given: The EMBEDDED PDV type contains three components - identification,
data-value-descriptor and data-value.
In WITH COMPONENTS the presence of the sequence of the characters {
..., immediately after WITH COMPONENTS (space not being significant)
effectively states that what follows is an assertion on whatever
component(s) are explicitly listed in the constraints, and that no
assertion is being made on any component not explicitly listed. For
example, in the above constraint on EMBEDDED PDV, the outer WITH
COMPONENTS is an assertion on the value of identification, and is
silent on the value of data-value-descriptor and data-value.
The assertion being made on identification is itself a WITH COMPONENTS
constraint. You can read it as saying - As far as this constraint goes
there is no restriction on 'identification', with the exception that the
components 'presentation-context-id' and 'context-negotiation' MUST be
absent in all values of 'identification'.
What exactly does 'WITH COMPONENTS' imply ?
It imposes a constraint on the components of a previously defined SET,
SEQUENCE or CHOICE type, or on a type derived from these, such as EMBEDDED
PDV.
-
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
Re: [ASN.1] ASN.1 and decoding
On Fri, 28 Dec 2001, Sergio Da Silva wrote: Hello, I am just starting in the world of ASN.1 and am trying to figure out how to go about decoding a file that was encoded using Basic Encoding Rules as specified within ITU Rec. X.690 or ITU Rec. X.209. I have little knowledge of ASN.1 and basic knowledge of programming languages such as C, Perl and Java. 1) Are there any specific tools that can solve this problem, if possible free (as in speech) ones? 2) As I have understood so far, tools like snacc provide ways to decode the above mentioned files: does there exist a tutorial or a howto about doing this. 3) More questions will rise as time goes by ... For now I will greatly appreciate any feedback on the subject that will help me getting started. A bunch of tools are listed at http://asn1.elibel.tm.fr/en/links/index.htm#tools - 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
Re: [ASN.1] Dynamic ObjectSets
On Mon, 19 Nov 2001, John Birrell wrote:
G'day,
If I have ObjectSets 'A', 'B' and 'C' defined:
A SOMECLASS ::= { a1 | a2 | a3, ... }
B SOMECLASS ::= { b1 | b2 | b3, ... }
C SOMECLASS ::= { A ^ B }
I understand that ObjectSet 'C' inherits the dynamic
nature of 'A' and 'B'. Does this mean that the Objects
in ObjectSet 'C' can only be determined at runtime
(in order to allow for Objects being added to, or
deleted from, the ObjectSets 'A' and 'B')?
Yes.
-
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
Re: [ASN.1] asn specification
On Thu, 25 Oct 2001, Ed Day wrote: We have dealt with this problem and others like it using the infamous lex tie-in that is prevalent in the SNACC code. That is to say swallow the whole thing up and deal with it on the back end essentially emulating multi-token look aheads. It isn't pretty, but it works. Agreed. Any number of tools cope fine with the BNF as it is, I don't see the need for a change. Remember that ASN.1 is not LR(1). Bancroft
Re: [ASN.1] Encoding of REAL values
On Wed, 24 Oct 2001, Sathya[IT] wrote: Hi, Can anyone please explain how to encode a REAL value of 3.14 in ASN.1 BER? You really need to read the documentation, or you are extremely likely to end up with a buggy implementation. You can either spend the time and do the proper research now, or spend the time patching and repatching a very buggy implementation. Two very good books on ASN.1 can be freely downloaded from: http://www.oss.com/asn1/booksintro.html You can download the actual ASN.1 standards for free from: http://www.itu.int/ITU-T/studygroups/com17/languages/index.html - 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
Re: [ASN.1] PER encoding/decoding help
On Thu, 4 Oct 2001, C. Wayne Buhrman wrote: Hello! In an attempt to learn Basic Aligned PER encoding/decoding, I am looking at the T38 example in the OSS ASN compiler. The t38.h file is not present, which precludes being able to compile and run the example. Where can I get t38.h so I can run the example and learn the encoding/decoding methodology? Send tool-specific queries to the tool vendor. In this case, [EMAIL PROTECTED] We provide tech support 24 hours a day, 7 days a week. You will get a response shortly from OSS support. - 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
Re: [ASN.1] Assignment of an IntegerValue
On Mon, 17 Sep 2001, Egon Andersen, Talura wrote:
I've been looking at the following construction.
---
alpha INTEGER { a (1) } ::= 3
beta INTEGER { alpha (7) } ::= alpha
---
What is the value of beta? 3 or 7? 'alpha' can be regarded as both a
DefinedValue and an identifier. Both types are defined with different
named values and different names for named values. I can't see that
any rule is violated. Nor any rules saying which of the two values is
assigned to 'beta' I'm specially looking at X.680 (1997 E) clause
18.10 (including NOTE) and X.680 (1997 E)/Amd.2 (1999 E) clause F.4.5
The answer is that beta is 7, same as you would get for
alpha INTEGER { a (1) } ::= 3
Foo ::= INTEGER { alpha (7) }
beta Foo ::= alpha
We will clarify this in ASN.1:2002.
-
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
Re: [ASN.1] PER, Sequence OPTIONAL extensions
On Fri, 27 Jul 2001, Benoit POSTE wrote:
Thank you very much Mr. Scott for resending you e-mail.
So, just to get this straight (last question, I promise!), if
I understood well:
Toto ::= SEQUENCE {
one BOOLEAN,
...,
two BOOLEAN OPTIONAL,
three BOOLEAN OPTIONAL,
fourBOOLEAN OPTIONAL
}
A value with one set to true and all other components absent
will be encoded:
0 no addition value present
1 encoding of one
011 number of additions in the type (small whole number 3)
000 additions presence bitmap
Am I correct? If so, it is a good thing I asked, I think I had
it wrong.
No, not correct. If no extension addition value is present then the
encoding is (produced by OSS ASN-1Step utility):
ossPrintPER output...
value Toto ::=
{
--TYPE INFORMATION: SEQUENCE
--OFFSET: 0,0
--extension flag: .0
one TRUE
--TYPE INFORMATION: BOOLEAN
--OFFSET: 0,1; LENGTH: 0,1
--contents: 1
}
--PDU padding: 00
--TOTAL LENGTH: 1,0
Simply put, the encoding is:
0 no addition value present
1 encoding of one
00 PDU padding
Here it shows what X.691 clause 18.6 says - that once the extension
root has been encoded the type is fully encoded.
Similarly:
Toto ::= SEQUENCE {
one BOOLEAN,
...
}
Would be encoded:
0 no addition value present
1 encoding of one
000 number of additions in the type (small whole number 0)
(no additions presence bitmap)
Right?
No. The encoding would be *exactly* as shown above. That is:
0 no addition value present
1 encoding of one
00 PDU padding
Bancroft
Again, thanks a lot for patience and your time.
Benoit Poste.
Bancroft Scott wrote:
On Wed, 25 Jul 2001, Benoit POSTE wrote:
X.691 clause 18.1 is abundantly clear on this:
... The bit shall be one if values of extension
additions are present in this encoding, and zero
otherwise
What is the source of your confusion as to how the SEQUENCE
should be encoded? It is clear to me.
Oh all right, so present of the additions is to be taken in the
OPTIONAL/DEFAULT sense. I only have the French version of X.691 and in
French it either meant present as in OPTIONAL/DEFAULT, or possess
(from the type's point of view).
No, it hasn't anything to do with OPTIONAL/DEFAULT or with anything from
the type's point of view. It speaks of *values* of encoding additions.
That is, it is a matter of whether the extension addition values are
actually present that determines if the extension bit at the front of
the SEQUENCE is to 1.
... Ce bit doit être mis à 1 si ce codage contient des
valeurs d'adjonction d'extension ...
Which literally could mean:
... The bit shall be one if this encoding contains
extension additions ...
I guess I am just going to get the English version too.
However, 18.7 uses the words number of extension additions to
encode so ...
Look again at 18.7. It says number of extension additions in the type
being encoded. Here it is referring to the type notation, not the actual
value.
I was beginning to wonder if it meant number of
additions, whether present or not. Of course, one could argue
that encoding an all 0 presence bitmap is rather pointless, but
one benefit is that it tells the receiver the encoder's version.
Hence my confusion about the way to encode it.
It would be nice if you were to show us which comment you
are referring to instead of having everyone spend their time
trying to figure out which of Mr. Andersen's emails you are
referring to.
snip
Re: [ASN.1] PER, Sequence OPTIONAL extensions
On Thu, 26 Jul 2001, Egon Andersen, Talura wrote:
Bancroft Scott wrote:
[snip]
Or in other words: we have no direct way to say that
mandatory components in first ExtensionAdditionGroup must
be present, if we have components from the second
ExtensionAdditionGroup.
This could be handled if ASN.1 allowed the following
pseudo-notation:
[[ Addition1, [[Addition2]] ]]
Egon is mistaken. X.680 clause 24.14 makes it clear that in a value
mandatory components in the first ExtensionAdditionGroup must be present
if components from the second ExtensionAdditionGroup are present.
Yes I was mistaken, 24.14 specifies exactly that. But then we have no
possibility to say that either first ExtensionAdditionGroup or second
ExtensionAdditionGroup (or both) must be present! Which was actually the
first impression I got from the BNF-notation.
I have an additional question related to this, actually 24.14 Note 2.
John Larmouth wrote as a reply to Ed Day:
I am afraid you have got this one the wrong way round. Without version
brackets, each line of the additions is treated as if it has been added
in a new version, and encodes exactly the same as if it had version
brackets round each line.
Correct.
This I interpret to mean that the following two constructions are
'equal':
A ::= SEQUENCE{
alpha Alpha,
...,
beta Beta,
gamma Gamma}
B ::= SEQUENCE{
alpha Alpha,
...,
[[beta Beta]],
[[gamma Gamma]]}
Correct.
If not relayed, Note 2 says that all parts of A (Alpha, Beta and Gamma)
should be encoded.
Correct.
Note 1 says that we can select to encode only parts of B that is either
Alpha, or Alpha and Beta, or Alpha and Beta and Gamma.
No, note 1 says that if an encoding contains gamma then it must also
contain beta since beta is not marked OPTIONAL or DEFAULT.
S reading Note 1 and 2 I see A and B as beeing quite different.
Do I misinterpret John Larmouth's statement or do I misinterpret 24.14
Note 2 or ?
You misinterpret note 1.
-
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
Re: [ASN.1] PER, Sequence OPTIONAL extensions
On Wed, 25 Jul 2001, Benoit POSTE wrote: (I knew I should have written a I'll be back at the end of my last e-mail on this topic ...) Hello all. I know that I have already asked very similar questions a while ago ... unfortunately none seem to fit my current problem. If we consider a sequence type with a few extensions that are all OPTIONAL. Consider that we would like to PER encode a value where all these (OPTIONAL) extensions are non-present. What exactly do we encode? More precisely: - Is the extension preamble set to 0 or 1? - Consequently, are the enxtension bitmap length and the extension bitmap (all 0s) encoded at the end of the root encoding? Hoping that someone will be able to help me determine what is expected/tolerated/forbidden, thanks a lot all :). X.691 clause 18.1 is abundantly clear on this: ... The bit shall be one if values of extension additions are present in this encoding, and zero otherwise What is the source of your confusion as to how the SEQUENCE should be encoded? It is clear to me. Benoit Poste. P.S.: On a side note, Mr. Andersen had an interesting comment on this topic last time, but I couldn't see any reply ... or were the messages eaten by the big nasty mailing list software? It would be nice if you were to show us which comment you are referring to instead of having everyone spend their time trying to figure out which of Mr. Andersen's emails you are referring to. - 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
Re: [ASN.1] approach for asn.1
On Mon, 23 Jul 2001, Chitta Nithin wrote: Good afternoon all, I have joined this list recently. We are trying to develop java modules for encode/decode of RANAP(PER), MAP(BER) asn.1 messages. Can you give us some pointers to the approaches used for the above? Send email to [EMAIL PROTECTED] to find out about the OSS ASN.1 Tools for Java. It suports ASN.1:1997, BER, PER and DER, annd hence supports both RANAP and MAP. - 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
Re: [ASN.1] compatibility 94-97 vs 90
On Thu, 12 Jul 2001, Benoit POSTE wrote: Hello all. I had just a short question regarding compatibility. Someone told me not long ago that it was not illegal, for modules written in ASN.1 94 or 97, to import from modules written in ASN.1 90 or even 88. I find it a bit surprising. Could someone confirm/invalidate this? This is incorrect, as stated in X.680 Annex A. Thanks a lot :). Benoit Poste. P.S.: I may be mistaken, but it seems to me that the archives of the list (http://www.mail-archive.com/asn1%40oss.com/) are missing a few emails (not including the most recent ones of course). For instance [ASN.1] Use of ASN.1 in PKCS-15 has no reply listed, although at least one was made on the list. Anyone knows why? It is due to problems with our archive software. We are in the process of switching to a new mail and archive server that will resolve this problem. This switchover is expected to take place at the end of this month. - 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
[ASN.1] test msg
Re: [ASN.1] Non-uniqueness and component relation constraints?
On Sat, 7 Jul 2001, Olivier Dubuisson wrote:
I said in my earlier email that I could not think of a good reason to have
an information object set if the associated information object classs has
no identifier field. I have thought of a case where it makes sense,
though it is unlikely that anyone will ever write such ASN.1. The case is
when a component relation constraint references multiple components in a
message. In such case it is possible that while there is no single unique
field in the information object set, a combination of fields can be
unqiue. For example:
FOO ::= CLASS {
a INTEGER,
b INTEGER,
Type
}
Bar FOO ::= {
{a 1, b 1, Type BOOLEAN} |
{a 1, b 2, Type NULL} |
{a 2, b 1, Type IA5String} |
{a 2, b 2, Type REAL}
}
FooBar ::= SEQUENCE {
x FOO.a({Bar}),
y FOO.b({Bar}),
z FOO.Type({Bar}{@x, @y})
}
I don't see how this is different from Geoff's one-dimension example:
It is not because you use a two-dimension space that you desambiguate and
select only one information object in the set (the set can still contain
two objects with the same values in fields a and b).
I was not trying to highlight a difference; I was taking back the comment
that I previously made concerning the usefulness of information object
sets whose governing information object class has no identifier field.
-
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
Re: [ASN.1] Object Class Definations
On Thu, 5 Jul 2001, Andrew M. Schoka wrote: Is there a relationship between GDMO and ASN.1? A mapping perhaps? How could a project manage information when there is some information in one form and some information in the other? GDMO uses ASN.1 for its type notation. There is no mapping from one to the other per se. Hmmm ..., if one wanted one could for the most part redefine GDMO templates in terms of information object classes, but you can't redefine ASN.1 in terms of GDMO since GDMO has no typing mechanism of its own (it relies on ASN.1 for its typing). - 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
Re: [ASN.1] Object Class Definations
On Thu, 5 Jul 2001, Paul Thorpe wrote:
Hi,
These definitions look like the MACRO NOTATION from the obsolete 13 year
old 1988 X.208 standard. You will be far better off getting an updated
version of that specification that uses the 1997 notation described in
X.680, X.681,...
Paul and Olivier are right; I was wrong. I checked and this looks closer
to the ASN.1 macro notation than to GDMO. I say closer because, as
Olivier points out, the syntax is invalid ASN.1.
-
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
Paul E. Thorpe Toll Free: 1-888-OSS-ASN1
OSS NokalvaInternational: 1-609-987-9073
Email: [EMAIL PROTECTED] Tech Support : 1-732-302-9669
http://www.oss.com Fax : 1-732-302-0023
On Thu, 5 Jul 2001, Egon Andersen, Talura wrote:
[EMAIL PROTECTED] wrote:
Hi ,
I have come across the following ASN.1 syntax for object class
definations. Which asn.1 standard is this
explained in ??.
If there are other resources for this they are most welcome
Class:
alarmCountList M-OBJECT-CLASS
DERIVED FROM top
CHARACTERIZED BY
BEHAVIOR DEFINITIONS
ATTRIBUTES {
alarmCountListId GET
alarmCountInfoGET
}
OPERATIONS
CREATE with automatic-instance-naming
DELETE
NOTIFICATIONS
{
objectCreationReporting,
objectDeletionReporting,
eventReporting
}
OPTIONAL ATTRIBUTES {
EventReportControlPointers GET-REPLACE ADD-REMOVE
}
: = { mviObjectClass 303 }
Attribute Definition:
alarmCountInfo ATTRIBUTE
SET-VALUED
WITH ATTRIBUTE SYNTAX AlarmCountInfo
MATCHES FOR EQUALITY
: = { mviAttribute 1542}
alarmCountListId ATTRIBUTE
SINGLE-VALUED
WITH ATTRIBUTE SYNTAX INTEGER
MATCHES FOR EQUALITY
: = { mviAttirbute 1543 }
Praful
What you show us is objects - not the classes!
You can read about objects in X.681
Regards
Egon Andersen
--
* Talura ApS * Phone: +45 43 52 50 00 *
* Baldershøj 24 B * mailto:[EMAIL PROTECTED] *
* DK-2635 Ishøj * http://www.talura.dk *
Re: [ASN.1] BER/DER encoding of a Set
On Thu, 21 Jun 2001, Benoit POSTE wrote: Bancroft Scott wrote: snip I don't have X.680 handy at the moment, but if you check the docs you will see that SET requires that new extension additions MUST use tags that are canonically greater than any other existing tag in the SET, so the above is invalid ASN.1. That's what I'd really like it to be, for sure. Unfortunately here is what I got from 26.3 : 26.3 The ComponentType types in a set type shall all have different tags. (See clause 30.) The tag of each new ComponentType added to the AdditionalComponentTypeList shall be canonically greater (see 6.4) than those of the other components in the AdditionalComponentTypeList. I says the other components in the AdditionalComponentTypeList, and not any other component of the Set type ... :( Do you mean that greater than any other component in the SetType is what was meant in the first place? Of course it makes decoding and encoding quite a bit easier, but is it correct to interpret it that way? On the other hand, it could be my copy of the norm, but I thought 1997 was the latest ... Oops! You have detected a bug in the X.680, as AdditionalComponentTypeList is not even defined. I'm 99% certain I know the answer, but I'll check with the ITU-T | ISO/IEC ASN.1 Committee and get back to you. - 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
Re: [ASN.1] Tag value for SEQUENCE OF sequence_type
On Thu, 21 Jun 2001, Konduru, Chandra wrote:
Hi,
I have a question on SEQUENCE OF tagging.
I have the following ASN.1 BER definition:
MY_DEF DEFINITIONS IMPLICIT TAGS ::=
BEGIN
X ::= [15] SEQUENCE OF Y;
Y ::= SEQUENCE
{
a INTEGER;
b OCTET STRING;
}
END
In the above definition IMPLICIT global tagging is used.
My question is which tag I should use while encoding any element (i.e., of
type Y) in X.
Do I use context-specific tag 15 or universal tag for SEQUENCE?
[15] IMPLICIT applies only to X itself. Y is encoded using the universal
tag for SEQUENCE.
-
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
R: [ASN.1] Null Encoding in Extension Part
On 17 Apr 2001, manikandan meyyappan wrote: Hi, I have problem in NULL decoding. The extension elements in choice are encoded using open type. What is the procedure for encoding the NULL type which is coming under extension part? In one scenario the NULL is encoded as 0001 But in another scenario the NULL is encoded with no bits. I seen the second scenario in Netmeeting ReleaseComplete message by encoding the ReleaseComplete Reason as Security Denied. what is the actual procedure for Encoding the NULL type? NULL is always encoded with no bits. HOWEVER, X.691 clause 18.9 states that the extension addition value should be encoded as if it were an open type value, and clause 10.2.1 states that in producing the encoding of an open type value the contents of the open type must be encoded then must be converted into a complete encoding. So, the NULL value must first be encoded (producing no bits), then this encoding must be converted to a complete encoding. Clause 10.1.3 states that in producing the complete If the result of encoding the outermost value is an empty bit string, the bit string shall be replaced by a single octet with all bits set to 0. Hence, the only correct PER encoding for NULL when it is an extension addition value is the first scenario above ( 0001 ). If you are using the OSS ASN.1 Tools you can instruct the decoder to not treat the above mentioned invalid encoding (NULL encoded as an extension addition value with with no bits) as an error by setting the runtime flag RELAXPER. - 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
Re: [ASN.1] ragarding Rtp and Rtcp Port numbers
On Mon, 8 Jan 2001, Manikandan wrote: hi, Can any body help me to get the Rtp port number? I am not able to proceed in my project.I have the following doubts. 1. Port number standards says that the dynamic port numbers will start from 49152, but in Fast start decoding i am seeing that the rtp port number as 5000.Is it standard port number for faststart?. 2. I want to know ,all the h323 stacks will use the port number standard for assigning the dynamic port number for rtp(= 49152)? 3. Is there any standard,the Difference between RtpPort number and Rtcp Port number will always one? [EMAIL PROTECTED] is the wrong list for this sort of question. This lists deals with ASN.1-specific questions. You are more likely to get the help you seek if you send your query to [EMAIL PROTECTED] or [EMAIL PROTECTED] - 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
Re: [ASN.1] significance of OPTIONAL element in extension
On Thu, 26 Oct 2000, Olivier DUBUISSON wrote:
Rajmohan wrote:
I need a clarification in PER.
What is the significance of OPTIONAL element in extension?
eg: ASNSTRUCT::= SEQUENCE
{
nonStandardINTEGER,
extnA BOOLEAN,
extnB INTEGER (0..65535) OPTIONAL
}
Here, how to encode the extension elements in extension and with the OPTIONAL
bit?
This is described in the books:
[...] Each bit equals 1 if the corresponding extension is present in the
value (whether this extension is mandatory or marked OPTIONAL or DEFAULT), 0
otherwise.
Olivier answered your second question, but your first question was not
answered. Extension addition items are all "optional" for versions of
implementations in which those items are not defined (e.g., in version 1
of ASNSTRUCT extnA and extnB are not defined), but in versions of
implementations in which the extension additions are defined (e.g., let's
say extnA and extnB are defined in version 2) an extension addition item
which is not marked OPTIONAL is *mandatory* as far as that version goes,
and those items that are marked OPTIONAL are optional to that version.
Thus, if extnA and extnB above are defined in version 2 but not version 1,
a version 2 implementation is required to always transmit extnA *if it is
originating the message* because it is not marked OPTIONAL, but can omit
extnB. If it is not originating the message (e.g., it is forwarding a
message that was received from a version 1 implementation) then it is free
to omit extnA and extnB if it was not present in the message. An
implication of this is that you can never have extnB present in a message
if extnA is absent.
-
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
