issue related to publicatio resource locations in Publications specification

[GoogleCodeExporter]

Specification: Publications

Sub-clause: 6.3 Publication Resource Locations

Issue: All Publication Resources must be located in the EPUB Container, with 
the  exceptions of Audio and Video. But usually 2byte fonts are so big like 
12MB or 15MB. It means Korea ebook service vendors are considering displaying 
each ebook with the remote font server. Could you think over the remore reource 
items?

Original issue reported on code.google.com by zzos...@gmail.com on 16 Mar 2011 at 9:29

[GoogleCodeExporter]

Original comment by markus.g...@gmail.com on 18 Mar 2011 at 10:12

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by markus.g...@gmail.com on 18 Mar 2011 at 10:15

• Changed state: Acknowledged
• Added labels: Type-ReviewComment

[GoogleCodeExporter]

I think that serving fonts from a remote server would be reasonable and easily 
doable (especially now when a Reading System supports WOFF format), and agree 
that there may be use cases when doing this would be a benefit.

Original comment by vladimir...@gtempaccount.com on 23 Mar 2011 at 8:11

[GoogleCodeExporter]

I have contacted Koreans, Taiwanese, and Japanese.  Most of them feel that 
remote fonts should be allowed.

One possible reason for disallowing remote fonts is the same origin restriction 
for fonts, but I do not think that it is a good reason.  In the latest WD of 
CSS Fonts, the same origin restriction for fonts
is marked as a feature at risk.  See http://www.w3.org/TR/css3-fonts/

Moreover, the WD has a para as below:

    Some implementers feel a same-origin restriction should be the
    default for all new resource types while others feel strongly
    that an opt-in strategy usuable for all resource types would
    be a better mechanism and that the default should always be to
    allow cross-origin linking for consistency with existing
    resource types (e.g. script, images). As such, this section
    should be considered at risk for removal if the consensus is
    to use an alternative mechanism.

webkit does not implement this restriction.  See the thread 
starting at

    http://lists.w3.org/Archives/Public/www-style/2011Mar/0280.html

The minutes of the CSS WG F2F about this topic is available at:

http://lists.w3.org/Archives/Public/www-style/2011Mar/0280.html

I heard from Ishii-san that this topic is being discussed at the W3C
WebApps WG and the W3C TAG, and that the CSS WG is waiting for the
conclusion in these groups.  I believe that IDPF should not introduce 
its own restrictions on remote fonts.

Original comment by eb2m...@gmail.com on 29 Mar 2011 at 4:53

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I would like to provide a clarification on same origin restriction:
Currently, same origin restriction (SOR) is described by the HTML5 and CSS3 
Fonts module. CSS3 Fonts do not mandate same origin restriction, it just 
defines what it means. However, both Firefox (ver. 3.5 and higher) and IE9 
implemented SOR for all font resources, and the WOFF spec mandates it for WOFF 
files.

SOR means that by default the use of downloaded fonts is allowed only if both 
the fonts and the HTML content (but not CSS) came from the same origin - e.g. 
same domain, or same local storage / device / file (in case of EPUB). This 
restriction can be relaxed using cross-origin resource sharing (CORS) header, 
where the use of fonts coming from a different domain would be allowed only if 
that particular domain provides corresponding "Allow-origin" header. 

"SOR by default" condition makes it easy for authors to comply with the most 
font license requirements - it means that authors don't have to do anything if 
they do not want to allow others to use the fonts they licensed. However, 
someone who licensed fonts to be used on multiple different domains can host 
them in one location and allow their use on multiple different domains that the 
fonts are licensed for. Any other site will not be able to use the fonts - this 
is done to prevent hot-linking and bandwidth/resource theft. 

The argument was made that same origin restriction is good in general (because 
it gives authors and domain owners full control over the use of their 
resources) and should be applied for all new resource types going forward. 
However, this doesn't solve the same problems for existing data types such as 
images and scripts - currently these types of resources can be linked to with 
no restrictions. If the domain owner doesn't want images and scripts be 
linkable - they would have to jump through many hoops (e.g. implement referrer 
checking, which is unreliable) to protect their bandwidth and resources from 
hot-linking.

An alternative proposal that is being discussed by W3C is to establish a 
"From-origin" header mechanism that would allow domain owners to opt-in for 
origin restriction for any resource types. E.g. an image without any header can 
be linked from anywhere, but if image comes with "From-origin: same" header - 
it would anly be allowed to be linnked from the same origin. This mechanism 
would therefore be global and can be applied for any resource type. It would 
also, at the same time, allow the new resource types be protected with SOR by 
default if desired, with "From Origin" header (instead of CORS) being used as a 
mechanism to relax the default restriction.

This "From Origin" proposal is very recent and is being discussed at various 
W3C groups. If and when this mechanism is developed - the current use of CORS 
as a way to relax same origin restriction will change, and this is why CSS3 
Fonts spec has "at-rsik wording" added to it.

Original comment by vlad.lev...@gmail.com on 13 Apr 2011 at 6:06

[GoogleCodeExporter]

This issue was deferred to a later revision by the WG on the 2011-04-21 call. 

Thread: 
http://groups.google.com/group/epub-working-group/browse_thread/thread/b18c55108
7fd492e

Original comment by markus.g...@gmail.com on 20 Apr 2011 at 10:41

• Changed state: Deferred