RFC: EOTL font file specification version 1

Request for comments:

See my previous post:
http://lists.w3.org/Archives/Public/www-font/2009JulSep/1206.html

I thought about this a bit more and perhaps we should drop all
non-critical legacy features from EOT Lite and rename it as e.g. "EOTL
font format" or "SEOT font format" (the latter standing for Simplified
EOT) or PBCWF (Possibly Backwards Compatible Web Font). I'll refer to
new font format as EOTL font below.

****

The EOTL font file specification (version 1)

File starts with a two consecutive 32 bit little endian unsigned integer
numbers. The first is called EndOffset and the second is called
PayloadSize. Before trying to load an EOTL font file, a conforming user
agent must first execute Same-origin check and if that fails, consider
the font as invalid.

Same-origin check:

Before an EOTL font is downloaded either of the conditions below
must be true:

1. The font originates from the same origin as the containing document
2. The site serving the font relaxes the restriction above using an
   Access-Control-Allow-Origin HTTP response header as described in the
   Cross-Origin Resource Sharing specification.

If the Same-origin check is successful, a conforming user agent will
download the font. Then the font is activated by loading the data at
offset (EndOffset - PayloadSize) of length (PayloadSize) as a normal
OpenType font. If the font loads successfully, it will be used.
Otherwise, consider the font as invalid.

****

As I see it, the EOTL specification does not need to say anything more.
It could mention in the informal part that the bytes between byte 8 and
offset (EndOffset - PayloadSize) can be used for compatibility with
legacy user agents.

If compatibility with legacy user agents (MSIE) is not required, the
EOTL font file is identical to OpenType with eight byte prefix computed
from the size of the original OpenType font file (EndOffset is set to
size of Original OpenType font + 8, PayloadSize is set to the size of
original OpenType font, followed by contents of original OpenType font
file).

The OpenType font data can be extended with additional tables to contain
any meta information about the font as needed by font author/distributor.

In the end, any EOT classic font without XOR or MTX scrambling can be
loaded successfully with Same-origin/CORS restrictions with conforming
user agents. A compatible (but non-conforming) legacy agent (MSIE) can
load the EOT classic font as usual (no Same-origin restrictions but
rootstrings or other restrictions in the EOT classic font may apply).

Pros:

- Really easy to implement (similar to raw OTF except for the offset).
- Does not require any EOT specific knowledge or magic numbers from
conforming user agent.
- Compatibility with MSIE.

Cons:

- Undermines the "protection" provided with rootstrings in current EOT
files (though, I'd assume that most EOT files with rootstrings also
include XOR or MTX scrambling and would not be successfully loaded).

-- 
Mikko