W3C home > Mailing lists > Public > public-webfonts-wg@w3.org > October 2010

RE: non-normative best practices & file caching

From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Sat, 2 Oct 2010 21:40:15 -0400
To: Dave Crossland <dave@lab6.com>, John Hudson <tiro@tiro.com>
CC: David Singer <singer@apple.com>, Sergey Malkin <sergeym@microsoft.com>, Christopher Slye <cslye@adobe.com>, Håkon Wium Lie <howcome@opera.com>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
Message-ID: <7534F85A589E654EB1E44E5CFDC19E3D049DD31A89@wob-email-01.agfamonotype.org>

On Saturday, October 02, 2010 5:03 PM Dave Crossland wrote:
> To: John Hudson
> On 2 October 2010 02:02, John Hudson <tiro@tiro.com> wrote:
> > David Singer wrote:
> >> I think perhaps that the shoulds should be musts
> >
> > I'd be very happy for that to be the case.
> >
> > The impression I get from Håkon's comments re. this text being non-
> > normative is that he and perhaps others might have objections to 
> > 'must' in this context.
> This discussion is veering into DRM.

I would suggest to refrain from using the D-word when there no reason for it - it leaves a bad taste as if someone is trying to stifle the discussion when there is no reason for it. The informative note in question attempts to further explain the normative requirement of the CSS spec that clearly and unambiguously states that the downloaded font resources "MUST NOT be made available to other applications or documents on the user's system" - are you saying that the CSS spec is veering into DRM?

> This text is non-normative. As I understand that term, it doesn't
> matter if the standard says 'should,' 'must,' or 'pretty please' in
> non-normative sections, because they all carry the same weight: none.
> Any directives in such sections are very informal suggestions,
> carrying no weight, whatsoever.

Yes, the text is non-normative, but it attempts to clarify a normative statement, and nothing in this note should contradict the meaning of what the normative statement says. The English language is the language of this spec, and the plain English words "must" or "must not" (or anything else to that matter) are not barred from being used in the informative note.

> However, having recently spoken to lawyers about unrelated copyright
> license issues, it seems that lawyers can try to paint things like FAQ
> documents to licenses as normative - since they express the intent of
> the license authors. Therefore I would like to see 'should' as the
> strongest language used, even in non-normative sections, and would
> prefer to see 'may' rather than 'should.'

The WOFF and CSS specs have nothing to do with licenses, and nothing that UA does or doesn’t do related to any particular license condition. Therefore, the use of any language in informative parts of the spec should be coherent with the normative parts of the same spec, nothing else matters!

Your comment about licenses was completely off topic, but since you brought it up - I'd like to mention what I heard lawyers say. In my discussions with lawyers, they said that *if* there are multiple different documents that attempt to *explain* the meaning of the license - the least restrictive document is the only one that matters. A lawyer *may* therefore try to paint the FAQ to a license as normative, but only if that FAQ would be considered less restrictive than the original license document. Again, this is completely off topic and has nothing to do with the subject of our discussion.

> >> or the language needs to talk about not making the font available
> outside
> >> its licensed use (if the client can tell it's freely distributable,
> then you
> >> can expose/install it if you like, but I don't know how it would
> tell)
> >
> > I don't think that is reliably determinable using any existing font
> data*,
> I know that is not reliably determinable, because it is *impossible*
> for a machine to know what the user is permitted to do. This is the
> core of the DRM conundrum: Even if the file says "You can't do
> anything," users are allowed to do various things under fair-use
> exceptions and the like.

The language of the WOFF spec only addresses the UA behavior that is relevant to technical requirements, user security, etc. - there is nothing else. Except in human-readable metadata that can only be displayed to a user - there is nothing in the WOFF file that would convey any information about licensed use, and I agree - it is impossible for a UA to know what the user is permitted to do. As far as a UA is concerned - it will do whatever is prescribed by the spec and is necessary to use the presented data in a manner the content author intended.

> > I can't think of a situation in
> > which installing the unwrapped content of a WOFF file is a necessary
> action,
> > so it is easiest simply to recommend that this should not be done.
> I can: The WOFF is entirely libre software.
> Given that many web fonts will say "I am installable if you like me,"
> it is entirely legitimate for users to install and use user agents
> that have features to conveniently install web fonts. Libre fonts are
> commonly used as web fonts, and installing libre WOFF-wrapped fonts is
> likely to be popular.

I am sorry but you contradict yourself - didn't you just say that " it is *impossible* for a machine to know what the user is permitted to do"? If font presented in WOFF format is installable, users will know about it from its metadata. They will also know where to get the original font file and can proceed with downloading and installing it as they wish. The UA, however, will have no idea what users can or cannot do (as you stated earlier) - the use case is irrelevant here.

> The best and only legitimate thing such user agents can do is to
> present the license metadata in the fonts to users *prominently* in
> their user interface and trust that users to not choose to do what
> they are not permitted to do.

Amen! I whole-heartedly agree.


> --
> Cheers
> Dave
> (Please note, this email is my personal opinion and does not represent
> the views of any of my consulting clients.)

Received on Sunday, 3 October 2010 01:41:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:04:23 UTC