Home

Against DRM in W3C Recommendations

The Fatal Flaw in the EOT Submission

by Tom Lord, 19th September 2008

When you MUST NOT say "MUST NOT";
And you SHOULD NOT say "SHOULD NOT";
Because What You Really Mean is "MAY"

Introduction

The EOT proposal has many fine points over which there might arise the usual scuffling in a successful standards effort but it contains one set of requirements which make it so controversial as to call into question whether or not there can emerge any successful W3C Recommendation at all. For example:

"If the [EOT] font embedding bits do not provide permissions for embedding, the user agent shall not use the font."

and

"User Agents must validate that the page using the embedded font is within the list of URLs in the [EOT file's] RootString from which the embedded font object may be legitimately referenced."

These imply what is called in the careful, legalistic language of standards, "MUST NOT" (or perhaps "SHOULD NOT") requirements. The language of an approved Recommandation would read something like:

User Agents MUST NOT render using a font file whose embedding bits are set to 0.

If the EOT proposal were "weakened", the requirement might read, instead:

User Agents SHOULD NOT render using a font file whose embedding bits are set to 0.

The Rationale given for such a requirement would read something like:

If the embedding bits are set to 0, the user does not enjoy legal permission to render text using the font.

We argue in this paper that such a standard is ill-formed, particularly (but not exclusively) in the context of an international standards body such as W3C. Rather than "MUST NOT" or "SHOULD NOT", the Recommendation ought to read "MAY": the user agent MAY render even if the embedding bits or 0 or the root strings don't match.

That is, we argue that browser implementors MAY choose to interpret such things as embedding bits or root strings by not rendering with a font in some cases, but they are not obligated to do so nor are they to be expected to do so. They simply "MAY" rather than "MUST," or even "SHOULD".

Our argument here is short, simple, and (we claim) to the point. It requires scarecly more verbiage than this introduction:

"MUST NOT" Means "Will Fail to Interoperate Unless Does Not"

In an interoperability standard, the phrase "MUST NOT" is not an admonishment but a condition of interoperability. A standard that says implementations "MUST NOT _X_" (for whatever "X" happens to be) says that programs which do "X" will fail to interoperate with other programs using the same standard. The langauge "MUST NOT" does not mean that implementors are forbidden to write programs that "X" but rather it means that programs that "X" will fail to interoperate with conforming programs.

An implementation of a W3C "user agent" that conforms to all requirements of a (hypothetical) EOT Recommendation, except that the user agent renders using a web font regardless of "root strings" or "permission bits" or other meta-data -- such an implementation will interoperate perfectly well with implementations that do not impose such a restriction against users.

Because rendering without regard to permission bits or root strings does not in any way damage interoperability, any claim by a standard that a browser "MUST NOT" render for interoperability-sake is a false claim.

W3C should not publish Recommendations with known-to-be-false claims and therefore the W3C web font Recommendation MUST NOT say that user agents "MUST NOT" render just because of permission bits or root strings.

"SHOULD NOT" Means "May Fail to Interoperate Unless Does Not"

Similarly, in an interoperability standard, the phrase "SHOULD NOT" is not a stern ethical warning but rather, and highly technically, advice that other conforming programs are not required to interoperate with a program that "does" in spite of the "SHOULD NOT".

If a program's possible action "X" is interesting enough that some implementations will want to do it, yet a program that insists on doing "X" is not guaranteed to inter-operate, then the program SHOULD NOT "X".

A user agent that renders using web fonts regardless of permission bits, root strings, or other meta-data will not ever fail to inter-operate on the web. Thus, "SHOULD NOT" is not the right language to describe such font rendering.

"MAY not" Means "Will not Fail to Interoperate By Not"

The EOT proponents seem to think it important that there will exist interoperable user agents which pay attention to permission bits in fonts, and/or root strings, etc. and sometimes refuse to render with a font accordingly.

They would like such user agents to be recognized as conforming to the standard.

Such a browser would not fail to inter-operate with other web software and so such implementations ought to be permitted. If we want to give this point emphasis in a standard, then the right language is something like "MAY refuse to render with the font".

Conforming programs (fully inter-operable) can render with such fonts or not under any circumstance, but we emphasize that they are not obligated to render if the permission bits or root strings suggest some reason to not render.

Conclusion: Standards Are What Works, Not What We Wish Was Enforced

Standards such as W3C Recommendations give advice about how a distributed effort at software development can result in a set of separately developed yet inter-operable programs.

Critical formal language in standards, such as "MUST NOT" and "SHOULD NOT" and "MAY not" must be understood as technical terms contributing to a specification of inter-operability rather than some kind of legal prohibition or ethical admonishment.

By forgetting that inter-operability is the one true meaning of such langauge, the EOT proposal as it stands over-reaches and abuses the standards process. The "fix" is to make clear that user agents are not obligated by the standard to NOT render no matter what permission bits and root strings and other meta-data says.