Main findings:
- domain names, hostname, URIs and friends validation relies on existing python libraries that claim compliance with RFCs. Testing is done on common cases only, while a more accurate testing is currently not included.
- email address validation seems to be more restrictive that what should be in practice (e.g., user@<ipaddr> should be valid)
- There are no constraints on File fields
- Artifact and Map are currently able to automatically convert fields into correct types.
- The Specification requires at least one key to be present for many fields, but does not require a valid value (check what happens in json)
- Port numbers are allowed also for icmp, because the specification does not forbid this.
- IRI was not tested.
- Strict conformance does not allow to give IPv6Addr + Netmask. IPv4/6Net must be strictly be a network
- Features only accept Feature enum, and cannot initialize them from the corresponding string.
- ArrayOf accepts the same elements multiple times, because this is the default behaviour of list. OpenC2 did not give specific indication about this.
- IPv4 schema does not allow "x.y.w.z/32" with explicit indication of an IP address and the /32 prefix. The LS says about the prefix: "If omitted,  refers to a single host address." but does not forbids to use the "/32" prefix. Fixed the pattern to accept explicit indication of the "/32" addresses.
- According to common network practice, an IP network address should always include the prefix/netmask. The LS says a Connection should include "IP address range", so this implicitely demands for a prefix 		to be given. However, a single host address may be acceptable as well. Openc2lib strictly adhere to 		the network-biased convention to always give the prefix, but it also accepts ip addresses as input. The tests have been set to manage this issue.
- For the encoding of BinaryX, RFC 4648 says "Base 16 encoding is the standard case-insensitive hex encoding... ", which let to use both uppercase and lowercase alphabets. However, the LS says: "Note that the Base16 alphabet does not include lower-case letters." This does not seem compliant to RFC 4648, so openc2lib accepts both uppercase and lowercase letters but it only outputs uppercase letters. Since third parties examples use both notation, tests have been arranged to compare upper and lowercase versions.
- There are not indications about the usage of uppercase or lowercase digits for MAC addresses in the LS, and no constraints are posed by the IETF. openc2lib does not force either lowercase or uppercase, and reads both formats.
- UUID according to RFC 4122 should be output as lowercase, but both cases are acceptable. The tests use lowercase for comparison.
- How to merge responses from multiple actuators?
- How to respond to unmanaged encoding formats? What to use in the "to" field if no "from" is provided in the Message?
- 10 tests fail for bad commands, all releated to the use of special characters in the nsid or    object name. This is set in the json schema, but I did not see any indication about valid characters in the LS
-  The response in good/query_features_all.json does not conform to the definition 3.4.2.17 Version  that says the Version is Major.Minor version number. This file uses: "1.0-draft-2019-02" I removed the trailing "-draft-2019-02" e put the original file in the bad examples.
- Multiple extensions to the same field is not supported. This is motivated by the fact that it is difficult to compose a single response from different actuators (different extensions are likely to be managed by different actuators, because they are part of different profiles). According to the OpenC2 syntax, it is hard to mix multiple dialects in the same command/response.
	


