Philosophically, this may be the crux of the issue (operationally, it
may not be interesting).
This may be a matter of personal taste, but, when it comes to
networking, I prefer not to have philosophical arguments. I just want
things to *work*.
Many people construed the "no transport
modification" discussion as implying that any gateway that could
properly handle RFC822 (regardless of what was on the other side)
without loss of headers would not have to be modified to adequately pass
MIME. The BITNET gateways can properly handle RFC822 (at least in the
Internet->BITNET direction) but may need modification because the format
on the other side isn't RFC822 but a clone derived from an orderly
transformation.
What, exactly, would need to be changed?
# I.e. if the header says
# "us-ascii", but the "u" is 0xa4 (hex a4), then the program could guess
# that it was converted to EBCDIC.
Needs a little refinement (e.g., to check for 0xE4 as well as 0xA4),
but has potential, I think.
Oops, yes, you're right. I was just trying to illustrate the idea,
rather than writing a full spec. (For those of us that don't know
EBCDIC: 0xE4 is upper-case "U".)
At the risk of leaping headlong down the
slipperly slope, five minutes of analysis suggests that, if we were
willing to impose one constraint on ourselves-- that character set names
must always contain "-" in one of the first four positions and may not
contain P there
Whoa! Hold on, hold on. I only seized upon the "u" in "us-ascii"
because it was a cute way of illustrating the solution. The actual
way of doing it would be for the automaton to start parsing the
message, assuming at first that it was in EBCDIC. If the message was
indeed in EBCDIC, it would be able to parse the headers. I.e. it
would recognize the string "Content-Type:", and so on. But if the
message was in ASCII (unlikely in the EBCDIC world?), it wouldn't even
be able to start parsing. So it could tell right off the bat that it
wasn't EBCDIC.
If we could make
a few specific constructive suggestions, rather than just suggesting
that solutions exist, it would probably help a lot.
Agreed. (Who could be the liaison? John?)
I should mention that I have doubts about the "trick" that I proposed.
Specifically, when an automaton determines that a message has been
converted to an EBCDIC, how is it to know *which* EBCDIC it was
converted to? Or is this not an issue? I don't have enough knowledge
about the various EBCDICs.
Erik