RE: WOFF without SOR?

One more note on this topic.

Anne did suggest using a separate header for this purpose instead of CORS not too
long ago but that ship had already sailed. Releases of Firefox 3.5+ support this, 
IE9 preview builds have supported this for many months and real-world services from 
Typekit to Google Fonts already support the CORS-based solution. Breaking what 
works well today is not an option. Adding a redundant way to do the same thing 
is just unnecessary pain at this point. In practice we'd end up with supporting
two sets of HTTP headers - those that work today + the new version - maybe two code 
paths (if the new header value is not 1-to-1 CORS-like), more testing, make sure we 
handle edge cases where both headers are specified etc. Yuck. 

If we wanted that it should have been specified and implemented a while ago. It's 
too bad we're using a standard feature for a scenario it was not intended for 
but that's life on the web. All we should do now is really scope down what exact 
minimal subset of CORS is required for WOFF conformance. That's the pragmatic
course of action. 

Starting a new spec should thus not be necessary unless we want to define an SOR 
mechanism that is unspecified elsewhere and thus incompatible with current 
implementations. I'm not quite sure how the scope of this WG's charter can be 
argued to include the definition of a general SOR mechanism distinct from CORS. 
(I assume Anne wasn't talking about creating something specific to fonts as that
would be rather confusing from someone who thinks fonts should be like any other file).

While it's natural for the CORS editor to disagree, I don't think fixing this is 
worth all the extra work and disruption. So it would help if Opera could make a
constructive case explaining why it would beneficial for all current implementations
and users of this protocol to go through such a switch.

Received on Wednesday, 26 January 2011 18:06:36 UTC