ietf-822
[Top] [All Lists]

tspecials changes (was: MAJOR BUG IN MIME)

1992-07-03 12:29:34
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 =

<Prev in Thread] Current Thread [Next in Thread>