W3C

- DRAFT -

WebFonts Working Group Teleconference

16 Jun 2010

See also: IRC log

Attendees

Present
+1.781.970.aaaa, +1.443.895.aabb, +1.510.816.aacc, +1.425.882.aadd, +1.250.668.aaee, +1.206.324.aaff, jdaggett, cslye, +47.21.65.aagg, ChrisL, +31.70.360.aahh, +1.206.324.aaii
Regrets
Chair
vlad
Scribe
chris

Contents


<erik_> trying to connect

<erik_> still wrestling with phone, it hangs up after entering the access code.

<jfkthame> it seems like it's just not hearing me enter the code

<sylvaing> to attach your phone number: http://www.w3.org/1998/12/bridge/info/name.php3

<jfkthame> it asks again, and then just hangs up

<jdaggett> csyle: using the format "zxxx, xxx is c

<jdaggett> cslye: you're the only 510 number, right?

<cslye> That's correct.

<cslye> So, let me try this...

<erik_> unable to connect - same here.

<erik_> star / zero doesn't go anywhere either.

<sylvaing> trackbot-ng, start telcon

<trackbot> Date: 16 June 2010

<cslye> Vlad: Should we discuss origin restrictions or metadata first?

<Vlad> http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0092.html

<erik_> despite repeated tries, I'm unable to connect

<jfkthame> also unable to connect - i can watch the irc channel but no phone connection

<sylvaing> 1) there is no security benefit here.

I can connect via the US number. France number seems unable to accept touch tones

<erik_> trying

<sylvaing> 2) same-origin is not defined in HTML5 but in CORS. CORS depends on HTML5 for the definition of origin and origin matching

<cslye> I connected to the Boston number with no problem, fwiw.

<sylvaing> not opposed

<erik_> I could connect via the uS number

Anne (CORS editor) opposes using CORS for WOFF

Howcome: is same-origin for WOFF or for other formats?

<sylvaing> Font vendors do not want to license raw fonts so that shouldn't be an issue

<sylvaing> at least for some time

<cslye> I think the point is that WOFF is a "protected" format and deserves the mild protection it gets from same-origin, whereas "raw" fonts don't need it.

howcome, you mentioned a range of opinions in Opera - what are the others?

howcome: others say its good, for example to save bandwidth

<cslye> When we refer to the "security" argument, we mean attacks and such, as opposed to theft?

<sylvaing> cslye: yes

<sylvaing> notes that TypeKit et al. rely on cross domain font access so the licensing benefit depends on who the vendor is

<jdaggett> typekit uses data urls

<jdaggett> i.e. they are not affected by this

<sylvaing> jdaggett: for Firefox, yes

<cslye> I think Typekit delivers EOT files for IE, though.

<erik_> this is the license FSI links to in their current WOFF releases: http://www.fontfont.com/eula/license_webfonts_v_1_0.html

<sylvaing> jdaggett: there still are other browsers :) and other font providers who link across domain e.g. ascender

2.3. Font Software File Protection. You must ensure, by applying reasonable state-of-the-art measures, that other websites cannot access the Font Software for display (e. g. by preventing hotlinking and blocking direct access to the Font Software via .htaccess or other web server configurations).

http://www.fontshop.com/help/licenses/fontfont/

<jdaggett> sure

sg: if browsers do this, font vendors are willing in return to llosen their licenses

<cslye> Not just loosen their license, but would be more inclined to offer web font licenses in the first place.

erik: makes it much easier for us certainly

<erik_> (that's erik, not Erik0

erik: current licensing is in flux and depends on how WOFF spec ends up

<Vlad> installing adequate technical protection measures that restrict the use and/or access to the Font Software and/or Derivative Works, for instance by binding an EOT font to the Licensed Websites, utilizing JavaScript or access control mechanism for cross-origin resource sharing and/or protecting a sIFR Flash file against use on other websites than Licensed Websites by restricting domain access only to Licensed Websites.

<cslye> :)

vlad: monotype license encourages woff usage

sylvaing: generaly positive on same-origin

howcome: abstain

<cslye> Does anyone explicitly object to requiring access control?

resolution: same-origin restriction is mandatory for WOFF. modulo editorial changes discussed on the list

extension mechanisms

f2f

<cslye> I agree.

vlad: majority favour a f2f at typecon in LA

chris: will try, but CSS in Oslo next day, also affects howcome, jdagett and sylvaing

<cslye> My concern with ATypI is that it's closer to TPAC. (Also more difficult for me personally.)

vlad: dublin atypi

john: can't do dublin

cslye: cant do dublin

(sep 9-12)

<sylvaing> will be at TPAC

howcome: do we need a physical f2f?

<erik_> http://atypi.org/03_Dublin

vlad: seen as desirable

