neon is intended to be compliant with the IETF and W3C standards which it implements, with a few exceptions due to practical necessity or interoperability issues. These exceptions are documented in this section.
neon is deliberately not compliant with section 23.4.2, and treats property names as a (namespace-URI, name) pair. This is generally considered to be correct behaviour by the WebDAV working group, and is likely to formally adopted in a future revision of the specification.
There is some confusion in this specification about the
        use of the “identity”
        transfer-coding.  neon ignores the
        Transfer-Encoding response header if it
        contains only the (now deprecated) “identity”
        token, and will determine the response message length as if
        the header was not present.  neon will give an error if a
        response includes a Transfer-Encoding
        header with a value other than “identity” or
        “chunked”.
neon parses and handles scoped IPv6 link-local literal
        addresses passed to ne_session_create since version
        0.34, following the syntax in RFC 6874. An
        example host argument would be
        "[fe80::cafe%25eth0]" where
        "eth0" is the scope ID. Since RFC
        9110 does not reference the extended syntax of scoped
        IPv6 literals, and a scope ID has no meaningful interpretation
        outside of the client host, it is omitted from the
        Host header sent over the wire. So the
        example argument here translates to an HTTP/1.1 header field
        of Host: [fe80::cafe].
neon is not strictly compliant with the quoting rules
        given in the grammar for the Authorization
        header.  The grammar requires that the qop
        and algorithm parameters are not quoted,
        however one widely deployed server implementation
        (Microsoft® IIS 5) rejects the request if these parameters
        are not quoted.  neon sends these parameters with
        quotes—this is not known to cause any problems with
        other server implementations.
RFC 7616 predates RFC 9112 and uses conflicting language
        around URIs. neon uses the RFC 9112
        request-target in both the
        A2 grammar and the uri=
        parameter of the Authorization
        header. neon will accept (and resolve) any URI-reference in
        the domain= parameter for
        WWW-Authenticate response header
        field.
The neon XML parser interface will accept and parse
        without error some XML documents which are well-formed
        according to the XML specification but do not conform to the
        "Namespaces in XML" specification [REC-XML-names].  Specifically: the restrictions on
        the first character of the NCName rule are
        not all implemented; neon will allow any
        CombiningChar, Extender
        and some characters from the Digit class in
        this position.