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

It may be useful to add that my understanding of the current language
proposed in css3-fonts and woff is that the following would apply:

Step 1   Step 2
  0        0        // *non-*conforming behavior
  0        1        // conforming behavior (note 1)
  1        0        // non-conforming behavior (note 2)
  1        1        // conforming behavior

Our position is that first line above should NOT be defined as
non-conforming behavior. This line corresponds to a UA which does not
otherwise implement support for same origin access restrictions. Clearly
this UA would not be conforming in the context of HTML5, but it should be
conforming in the context of some other UA definition that does not impose
the same origin restrictions found in HTML5.

We are fine with the third line being defined as non-conforming, which is
the essence of the alternative language we propose.

In the context of HTML5, only the third and fourth lines would be possible
if the implementation at least conforms to HTML5 same-origin restrictions on
non-WF fetches. So the interpretation of these two lines should not present
a problem w.r.t. the intent expressed by the WF WG. Similarly, the second
line should not present an issue.

The only issue then is line 1: whether it needs to be defined as
non-conformant (as some have argued) or conformant (as Samsung has argued).
Line 1 is an issue only in non-HTML5 cases, so the question is how much does
this group worry about non-HTML5 UAs w.r.t. same origin enforcement of WF
fetches?

It is this last category that Samsung wishes to see supported, particularly
in the context of already fielded, HTML4 or XHTML1 class  UAs that support
@font-face but do not support same-origin. We do not want to see such UAs be
labeled as non-conformant w.r.t. CSS3-FONTS or WOFF simply because they are
not retrofitted to support same origin restrictions on WF fetches. Note that
these UAs already support some non-WF font formats, e.g., BDF, OTF, TTF,
etc, and that adding support to these for WOFF format is much easier than
adding support for same-origin semantics.

It should be possible for these existing (non-HTML5) UAs to continue
fetching BDF, OTF, TTF, etc., without becoming non-conforming under the
auspices of a (finally, after ten+? years) complete CSS3-FONTS spec.
Further, they should be able to support WOFF formatted wrappings of the same
OTF/TTF fonts.

On Mon, Jun 27, 2011 at 11:58 PM, Glenn Adams <glenn@skynav.com> wrote:

>
> On Mon, Jun 27, 2011 at 8:01 PM, Sylvain Galineau <sylvaing@microsoft.com>wrote:
>
>>
>> ****
>>
>> >However, in the interest of compromise, we are willing to drop the
>> objection if the language is changed to require same-origin only in the *
>> ***
>>
>> >case that the UA already requires it (due to other requirements).****
>>
>> As pointed out earlier – and, of course, ignored by you – such language is
>> normatively meaningless and untestable.
>>
>
> Wrong. It is both meaningful and easily tested.
>
> (1) determine if UA implements same origin restriction on a non-WF resource
> known to be subject to same origin restriction (as normatively mandated by
> the spec to which UA claims conformance), e.g., a JS resource fetched when
> processing a script element on an HTML5 UA; easily tested by using a cross
> origin reference with restrictive headers; if access succeeds, then record
> as 0 (no restriction), otherwise 1 (restriction applied);
>
> (2) determine if UA implements same origin restriction on a WF resource,
> e.g., use a cross-origin reference on a WF, recording success (no
> restriction) as 0, otherwise 1 (restriction applied);
>
> (3) using following truth table, assess whether or not UA implements
> conditional mandatory requirement to support same origin  on WF fetch
> predicated on existing support for same origin on non-WF fetch:
>
> Step 1   Step 2
>   0        0        // conforming behavior
>   0        1        // conforming behavior (note 1)
>   1        0        // non-conforming behavior (note 2)
>   1        1        // conforming behavior
>
> Note 1: permissible for UA to enforce same origin on WF fetch even in
> absence of enforcement on non-WF fetch;
> Note 2: this is a direct affect of the alternative language I proposed,
> i.e., that same origin must apply for WF fetch if UA already supports WF,
> the violation of which would result in non-conformance;
>
>
>
>> In order to achieve a compromise one needs a defensible position that is
>> at least understandable by others. Until you’ve been able to make at least
>> some members of the WG reach a level of understanding and agreement about
>> the issue you’re trying to resolve, offers of compromise are only helpful
>> when they clarify your position. When the compromise is to say ‘css3-fonts
>> does not define whether and how @font-face loads fonts and leaves it to
>> HTML5 which shall allow all the incompatible behaviors currently
>> implemented’, it seems we don’t have any actionable compromise.
>>
>
> CSS3 Fonts does not fetch resources any more than CSS @import and CSS
> background="url(...)" do not fetch resources. These mechanisms define how
> resources are referenced. A UA which employs and supports CSS does the
> fetching and defines fetch semantics. CSS does not define how fetch works or
> how access control works in conjunction with fetching. Or at least, CSS does
> not do so outside of the proposed language being discussed here.
>
> If you can't follow this logic, then I'm not sure how I can improve your
> understanding of the position I am representing.
>
> G.
>
>