The AVA class should conform to the follow rules when decoding and encoding the string representation of an AVA:
- Ava.valueOf(string).toString() should always preserve the original user provided representation. In particular, if the user provided an unusual attribute name during parsing, then it should be kept in the encoded string representation. Likewise, the original encoding of the attribute value should be preserved - LDAP, legacy (hex), or BER
- when an AVA is constructed then we should take care to follow the rules defined in RFC 4514 section 2.3 and 2.4:
- if the attribute name is numeric then attempt to BER encode the value
- if the attribute name is unrecognized then assume that the value is human-readable and encode it as a string
- if the attribute name is recognized then encode it as a string or BER depending on whether its syntax is human-readable.
There are a number of bugs at the moment:
- BER values are not decoded correctly: instead of parsing them as ASN.1 they are simply decoded as HEX. Likewise for encoding of BER values
- the original representation of attribute values is not preserved. The toString() method encodes octet-string values as UTF-8 strings, unless the attribute name is a numeric OID
- unrecognized attribute types are treated as octet string syntax requiring the octet string syntax to be flagged as human readable in order to cope with the common case
- unrecognized attribute types whose name is a numeric OID are decoded as a placeholder attribute type whose numeric OID has the string "-oid" appended.