RE: .webfont Proposal 2

>-----Original Message-----
>From: Thomas Lord [mailto:lord@emf.net]


>Such solutions work well for some applications,
>that's true.

Why they would work less well here remains unexplained.

>> 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;
>
>You normally would not or want to do so.  Normally
>you would want to use a file archive tool and format
>that records file meta-data such as modification time.
>
>MIME is a good choice for a meta-data wrapper, though,
>because it is flexible, already extensible in an orderly
>manner, and parsimoniously consonant with the design of HTTP.

That it is a good choice does not make it better for this purpose or any other.
Asserting its conveniently ill-defined 'parsimonious consonance' is unhelpful.
Why this is a relevant criteria and how to measure it is also unexplained.

The fact that MIME is not widely used for this purpose today should indicate that such
'consonance', however relevant it might seem in theory, is not so in practice.

>> nor did anyone ever send me a file archive as a collection of MIME
>parts vs. a single zip.
>
>Typically people send files as email attachments.  Your
>Mail User Agent is acting as the encoder / decoder,
>as I'm sure you are aware.

If MIME was so well suited to encoding file archives, one would expect
internet mail clients to expose such a feature and do so routinely since it is
a very common scenario in practice. That they generally do not and zips are
generally used for this purpose is a valid data point imo.

>Either solution can "technically work" but they
>make distinct trade-offs.  I've explained why I think
>the MIME trade-offs are more appropriate to the design
>context.

You have merely asserted it was more appropriate and backed up your assertion using
more assertions.

>
>> So, fwiw, I don't think parsing and decoding MIME adds
>> any value here
>
>As I explained, among the relative advantages are
>parsimony (c.f. HTTP), orderly extensibility, and
>the avoidance of unneeded meta-data fields.


Each MIME part requires header data that would be unnecessary with a zipped archived
so it is unclear what metadata is saved, how much is saved, or why this type of metadata is
worth saving more than this other one. Why any of this is relevant to this specific proposal is
also unclear.

Also unclear is what is 'disorderly' about the extensibility of the alternative, when, how and why that is
a criteria for this proposal, how MIME addresses these specific scenarios and does so in a clearly better
manner than anything the current serialization could achieve.

As for the importance of these alleged advantages to the success of this proposal, it is asserted but not
demonstrated.

>> and I don't buy that
>> 'consonance with the design context' mandates standard
>> internet mail encoding for web fonts at all.
>
>It is clear that you do not but why or why others
>should agree with you is unclear.

Since you're the one demanding a change, it is up to you to obtain agreement from
authors and implementers. As I have no objection to this part of their proposal, I
surely have no need to get agreement from them.

>
>> The proposed solution makes it much simpler to
>> create these files, edit them, and generally
>> handle them both manually or programmatically.
>
>Do you envision, for example, people creating
>a font for web use, writing the metadata file,
>and then using, say, a "zip" program to package
>the results for distribution on the web?

Zip archives are so common it does make it easy for web authors to
examine such files, for developers to debug, for admins to audit them, as well
as easier for tool vendors to support them given that many already support
similar formats. From JARs to ODF to KMZ and many others, the practice is very common.

Implementers and users alike are likely to prefer 'consonance' with common real-world practice
over unclear and largely theoretical benefits stated by one individual. No one needs to make a case
that the proposed serialization scheme works well in practice. You, however, need to make a compelling
case that your alternative will work much better than this common practice and why. I suggest that
repeating assertions of 'parsimonious consonance' will be unhelpful in making that case.

>
>Among the disadvantages of such a plan is that on
>most systems, the ordinary way of creating such a
>file archive or unpacking one will record and restore
>file attributes such as a user ID.

If one expects that most people will rarely, if ever, create such files
then this implementation detail should be of no concern.

>
>It is a simple enough matter, on the other hand,
>to write an "encode/decode" program pair for a
>MIME format.

Encoding MIME is trivial. Decoding it can be, however, a lot less so as anyone
who ever had to parse real-world MIME data knows. One could simplify this by
defining a very strict MIME profile for web font purposes - e.g. 8bit encoding only, limited header set -
but that is extra spec and design work beyond the current proposal, it will require specific encoders
to be written etc. Solutions that require more design work as well as more code to achieve interop
ought to be less interesting than alternatives that do not.

>
>
>> 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).
>
>I am at a bit of a loss as to why you think
>MIME is unacceptable while, say, zip is not.

I never said it was 'unacceptable'. Zip archive formats are widely supported and used
by many applications for similar purposes. We know from experience the pattern works well,
and the professional user base who will deal with those resources in their daily work
is already both familiar and comfortable with it. As I am not able to make any of these
claims about raw MIME archives, I am bound to be less comfortable with it than I am with using
a simpler, very well established pattern.

>It is unclear what you propose to form agreement
>about.  The phrase "structure and content" is vague
>and you seem to specifically exclude serialization
>from being an aspect of "structure and content".

Orthogonality does not mean exclusion. Serialization does not matter if font vendors
are not interested in this proposal and no browser vendor wants to implements it. These are
the high-order bits.

I will therefore not discuss this issue further unless someone demonstrates clear purpose and benefits
to making this change. It doesn't appear you can make this case.


>Perhaps it would be more effective if you offered up
>a specific proposition to which implementers, foundries,
>and the larger community, could express agreement or
>disagreement.

I suggested leaving the proposed serialization as is. MIME adds nothing and costs much for no good reason. I don't
know how to be more specific than that. But if you're saying that the only reasonable way to disagree with you is to
make a full format proposal *and* get it accepted, then I suggest that parsimonious consonance with humility
may get you a lot further than MIME :)

Received on Thursday, 16 July 2009 19:27:31 UTC