RFC 2119 makes it clear that requirements that use SHOULD are not optional and should be complied with unless there are specific reasons not to: "This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."

In order to conform to this document, specifications MUST NOT violate any requirements preceded by [S],
[S] Every W3C specification MUST:
1. conform to the requirements applicable to specifications,
2. specify that implementations MUST conform to the requirements applicable to software, and
3. specify that content created according to that specification MUST conform to the requirements applicable to content.
[S] If an existing W3C specification does not conform to the requirements in this document, then the next version of that specification SHOULD be modified in order to conform.
I think this ones are to do with bidi text
. [S] Protocols, data formats and APIs MUST store, interchange or process text data in logical order.
I think we should do this one.
. [S] The 'character string' definition of a string is generally the most useful and SHOULD be used by most specifications, following the examples of Production [2] of XML 1.0 [XML 1.0], the SGML declaration of HTML 4.0 [HTML 4.01], and the character model of RFC 2070 [RFC 2070].
[S] [I] Specifications and implementations SHOULD be designed in such a way as to not disallow the use of private use code points by private arrangement. As an example, XML does not disallow the use of private use code points
We meet the primary normalization requirement, these two may need thought.,br> [S] [I] A text-processing component that receives suspect text MUST NOT perform any normalization-sensitive operations unless it has first confirmed through inspection that the text is in normalized form, and MUST NOT normalize the suspect text. Private agreements MAY, however, be created within private systems which are not subject to these rules, but any externally observable results MUST be the same as if the rules had been obeyed.
[S] Specifications of text-based languages and protocols SHOULD define precisely the construct boundaries necessary to obtain a complete definition of full-normalization. These definitions MUST include at least the boundaries between markup and character data as well as entity boundaries (if the language has any include mechanism) and SHOULD include any other boundary that may create denormalization when instances of the language are processed.
[S] Specifications MUST document any security issues related to normalization.
[S] W3C specifications that define protocol or format elements (e.g. HTTP headers, XML attributes, etc.) which are to be interpreted as URI references (or specific subsets of URI references, such as absolute URI references, URIs, etc.) SHOULD use Internationalized Resource Identifiers (IRI) [I-D IRI] (or an appropriate subset thereof).
[S] W3C specifications MUST define when the conversion from IRI references to URI references (or subsets thereof) takes place, in accordance with Internationalized Resource Identifiers (IRI) [I-D IRI].
[S] Since specifications in general need both a definition for their characters and the semantics associated with these characters, specifications SHOULD include a reference to the Unicode Standard, whether or not they include a reference to ISO/IEC 10646.
[S] A generic reference to the Unicode Standard MUST be made if it is desired that characters allocated after a specification is published are usable with that specification.
[S] All generic references to Unicode [Unicode] MUST refer to Unicode 3.0 [Unicode 3.0] or later.
[S] Generic references to ISO/IEC 10646 [ISO/IEC 10646] MUST be written such that they make allowance for the future publication of additional parts of the standard. When referring to Part 1, they MUST refer to ISO/IEC 10646-1:2000 [ISO/IEC 10646-1:2000] or later, including any amendments.