[erlang-questions] asn1ct/asn1rt EXTERNAL 1990/1994 conversion information loss

[Harald Welte]

Hi Kenneth,

thansk a lot for looking into the issue and getting back to me.

On Wed, Apr 27, 2011 at 01:52:50PM +0200, Kenneth Lundin wrote:
 
> For good or bad we have once taken the decision to not introduce compiler
> options for chosing which ASN.1 standard 1990, 1994, 1997 etc. to use.
> Instead we try to support all reasonable constructs from these standards at
> the same time.

I'm not adamant of the compiler option.  In fact, a solution that
requires no explicit user/developer intervention is always preferred
to one that does.

> When it comes to the EXTERNAL type we allow input values both as a
> 5-tuple (1990) and as a 4-tuple (1994) and use the 5 tuple 1990 format for
> encoding as the standard recommends.

No complaint here.

> When decoding an EXTERNAL type this ends up as a 5-tuple  (1990) as
> you describe and we convert it "back" to a 4-tuple (1994) representation
> since otherwise a value using the 1994 4-tuple format would not yield the
> same value back when encoded and then decoded back again.

I don't really understand that part, but that's ok for me.

> The problem with this approach is as you also explain that some information
> possible present in the 1990 5 -tuple vesion get lost when converted to the
> 1994 4 -tuple format.

Indeed.

> I suggest an easy first step which might be sufficient since the
> EXTERNAL type in not recommended to be used at all any more 

The problem is that even in 20111 on the SS7 networks we still see stuff
encoded not only using old EXTERNAL types, but even stuff encoded in MAPv1,
specified against TCAP from 1988, using ASN.1 MACRO instead of information
object classes.

And even today, if you write software in 2011, you will want to have it
interoperate with those old implementations that at least some GSM operators
still use.

If you (or someone else on this list) is interested to read about how difficult
that really is, I recommend my blog posts at:
http://laforge.gnumonks.org/weblog/2011/03/26#20110326-parsing_dos_word_files_for_gsm_map
http://laforge.gnumonks.org/weblog/2011/03/27#20110327-parsing_more_word_files_for_gsm_map
http://laforge.gnumonks.org/weblog/2011/04/09#20110409-follow_up_on_gsm_map
http://laforge.gnumonks.org/weblog/2011/04/12#20110412-mapv1_available

So as indicated, the 1990/1994 EXTERNAL type difference is only the smallest
of all issues - and it is my belief that for years to come we will still see
the need for supporting it in a graceful manner.

> is to continue with the same conversion upon decode but only convert to 1994
> 4-tuple format when this can be done without information loss i.e. only when
> the "encoding" component is {octet-aligned, Octets}.

Makes a lot of sense.

> This will result in that a 4-tuple (1994) or a 5-tuple (1990) value can be
> returned from decode and that encode will accept both of these formats as
> well.

I think it is a great solution to the problem.

> This will only require a one-liner change in asn1rt_check.erl (plus
> the documentation of course)
> You can try it if you want.

Thanks, I will try it at the next convenient time.

Regards,
	Harald
-- 
- Harald Welte <laforge@REDACTED>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)