|
Notes |
|
|
(0002322)
|
|
maxime
|
|
2015-05-22 08:45
|
|
|
As reported in other bug, the tool actually does not support UTCTime at all. |
|
|
|
(0002323)
|
|
maxime
|
|
2015-05-22 08:59
|
|
|
DATE-TIME has the following characteristics:
callTime DATE-TIME ::= "2000-11-22T18:30:23"
-> for the user it is a string of 20 characters
-> for the encoding, the standard defines the following transformations:
```
YEAR-ENCODING ::= CHOICE { -- 2 bits for choice determinant
immediate INTEGER (2005..2020), -- 4 bits
near-future INTEGER (2021..2276), -- 8 bits
near-past INTEGER (1749..2004), -- 8 bits
remainder INTEGER (MIN..1748 | 2277..MAX)}
```
(Due to Min/Max, the last case cannot be fully supported as it implies malloc)
And the rest of the encoding is:
```
DATE-ENCODING ::= SEQUENCE {
year YEAR-ENCODING,
month INTEGER (1..12), -- 4 bits
day INTEGER (1..31) -- 5 bits -- }
```
(TODO check TIME-ENCODING) |
|
|
|
|
|
Do you have the relevant standard?
DATE-TIME is not part of X.691 (PER) or X.680 (ASN.1). |
|
|
|
(0002364)
|
|
maxime
|
|
2015-07-01 13:58
|
|
|
|
|
|
|
Thanks for the document. My version of X-691 did not mention anything about date and time.
The new X-691 doc, paragraph 32(Encoding the time type, the useful time types, the defined time types and the additional time types) makes a reference to ITU-T Rec. X.680 | ISO/IEC 8824-1 and specically in property settings of the abstract values (par. 38.4).
My version of X.680 | ISO/IEC 8824-1 ((07/2002) does not contain any information for property settings.
Do you have a newer version of X.680 | ISO/IEC 8824-1?
|
|
|
|
(0002366)
|
|
maxime
|
|
2015-07-02 09:34
|
|
|
|
|
|
|
I attached a file which presents some possible solutions on this ticket and I would like some feedback from you. |
|
|
|
(0002368)
|
|
maxime
|
|
2015-07-02 14:38
|
|
|
I think option 1 covers our need (also include the -DIFF types, since positive/negative relative times are also useful).
The only drawback I see is that if these types are built-in the compiler, then they become an ASN.1 extension, don't they ?
(i.e. an ASN.1 grammar that would use them would not pass with a different compiler). In that case we should avoid, or allow the use with an explicit ExternalTypeReference, for example:
```
MyModule DEFINITIONS ::=
BEGIN
MyType ::= STDLIB.TIME-DIFFERENCE
END
```
I think external module references can be used without an IMPORTS clause. In that case the grammar would be OK provided that (1) ASN1SCC provides this "STDLIB" (or whatever name) module in a file (2) knows where to find it and include it in the compilation process whenever it is needed (but not always).
Does this make sense? |
|
|
|
|
|
According to my understanding (see also paragraph 14.5 from latest X.680 spec), the external module reference does not impose an implicit import.
So,
MyType ::= STDLIB.TIME-DIFFERENCE
is valid provided that there is a an import of TIME-DIFFERENCE from STDLIB.
Of course, if no other TIME-DIFFERENCE is defined or imported, the protocol designed can equivalently write
MyType ::= TIME-DIFFERENCE
My proposal is that we create an ASN.1 file for the date-time types (see attached file TSTDLIB.ASN.1).
We introduce a new command line argument e.g. -ITSTDLIB (i.e. include the TSTDLIB) that tells the compiler to include this file in the compilation process. The ASN.1 file will be embedded into the ASN.1 compiler as external resource, like the C and Ada run time library.
The protocol designer should make an import to TSTDLIB and then define his own type. For example, the DATE-TIME can be defined as follows:
MY-MODULE DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
IMPORTS DATE-ENCODING, DATE-TIME-ENCODING, TIME-OF-DAY-ENCODING FROM TSTDLIB;
DATE-TIME ::= TSTDLIB.DATE-TIME-ENCODING{TSTDLIB.DATE-ENCODING, TSTDLIB.TIME-OF-DAY-ENCODING}
-- or
DATE-TIME2 ::= DATE-TIME-ENCODING{DATE-ENCODING, TIME-OF-DAY-ENCODING}
END
What do you think? |
|
|
|
(0002372)
|
|
maxime
|
|
2015-07-06 13:06
|
|
|
Agreed, this seems to be a very good option.
I am not sure that you need to import STDLIB if you refer to STDLIB.TIME-DIFFERENCE but I would need to check the standard again.
Also, -I in compilers is usually a flag to secify the path to the files, not the name of the file.
So if the module contains IMPORTS .... FROM TSTDLIB
then you only need to give the path where TSTDLIB.asn is. (-I/path/to/stdlib)
For the rest, no objection! |
|
Mantis 0000417.docx (15,800) 2015-07-02 14:10
TSTDLIB.ASN1 (13,138) 2015-07-06 10:45