<erik_> http://www.typecon.com/

<cslye> It's possible for me -- but travel budget makes it difficult.

sylvaing: is there enough of an agenda to justify travel?

<sylvaing> if people find themselves in the same spot, they can certainly meet

vlad: colocating would capitalize on existing travel

chris: can do call-in using a bridge

cslye: travel restrictions - good to have the WG there. How can we entice people?

vlad: everyone plese restate their travel plans including existing travel

<jdaggett> would love to come to typecon but with another meeting directly following it, that's tricky

<sylvaing> same as jdaggett even though it's fewer miles for me

chris: some of tpac will be spent in liaison

<tiro_j> I will be at TypeCon, but not at ATypI, posibly at TPAC

vlad: we asked for no overlap with css, can we reschedule?

<sylvaing> overlap with CSS would be quite unhelpful for 4+ of us

<scribe> ACTION: chris ask tpac organisers to reschedule webfonts to thur/fri at tpac [recorded in http://www.w3.org/2010/06/16-webfonts-minutes.html#action01]

<trackbot> Created ACTION-9 - Ask tpac organisers to reschedule webfonts to thur/fri at tpac [on Chris Lilley - due 2010-06-23].

metadata extensions

vlad: from discussions so far, etadata as specified in draft seems near consensus. number and type of elements is ok for font vendors
... implementors said it was ok even though optional
... so we can state consensus on the existing set of standard metadata elements
... so then we can discuss extension mechanism only

(no objections)

howcome: not sure
... want to see a complete proposal

vlad: can modify for good reason after fpwd

<sylvaing> doesn't know either but acknowledges that what we have is already being used. that's important

vlad: simple key-value is proposed for extensions
... localisation is important, tried to be impartial in summary, hope that was clear. but speaking for monotype, opinion is that the solution form jonathan kew was the best one
... sergei commented to say it was simple to implement, one pass

sergeym: yes

vlad: duplication should not cause significant size increase as it compresses well

howcome: difficult to discuss now, propose to delay all metadayta out of 1.0

vlad: including the standard metadata?

<cslye> Wouldn't that just create a lot of ad hoc metadata in shipping WOFFs?

tal: strongly object, that is the basis we got people to sign on, removing it would be insulting

vlad: so please respond on email

<sylvaing> we could keep what we have and postpone extensibility. I think this is what Hakon is saying ?

howcome: yes. just t eh extensibility

sylvaing: document what is used now
... extensibility comes later
... now one is using extensibility right now
... so drive to LC, CR. Extend once we have actual requirements

howcome: ok with that

sylvaing: do we want to delay for uncertain extensibility?

vlad: if its in fpwd theyn we get feedback and can take it out if needed

<cslye> If we want to get use cases for extended metadata for 1.0, we might get that out of TypeCon and ATypI conversations.

sylvaing: bar metadata, what other issues do we have?

vblad: not many

howcome: so lets get fpwd soon

vlad: want to have a solution that many of us can live with. if its in the fpwd we can ask for comments. if its not in the draft we can't get comments

sylvaing: ok lets get it out there

sergeym: font vendors unlikely to want to remove the extensibility

cslye; any objection to put it in current draft?

sylvaing: current draft represents what is out there

Vlad: better to have an extension proposal for people to discuss

john: put extensibility as a separate item?

chris: putting in extensibility and deleting later if needed is better from a patent policy point of view

vlad: lets use next couple of weeks to try to get agreement here. only half a page or so anyway

<jdaggett> history has been made...

howcome: i am willing to let microsoft cast my vote here

resolved: fpwd in a couple of weeks with whatever we have consensus on

<scribe> scribe: chris

Summary of Action Items

[NEW] ACTION: chris ask tpac organisers to reschedule webfonts to thur/fri at tpac [recorded in http://www.w3.org/2010/06/16-webfonts-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/06/16 15:15:27 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/John/erik/
No ScribeNick specified.  Guessing ScribeNick: ChrisL
Found Scribe: chris
Default Present: +1.781.970.aaaa, +1.443.895.aabb, +1.510.816.aacc, +1.425.882.aadd, +1.250.668.aaee, +1.206.324.aaff, jdaggett, cslye, +47.21.65.aagg, ChrisL, +31.70.360.aahh, +1.206.324.aaii
Present: +1.781.970.aaaa +1.443.895.aabb +1.510.816.aacc +1.425.882.aadd +1.250.668.aaee +1.206.324.aaff jdaggett cslye +47.21.65.aagg ChrisL +31.70.360.aahh +1.206.324.aaii
Found Date: 16 Jun 2010
Guessing minutes URL: http://www.w3.org/2010/06/16-webfonts-minutes.html
People with action items: ask chris organisers tpac

[End of scribe.perl diagnostic output]