On 02/27/2013 03:28 AM, Andreas Färber wrote:
Am 27.02.2013 00:03, schrieb jsch...@linux.vnet.ibm.com:
[snip]
I wrote an ASN.1 implementation once, and it seems to me you are mixing
up ASN.1 and BER here in your enum/array/... naming. The types are
general ASN.1 concepts and apply to other encodings as well, no?
What 'naming' are you referring too?
For me this is also a while back when Michael Tsirkin and I wrote the
code... some time in 2nd half of 2011.
Also I remember that BER has disjoint CER and DER flavors that I don't
see your output visitor distinguishing on brief sight, only P/C.
We do support definite length form of DER and the indefinite length
encoding form of CER.
Input visitor ideally handles both fine.
It does. The output visitor has to be configured with a flag choosing
either one of the types of output (CER/DER).
ASN.1
- textual
- BER
- CER
- DER
- PER (?)
- XER
While XER being XML-based just like the textual ASN.1 notation is
everything but efficient for transmission, keeping our options open to
implement either of these later for debugging purposes (e.g., verifying
VMState format) would be nice.
At least XER will require a separate implementation. I am not so
familiar with PER except that it produces a 'packed' encoding.
Stefan
