On Dec 28, 13:55, Ned Freed wrote:
[ Portion Deleted ]
}It is a MAJOR lose-lose for me -- my software doesn't know anything about a
}content-type of x-uuencode, which in turn can lead to situations where things
}get doubly encoded (we sometimes encode things that don't necessary need
}encoding to get non-MIME gateways to see them as attachments).
}
}Moreover, supporting
}
} Content-type: application/x-uuencode;
} real-content-type=whatever/whatever
}
}would be very difficult for me to do, and if I ever do support I would
}have to implement it as a low-level, non-reversible transform into:
}
} Content-type: whatever/whatever
} Content-transfer-encoding: x-uuencode
I tend to think of UUENCODE as application/x-uuencode, and leave this as a
"viewer" problem. This isn't elequent by any streach, but it doesn't allow
UUENCODE as a CTE to become "SEP" (Somebody Else's Problem).
It is much easier for users to intergate a "viewer" into their Mail env than
another CTE type, which is typically a vendor's problem.
--
Cheers!
[ psr ]