Re: css3-fonts: should not dictate usage policy with respect to origin

Liam, thanks for your prologue expressing good will.

On Tue, Jun 28, 2011 at 9:18 PM, Liam R E Quin <liam@w3.org> wrote:

>
> >    - Samsung believes the issue is whether an existing implementation of
> >    @font-face that does not employ same origin can claim conformance to a
> >    final, published REC that wishes to apply the same origin mandate to
> all
> >    implementations, whether new or old;
>
> You can only claim conformance to a W3C Recommendation, of course, not
> to a draft.
>
> An existing implementation of @font-face did not "conform" to anything.
> Why? Because the @font-face syntax was defined in a working draft.
> Conforming to a Working Draft that can be updated at any time isn't
> really a meaningful claim.
>

Actually, you may not have noticed that various industries regularly make
normative reference to non-final W3C documents, including PRs, CRs, and WDs
(though I haven't seen a normative reference to an editor's draft).

Why is this done? Because the W3C on occasion has taken a great deal of time
to complete (or has never completed) some specifications. For example,
css3-fonts was first published in July 2001, nearly 10 years ago. CSS TV
Profile also comes to mind.

How is this done? By considering any form of published W3C document as a PAS
"publicly available specification" [1] with a persistent URL. This is done
regardless of the warnings in the status section.

Who is doing this? Well, let's see, the CEA (Consumer Electronics
Association), the ATSC (Advanced Television Systems Committee), Cable
Laboratories, SCTE (Society of Cable and Television Engineers), ETSI
(European Telecommunication Standards Organization), DVB (Digital Video
Broadcasting), ITU (International Telecommunications Union), and the list
goes on. If I had time, I would happily supply specific instances of such
normative references, but I can assure you they are there.

[1] http://en.wikipedia.org/wiki/Publicly_Available_Specification


> You thus presumably are not objecting that a new Recommendation will
> make implementations fail to conform to something that never existed.
>

As you point out below, and I have already pointed out in this thread,
"there is no compliance certification done by W3C". But that has not
prevented non-REC forms of documents being used in the absence of a timely
completed REC.

I can't speak for Chris and Bert but right now my understanding would be,
> Samsung made
> some devices or implementations of a very old draft of @font-face and
> doesn't want to change those implementations, but wants to say that
> Samsung implements @font-face, and is objecting to WOFF going forward
> even though their existing implementations presumably won't support
> WOFF.


First I was using this as an example of why such a change produces a
potential interoperability issue. Secondly, I have never said that I am
referring to Samsung devices. In fact, @font-face has been implemented in a
variety of products in the consumer electronics industry (including Samsung,
LG, Sony, Philips, and others) prior to the current version, based on
earlier WDs which have been referenced by published specs (in the CE
industry).

Finally, I've pointed out that some of these existing devices, specifically
some Samsung devices (I can't speak for future plans for other companies),
may be updated to support WOFF format, since it is a straightforward
extension of existing sfnt based formats (OTF, TTF). Indeed, merely updating
these implementations to a new version of libfreetype.so that supports WOFF
may be nearly sufficient to support WOFF, while adding support for
same-origin requires a lot more work to core resource fetch and access code.

So I'm making this case not only for Samsung, but for a larger industry,
based upon real world implementation and deployment issues.

However, going back to a number of generic points that have been made:

   - css resource fetches (images, @import, etc) do not mandate use of same
   origin
   - usage policy should be defined separately from mechanism

These points by themselves are enough to make Samsung take pause at the
proposed requirements, which makes @font-face fetches inconsistent with
other css driven fetches, and which merges policy and mechanism.
Notwithstanding our concern about these points, we *are* willing to accept
mandatory requirements in a fashion that would address our prior expressed
concerns, and for which we have offered a number of possible approaches that
should be considered carefully by the affected groups.

Regards,
Glenn