Let's apply Occam's razor to this discussion and the specification!
From: "The American Heritage Dictionary, 2nd College Edition"
Ockham's razor also Occam's razor: n. A rule in science and philosophy
stating that entities should not be multiplied needlessly, which is
interpreted to mean that the simplest of two or more competing theories
is prefereable and that an explanation for unknown phenomena should
first be attempted in terms of what is already known. [After William of
Ockham (1285?-1349).]
As I see the results of this tspecials discussion, 2 groups have 2
different assumptions and offer 2 analogous proposals for changes to the
RFC and implementations, based on their assumptions.
The Klensin-Rose group assumes tspecials need contain exactly "?", "/"
and "." (and no more) and proposes the following changes:
a. add a "tutorial note" to explain tspecials,
From: John C Klensin <KLENSIN(_at_)infoods(_dot_)mit(_dot_)edu>
It is, at worst, a small irritation that takes only a tad of
extra effort to get right, no matter how we ultimately define "right".
And the next version of the MIME RFC should probably get a tutorial note
a.^^^^^^^^^^^^^
or two explicitly pointing out the implementation implications of
whatever plan is chosen.
b. retain "." in tspecials,
c. make all RFC examples consistent with the 3 character tspecials,
d. fix all implementations to adhere to the new RFC.
From: Marshall Rose <mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us>
I am against change for change's sake. You have yet to provide a reason
b.^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
why having dot in tspecials is a functional problem. All you can point
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
to is a typo in an example.
c.^^^^^^^^^^^^^^^^^^
[...and...]
Give me a break. People either read the spec or they don't. So they
miss it. Fine, tell the implementor and they'll fix it.
d.^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The Crispin group assumes tspecials need contain exactly "?" and "/" (and
no more) and proposes the following changes:
a. remove "." from tspecials,
b. make all examples consistent with the 2 character tspecials, and
c. fix all implementations to adhere to the new RFC.
From: Mark Crispin <MRC(_at_)cac(_dot_)washington(_dot_)edu>
`?' and `/' are in tspecials for a reason. There is no reason for `.'
a.^^^^^^^^^^^^^^^^^^^^^^^^^^
to be in tspecials. What's more, the MIME document has examples as if
^^^^^^^^^^^^^^^^^^ b.^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
`.' was not in tspecials.
^^^^^^^^^^^^^^^^^^^^^^^^
[...and...]
Some history: I invented tspecials (`token specials') in the BNF I wrote
for MIME back in the early days. RFC-822 specials weren't suitable,
since there were additional characters that we needed to forbid in
unquoted MIME tokens. I expressly did not include dot in tspecials, so
that it could be used unquoted. For some reason it was added, and now
there are interoperability problems.
c.^^^^^^^^^^^^^^^^^^^^^^^^^
In brief, the Klensin-Rose group proposes the following changes:
a. add a "tutorial note" to explain tspecials,
b. retain "." in tspecials,
c. make all RFC examples consistent with the 3 character tspecials, and
d. fix all implementations to adhere to the new RFC;
and the Crispin group proposes the following changes:
a. remove "." from tspecials,
b. make all examples consistent with the 2 character tspecials, and
c. fix all implementations to adhere to the new RFC.
Frankly, both solutions to the current RFC's problems induce change (and,
happily, both groups propose a set of minimal changes which would make
the RFC and implemenations consistent with their assumptions). The 2
proposals can be summed up as:
1. Klensin-Rose: "." is needed in tspecials;
tspecials need only be "?", "/", and ".".
change the RFC and implementations to support 3 character tspecials.
2. Crispin: "." is unnecessary;
tspecials need only be "?" and "/".
change the RFC and implementations to support 2 character tspecials.
For the assumptions they make, both proposals are Occam-compliant (that
is, they address the complexity of the problem without introducing any
unnecessary complexity of their own).
The key question, I believe, is which assumption is correct, i.e., does
tspecials need contain "." or not? To resolve this question, the
contributor(s) who added "." to tspecials should explain why/if it's
needed.
If no such explanation is forthcoming, then Occam's razor and the current
implementations which now seem to work fine without "." in tspecials
suggest "." is superfluous and should be removed from tspecials. If this
2 character tspecials is the chosen option, perhaps a "tutorial note"
explaining what needs and needs not be in tspecials could be added to the
RFC to avoid further confusion.
My .2 (yes, .2) cents,
= Joe =