- From: <ned.freed@mrochek.com>
- Date: Wed, 16 Jan 2002 08:36:30 -0800 (PST)
- To: Jacob Palme <jpalme@dsv.su.se>
- Cc: discuss@apps.ietf.org, langtrans@salut.nu
> At 17.15 -0500 02-01-15, Keith Moore wrote: > >how present mail UAs handle this is irrelevant, because they > >don't handle any other scheme for language selection either. > > > >the only question for IETF is - what's the best way to do this > >in MIME protocol? and nobody has come up with a better alternative > >(so to speak) than multipart/alternative. > When the MIME standard was introduced, the handling by > present mail was central in the design of mail. For example, > the QUOTED-PRINTABLE format was chosen, because messages > encoded in this format would be at least partly readable > for recipients with old mailers. First of all, the primary reason for including encodings in MIME was to insure backwards compatibility with deployed messaging _standards_, not deployed messaging _systems_. It is one thing to avoid breaking implementations coded in good faith to the standards of the time, it is quite another thing to attempt to cater to implementations that weren't coded very well to begin with. Second, in the case of quoted-printable, we also attempted to finesse the backwards compatibility issue somewhat by defing an encoding that would be partly readable. However, this attempt was, in retrospect, a nearly complete failure. In hindsight, it may have been more trouble than it was worth. In summary, you win few if any points in this debate by comparing what you're proposing to quoted-printable. > Why should not a graceful downgrading to existing mailers > be important for language translation in e-mail, when > it was so very important in the design of MIME itself? See above -- the comparison isn't as apt as you seem to think, and even if it were apt you're basically saying we should repeat something that didn't work the first time. An additional point. The pent up demand for MIME in the early 90s was enormous. A standardized message format for internationalized text and material other than text was urgently needed. This more than anything else drove the deployment of MIME support, and even then deployment was pretty slow. By contrast, the demand for language translation support in email is minimal at best. I know it is something you want very badly, but how many other people want it? Uptake of other MIME enhancements or extensions that require substantial UA changes has been sporadic at best, and seems largely related to the perceived needs of the vendors themselves, not a desire for full standards compliance. Because of this I fear that any proposal you make (other than one where you simply use multipart/mixed rather than multipart/alternative) is going to suffer the same fate as the attempt to use content-language fields to select between alternative parts. Simply put, while what you are doing is arguably a legitimate standards exercise, I see little chance of change in the real world because of it. There are, however, two alternate approaches that immediately come to mind that might work better: (1) Do some coding work yourself. There are plenty of open source UAs in use today and several other UAs provide hooks for extensibility. Have you tried coding honest to goodness alternative language support for these? Doing so and proving the value of such capabilities might help your cause. (Several MIME compliant mail systems were released at the same time the MIME RFCs came out. This helped enormously in getting MIME started.) (2) Work the problem from the other end. Efforts are under way to develop and deploy facilities for determining the recipient characteristics and sending messages that match those characteristics. I don't know if these efforts are going to be successful, but if they are and language selection is included in the initial rollout you might get something deployed, albeit vicariously. There are probably others, not to mention variants on these themes. Sometimes the way to win is not to play. Ned
Received on Wednesday, 16 January 2002 12:48:55 UTC