Re: Just-Send-8 to ESMTP/MIME Transition

[John C Klensin <KLENSIN@xxxxxxxxxxxxxxx>]

>Hi John -- For a guy that claims to not be persuaded either way, you
>are overly full of arguments in favor of x-unkown;-)....\Stef

Stef,
  I didn't claim to not be persuaded.  I'm *very* persuaded.  I'm just
not convinced that the decision is ultimately very important. :-)

  *I* find it quite interesting that people can look at the same issues,
state the same arguments, and arrive at opposite conclusions.

  Let me try once more, then I will say nothing further about this
issue, one way or the other.

  I think the difference of opinion here depends on the understanding of
"private agreement among consenting parties".  To me, that means that
both sides better agree, somehow, about how to interpret the thing or it
isn't interpretable: one can't go to an external source for a definition
*adequate for interpretation*.  Current text aside, that is what
X-critters have always meant in practice:  if I get one (in SMTP, FTP,
etc.), I either have to know what the sender *meant* by it, usually down
to rather fine details, or I have to somehow throw up my hands (or take
a chance).  To at least some other people here, there is an assumption
that seems to imply formal negotiations and signed agreements.  It has
just never been that way.

Anyway, if something is going to appear to the right of 
  Content-type: text/plain; charset=
it is governed by MIME (RFC1341), not anything this WG does.  The WG
certainly can't change MIME in an informational doc.  Now MIME says
(section 7.1.1, middle of page 20 in the Postscript version):
   No other character set name may be used... without the publication of
   a formal specification and its registration with IANA...
and (Appendix F, section F.2)
   (The published specification must be an Internet RFC or RFC-to-be or
   an international standard.)

Now the intent of all of this was, I think, that, if something appears
without an X-, there should be a real definition.  Not "well, I couldn't
figure out what it was, so I labelled it 'unknown', you guess".  The
latter isn't a formal spec in my book; I would expect IANA to reject
such a registration request.

We have an interesting analogy to this in 822 mail.  822 requires that
times be specified with some sort of time zone indication.  Some systems
don't keep timezones as part of their basic calendar clock information.  
We normally expect them to make a plan to produce proper timezones
anyway.  Sometimes, someone gets lazy, and we see "22:59:41 LOCAL".  We
either flame them or learn to live with it.  We don't modify RFC822 to
say "if you can't figure out the local timezone, using 'local' is ok as
a transitional strategy": clearly, these folks should not be encouraged,
even if there are far more hosts who might benefit than there are in the
Internet "just send 8" historical community.

My preference for x- is based on the assumption that "unknown" is
unregisterable, or at least should be.  MIME seems to call for explicit
specification of *character sets*, not abbreviations for "I don't have a
clue, but I'm pretty sure it is text, maybe you can guess".  If that
reading is correct, then we have the following choices:

  -- Use x-, which does not require registration and which communicates
some of the tone of "better go looking for external information".
  -- Modify MIME itself to contain support for an "unknown" concept.
  -- Encourage, in the transition document, violation of the MIME spec
by using an unregistered value in the character set position that isn't
a character set.

Personally, I find the latter distasteful.  I don't like either the
timing dependency or the "transition provisions in the spec" character
of the second.  And that leaves...

As I said, no more from me on this one in this forum, although I do
reserve the right to suggest to IANA that "unknown" should not be
construed as a character set for purposes of registration.

      john