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

In the absence of same origin, an existing implementation could remain
conformant; while in the face of a mandatory same origin requirement, an
existing implementation would become non-conformant or require modification.
Therefore, the change is not backwards compatible with respect to
maintaining the definition of conformance. This is why I offered alternative
language that would permit those existing implementations to remain
conformant while requiring new implementations (e.g. HTML5 UAs which
otherwise require same origin) to implement same origin to be conformant.

I am trying to find a solution that maximizes conformance, while the views I
have seen expressed here seem bent on reducing conformance, at least with
respect to fielded implementations.

G.

On Mon, Jun 27, 2011 at 1:58 PM, Levantovsky, Vladimir <
Vladimir.Levantovsky@monotypeimaging.com> wrote:

> Hi Glenn,****
>
> ** **
>
> You wrote:****
>
> Similarly, a variety of devices have been deployed based on earlier
> versions of @font-face in which same origin did not apply. Those devices may
> or may not be updated to support a final version of @font-face which does
> apply same origin. The change that introduces same origin thus impacts the
> interoperability and potential compliance of those earlier devices.****
>
> ** **
>
> Such non-backward compatible changes should be scrutinized and considered
> when making such changes.****
>
> ** **
>
> Deployed devices that are based on earlier versions of the @font-face spec
> would load a font regardless of its origin and without any regard to any new
> access control headers. As far as they are concerned – nothing has ever
> changed, and the content is going to be delivered and rendered exactly the
> same way it used to be. Newly deployed implementations would have to honor
> the same-origin restrictions and pay attention to the access control
> headers, but again this would only be true for new implementations. Can you
> please provide an example showing that the introduction of same origin
> restriction impacts the interoperability of those earlier devices? What is
> the basis for your claim that this change is non-backward compatible?****
>
> ** **
>
> Thank you,****
>
> Vlad****
>
> ** **
>
> ** **
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Friday, June 24, 2011 8:36 PM
>
> *To:* Sylvain Galineau
> *Cc:* liam@w3.org; Levantovsky, Vladimir; StyleBeyondthePunchedCard;
> public-webfonts-wg@w3.org; www-font@w3.org; Martin J.
> *Subject:* Re: css3-fonts: should not dictate usage policy with respect to
> origin****
>
> ** **
>
> You are putting words into my mouth when you claim I am making this
> argument based on "Samsung CE Devices". I did not specifically cite Samsung
> implementations of the interactive television standards I referred to. In
> fact, a significant number of CE manufacturers have deployed those
> standards.****
>
> ** **
>
> Next, new drafts *do* affect existing implementations when the features
> implemented are subject to changes in draft specifications, such as
> css3-fonts, which have been in process for nearly ten years. Just like
> HTML5, implementers cannot afford to wait until it reaches REC state, and
> early implementations that are fielded may be difficult or uneconomical to
> update.****
>
> ** **
>
> As an example, Microsoft created the UPnP 1.0 specification based on MSFT's
> early implementation of XML Schemas; namely, upon XDR. Many devices were
> fielded using this work based on early drafts of XSD. Those devices are
> still in the field. Eventually, XSD was finalized, but those early devices
> remain dependent upon XDR, and are not conformant with XSD. Slowly, new
> devices are being fielded based on UPnP 1.1 which transitioned to XSD as
> finalized.****
>
> ** **
>
> Similarly, a variety of devices have been deployed based on earlier
> versions of @font-face in which same origin did not apply. Those devices may
> or may not be updated to support a final version of @font-face which does
> apply same origin. The change that introduces same origin thus impacts the
> interoperability and potential compliance of those earlier devices.****
>
> ** **
>
> Such non-backward compatible changes should be scrutinized and considered
> when making such changes.****
>
> ** **
>
> This is a simple, pragmatic argument, not based upon an ideal state of
> affairs in which implementers refrain from building products until a
> specification is complete. Of course, this is a risk taken by implementers,
> but it is also a risk faced by standardization efforts, particularly those
> that take a very long time to reach some level of finality.****
>
> ** **
>
> You may think Samsung's objection unreasonable, but Samsung does not. So we
> will have to disagree on that point.****
>
> ** **
>
> I have proposed alternative language that represents what we believe to be
> a reasonable compromise. The WG can either consider it, possibly adopting
> it, take it in part, or ignore it entirely. That is up to the WG to decide.
> ****
>
> ** **
>
> I don't intend to elaborate our position any further, since it would merely
> mean repeating what has already been said.****
>
> ** **
>
> Regards,****
>
> Glenn****
>
> On Fri, Jun 24, 2011 at 5:51 PM, Sylvain Galineau <sylvaing@microsoft.com>
> wrote:****
>
> First, there is no such thing as a ‘retro-active requirement’. New drafts
> only affect future implementations. As there are no explicit or implicit
> requirements for you to go back and fix legacy devices every time a draft
> specification is updated, the claim that such an obligation is forcing you
> to object has no basis and thus no compromise seems necessary to resolve it.
> Since you point out that you have no objection to this requirement for new
> ‘HTML5’ devices, I wonder if you could elaborate on what makes you believe
> those devices that predate it must be updated to conform to it?****
>
>  ****
>
> Second, as some of us have successfully deployed this font access policy to
> hundreds of millions of users, we do have some understanding of its
> real-world impact and I am available to answer any questions you may have on
> the matter. In Microsoft’s case, many of our users still run a 10 year-old
> browser on a 10 year-old OS (as you say, PCs **can** be updated more
> easily; it doesn’t follow that they are…) running an implementation of
> @font-face originally based on a specification older than css3-fonts’ first
> draft. We also support a legacy font encoding (EOT) and apply same-origin
> restrictions to resources in this format in our latest release; we do so
> despite the fact that no such requirement ever existed for EOT, never mind
> that EOT supports its own origin restriction mechanism. Our older releases
> (as well as emulations of these older releases) do, however, remain
> unchanged and still download EOT fonts from all origins; precisely because,
> yes, this would be a breaking change, because our customers expect older
> versions to remain stable i.e. *compatible with our implementation of the
> standards of their time*…and because there are no ‘retro-active
> requirements’ to update these older releases.****
>
>  ****
>
> By the way, since the change you request would likely conflict with
> deployed IE and Firefox implementations by making failure scenarios valid,
> wouldn’t you expect Mozilla and Microsoft to object for the same reasons?
> Surely such a change would be as retro-active on our UAs as it is on yours?
> Shouldn’t this impact also be taken into account?****
>
> Third, I do not believe I made an unfair generalization of your argument;
> but I find it encouraging that you seem to disagree with a generalization of
> it. Maybe you believe your request justified because of its narrow and
> targeted nature, as you perceive it? It could explain part of the gap in
> understanding we’re struggling with. ****
>
>  ****
>
> To summarize, you are stating that the existence of Samsung CE devices
> implementing a prior draft of CSS3 Fonts requires you to formally object to
> those changes that are incompatible with these devices. In the absence of
> any concrete expectation or demand by the CSS WG or the Fonts WG that you
> update these products to conform with a requirement drafted after they were
> designed and released, and in the absence of any use-case demonstrating
> end-user harm – a UA that loads fonts from all origins will render all pages
> designed for UAs that enforce SOR - I consider your objection unreasonable
> as stated and see no further action that can, or should, be taken.****
>
>  ****
>
> I do, of course, welcome discussion of this requirement on its own merits
> or lack thereof, as it may be.****
>
>  ****
>
>  ****
>
> *From:* www-style-request@w3.org [mailto:www-style-request@w3.org] *On
> Behalf Of *Glenn Adams****
>
>
> *Sent:* Thursday, June 23, 2011 1:22 PM
> *To:* Sylvain Galineau****
>
> *Cc:* liam@w3.org; Levantovsky, Vladimir; StyleBeyondthePunchedCard;
> public-webfonts-wg@w3.org; www-font@w3.org; Martin J.****
>
>
> *Subject:* Re: css3-fonts: should not dictate usage policy with respect to
> origin****
>
>  ****
>
> One must recognize that (1) UAs deployed in CE devices are not the same
> category as PCs, which can be updated more easily; (2) css3-fonts has been
> under development for an inordinately long time and the need for @font-face
> implementations has existed since the beginning; (3) UAs *are* deployed that
> use @font-face and that do not support HTML5 or same-origin.****
>
>  ****
>
> These are facts that should be considered, and as a representative of a
> company that has deployed such UAs, Samsung will continue to object to a
> retroactive requirement on these UAs to support same origin. We do not,
> however, have the same position for HTML5 category UAs that are now
> appearing in the field.****
>
>  ****
>
> Of course, a WG is entitled to change a non-final spec in a non-backward
> compatible manner, but in doing so should take into account the impact of
> such a change. Finally, I did not suggest such a generalization as you state
> below.****
>
>  ****
>
> I am attempting to find compromise language that Samsung can live with. Are
> you interested in finding a compromise that can remove our objection or not?
> ****
>
>  ****
>
> G.****
>
>  ****
>
> On Thu, Jun 23, 2011 at 2:11 PM, Sylvain Galineau <sylvaing@microsoft.com>
> wrote:****
>
> As a *draft* specifications, css3-fonts and WOFF can certainly define new
> requirements for future implementations. Your entire argument would imply
> that once a draft has been implemented future versions of the spec must be
> compatible with those implementations. This is not the way CSS works; no
> implementation that implemented a given draft is guaranteed conformance with
> the next one. The main motive for vendor prefixes is to allow specifications
> to evolve without breaking implementations. That historical implementations
> did not prefix their @font-face implementation should not block us from
> achieving both interoperability and desirable runtime behavior in future
> implementations.****
>
>  ****
>
>  ****
>
> *From:* public-webfonts-wg-request@w3.org [mailto:
> public-webfonts-wg-request@w3.org] *On Behalf Of *Glenn Adams
> *Sent:* Thursday, June 23, 2011 12:59 PM
> *To:* liam@w3.org
> *Cc:* Levantovsky, Vladimir; StyleBeyondthePunchedCard;
> public-webfonts-wg@w3.org; www-font@w3.org; Martin J.****
>
>
> *Subject:* Re: css3-fonts: should not dictate usage policy with respect to
> origin****
>
>  ****
>
> Samsung supports your suggestion below if it is expressed either as
> "should" or made conditionally mandatory, where the condition is expressed
> as follows or an equivalent:****
>
>  ****
>
> "If the use of WOFF occurs in a context where same origin access
> constraints are *already* present/supported, then that mechanism *must* be
> used to limit access to WOFF fonts; otherwise, such a mechanism *should* be
> provided for such use."****
>
>  ****
>
> We do not want the use of WOFF by itself, or css3-fonts, by itself, to
> trigger a mandatory requirement for same origin processing in contexts that
> don't already support such constraints. For example, in HTML4 or XHTML1
> category UAs that already support @font-face or that wish to support WOFF.
> ****
>
>  ****
>
> We note that the @font-face rule has been defined in css3-fonts since 31
> July 2001, and that a variety of UAs have been fielded in the non-desktop
> environment (e.g., mobile, television, etc), which employ @font-face for
> accessing other non-WOFF fonts, and do so without same origin restrictions.
> This would argue against introducing a non-backward compatible change in
> css3-fonts to mandate same origin processing for prior fielded
> implementations that do not otherwise support same origin. WOFF similarly
> should not by itself trigger mandatory support for same origin in such UAs.
> ****
>
>  ****
>
> G.****
>
> On Thu, Jun 23, 2011 at 11:30 AM, Liam R E Quin <liam@w3.org> wrote:****
>
> The WOFF spec could say in its conformance section (right in the spec,
> not in a separate document) that for use in style sheets (not only CSS)
> an implementation-defined mechanism should (must?) be available to limit
> access to the WOFF resource outside of support for the style sheets, and
> maybe give same-origin as an example.****
>
>  ****
>
>  ****
>
> ** **
>