classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view


Christofer Dutz
Hi Mike,

But I definitely need to re-do the documentation.

I had started writing it before I did a big extension and refactoring …
I really hope I finally will get the chance to work on this again very soon.


Von: "Beckerle, Mike" <[hidden email]>
Datum: Mittwoch, 30. Oktober 2019 um 17:32
An: Christofer Dutz <[hidden email]>, Julian Feinauer <[hidden email]>, "[hidden email]" <[hidden email]>
Betreff: Re: ASN.1 ECN


Thanks for this. Very useful. When I look at that  ASN.1 ECN definition I have the same reaction to it that I'm sure many non-XML people have to XML Schema and DFDL, which is there is much to learn, and so little of it seems relevant to the immediate problem. As soon as a description gets complex enough, it starts to lose its declarative value.

I think intellectually, we need to find a small, but representative piece of data and schema that has what you refer to as the "parsing semantics" of the message - the interesting calculations that are fundamental to really expressing *all* of the format information.  Then we need to express it in DFDL and in ASN.1 ECN best we can so we can have a side-by-side comparison that is really helpful.

What is the smallest, simplest format that you have seen that you think represents this? Do you have a description of it in MSpec as yet?


Mike Beckerle

From: Christofer Dutz <[hidden email]>
Sent: Saturday, October 26, 2019 9:42 AM
To: Julian Feinauer <[hidden email]>; [hidden email] <[hidden email]>
Cc: Beckerle, Mike <[hidden email]>
Subject: Re: ASN.1 ECN

Hi Julian and others.

Yes I did have a look as ASN.1, however I had the impression that this only specifies the syntax of the packets themselves … it has no means to specify parsing semantics.

With MSpec we have the ability to also define these semantics … If we had used ASN.1 it would have generated models and parsers with every bit of information being included in the POJOs. When serializing we would have had to manually handle and prepare all the data.

For example the “implicit” fields … in MSpec we can say “headerLength is calculated by taking the total size in bytes, subtract the payload size in bytes and subract 2 more” with ASN.1 we would have had to do these caltulations ourselves.

Same with the discriminated types … here some data is implicity specified by the type itself (discriminators) … also the handling of optional fields and how to parse lists/arrays would have been challenging.

My evaluation might not have been 100% correct, but definitions like this did sort of scare me:


Von: Julian Feinauer <[hidden email]>
Datum: Samstag, 26. Oktober 2019 um 10:09
An: "[hidden email]" <[hidden email]>
Cc: "Beckerle, Mike" <[hidden email]>, Christofer Dutz <[hidden email]>
Betreff: Re: ASN.1 ECN

Hi Mike,

thanks fort he question which was also asked at ACEU, thus I’m bringing the discussion to the dev list.

Can you comment on that Chris? You did most of the evaluation.


Von: "Beckerle, Mike" <[hidden email]>
Datum: Samstag, 26. Oktober 2019 um 06:32
An: Christofer Dutz <[hidden email]>, Julian Feinauer <[hidden email]>
Betreff: ASN.1 ECN

For format description in PLC4X, did you consider ASN.1 Encoding Control Notation? This is an ISO standard. I have not used it, but it checks the boxes of being a standard, being a grammar + rich library of primitives annotated on it, etc.

If you did not consider it, or did and found it unsuitable, I'm interested in why.

...mike beckerle