RE: .webfont Proposal 2

>-----Original Message-----
>From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf
>With all due respect to Bert Bos, I hope that
>you will instead reconsider using MIME.   For
>most practical purposes, you can regard MIME
>format as a compressible "directory archive"
>so most reasons you might have for choosing a
>file archive format are also reasons for choosing
>MIME.
Many successful file archive formats do not choose MIME e.g. JAR files, which
bind together binary files together with one or more manifests and XML descriptors.
Such solutions work perfectly well in practice. I can create, read and edit a zipped
file archive right now on any of my machines running on three different OSs. I honestly don't
know how I would convert a directory to MIME on any of them or why I'd even want to do it;
nor did anyone ever send me a file archive as a collection of MIME parts vs. a single zip.
That it could technically be done that way does not warrant avoiding a common, familiar and quite usable pattern.

So, fwiw, I don't think parsing and decoding MIME adds any value here and I don't buy that
'consonance with the design context' mandates standard internet mail encoding for web fonts at all. The proposed
solution makes it much simpler to create these files, edit them, and generally handle them both manually or programmatically.

Lastly, I don't think a web font format should require client software that wishes to support them to include a MIME parser
(HTTP is MIME-like but not strictly MIME-compatible). Granted, this may be colored by a former life maintaining a server-side
MIME parser for a webmail system.

Ultimately, the priorities should be to 1) define structure and content 2) secure agreement and commitment from implementers, foundries etc.
How the data is serialized on the wire/on disk is for all intents and purposes orthogonal to these priorities and less interesting imo.
At a minimum, requiring MIME or XYZ or FOO encoding will not make it any easier to secure agreement on content or support so it shouldn't matter at
this stage.

Received on Wednesday, 15 July 2009 21:08:00 UTC