BER/DER/CER are a family; BER is the Basic Encoding Rules which give a
bunch of encoder's options about the order of fields and different ways
of saying the same thing, and CER and DER are just two different levels
of canonicalisation, subsetting/constraining BER in order to make things
like cryptographic hashes of the encoded data semantically meaningful as
hashes of the logical value therein.
The encoding formerly known as LER is just DER with one liberalization: sets don't have to appear in a fixed order, which makes it problematic for canonicalization. In addition, it's a "private specification", as X.690 calls such things, of types not part of the international standard. There's a minor violation there too: the 5-bit type codes have different semantics depending on whether they are used for primitive (byte) or compound (sub-object) types, which I do in order to keep down the number of 2-byte type codes.
So "LER", to me at least, implies an ASN.1 encoding rule that writes
arbitrary ASN.1 values as Lisp, presumably as s-expressions!
Whereas what I think John is describing is more of a mapping from an
s-expression subset into a schemaless BER encoding with pre-assigned
type tags.
Maybe LER should be the name of the textual format we're developing, then. Except it will make Lassi's marketing iinstincts go ding-ding-ding-ding.