> I hadn't because I didn't know about it. I've had a quick look. It
> looks way too heavy for our purpose.

Can be... though I wonder if people have other opinion.

> In specific, it's schema based and ascii encoded.

What do you mean by "ascii encoded" (do you refer to encoding rules in
ASN.1?)

> It looks reasonable for canonical,
> inter-organizational message exchange but less appropriate for ad
> hoc communication between database client and server.

From what I've read, it is used in many (if not most of) telco
equipment/protocols. Personally I like the way the stuff is defined
and a possibility to use different encoding rules for it. I suspect
that we can also plug-in the idea of supporting multiple protocols and
automatic capability negotiation into it.

> Do you have any experience with it?

Only experimenting. We have planned to switch to ASN.1 in my previous
company as a language to specify wire protocol between PDAs and
server. But I have changed my job and I have no idea what's the state
of affairs there. The tool I have tested (quite expensive one, if I'm
not mistaken, $4,500 per license) generated quite simple code both in
C++ and Java (do not know anything about C#).

The generated code is going to be bigger compared to our current wire
protocol handler, but the good thing is that you do not need to edit
it - it's like with parse.y. However, it will add dependency on some
external library, I have forgotten about this issue when posting first
message. So, most likely you're right, it might be too heavyweight for us.

BTW, there is already a free implementation of ASN.1 parser
http://lionet.info/asn1c/, though only with Basic Encoding Rules (in
other words type-length-value), but Packed Encoding Rules support is
planned. Though no Java implementation, but other tools are there.

But if nobody has practical experience in ASN.1, I think we have to
forget about it anyway.

Roman