Alex, maybe it doesn't matter much, but here's the problem in another view.
(Mail is _not_ my strong point, I freely admit it, but I've suffered enough with MSIE/outlook trying to send HTML documents from my server that at least I've hit enough problems to know it's not simple.)
Servers can negotiate which pages to return based on the AddLanguage and content handlers (Apache at least).
They can chose a set of templates to return to the user, with the right content heading to allow display in that browser. It's up to the browser to take the content header and do soemthing with it. But it's up to the server to send the right content header (and to the mailer program to put the right one on).
This is one-directional. The browser asks for a file, the server decides which to send, the browser displays it.
We've added another layer to this. We want to send content BACK to the server, that is then stored, processed or sent out. The browser sends a content header, the server responds to it (maybe) but then it's "lost".
We have a server running in a language (probably english). It's hosting pages in primarily Arabic (based on configuration, content handlers, whatever). Data coming in to the scripts is in arabic, and the content codes sent are in Arabic. What happens if an English user connects, or tries to read the sent file? If the wrong output set is loaded into the browser, you'll get gibberish.
If a user logs on in an arabic browser, requests the arabic templates, then attempts to send an English message, how on the other end do you know what to do? (assuming both users are on the same system?).
Or, the scripts have accepted the raw data from the browser, which is in Arabic. These character codes are fine, the server just stores them. Now, the file is sent, but without a content header on the mail message the end user has no idea what language they are in.
What if the user connects in Arabic, but the mail message was coded in English? Should the mail program send the English template set as an override, and force the browser to go get the characters, or just present the gibberish?
Do you see the potential problem? We aren't just talking server negotiation with the browser for a user session, we are then taking the result of that session, and sending it out into the world. Or, we are accepting something from the rest of the world, and trying to read it.
Maybe there isn't a problem, and all this has been incorporated into the base protocols. But, somehow I don't think so <G>.
Maybe at the least the system has to add a content header into the mail messages to allow proper handling?
such as:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
or:
Content-type: text/plain; charset=us-ascii; x-mac-type="54455854";
x-mac-creator="4D4F5353"
Content-transfer-encoding: 7bit
X-Accept-Language: en
I ran through my mail files, and not all this information is added to every message. Some, MIME-type mailers add this. But, files going through the sendmail system from a program pipe only have what is manually added to them.
(Mail is _not_ my strong point, I freely admit it, but I've suffered enough with MSIE/outlook trying to send HTML documents from my server that at least I've hit enough problems to know it's not simple.)
Servers can negotiate which pages to return based on the AddLanguage and content handlers (Apache at least).
They can chose a set of templates to return to the user, with the right content heading to allow display in that browser. It's up to the browser to take the content header and do soemthing with it. But it's up to the server to send the right content header (and to the mailer program to put the right one on).
This is one-directional. The browser asks for a file, the server decides which to send, the browser displays it.
We've added another layer to this. We want to send content BACK to the server, that is then stored, processed or sent out. The browser sends a content header, the server responds to it (maybe) but then it's "lost".
We have a server running in a language (probably english). It's hosting pages in primarily Arabic (based on configuration, content handlers, whatever). Data coming in to the scripts is in arabic, and the content codes sent are in Arabic. What happens if an English user connects, or tries to read the sent file? If the wrong output set is loaded into the browser, you'll get gibberish.
If a user logs on in an arabic browser, requests the arabic templates, then attempts to send an English message, how on the other end do you know what to do? (assuming both users are on the same system?).
Or, the scripts have accepted the raw data from the browser, which is in Arabic. These character codes are fine, the server just stores them. Now, the file is sent, but without a content header on the mail message the end user has no idea what language they are in.
What if the user connects in Arabic, but the mail message was coded in English? Should the mail program send the English template set as an override, and force the browser to go get the characters, or just present the gibberish?
Do you see the potential problem? We aren't just talking server negotiation with the browser for a user session, we are then taking the result of that session, and sending it out into the world. Or, we are accepting something from the rest of the world, and trying to read it.
Maybe there isn't a problem, and all this has been incorporated into the base protocols. But, somehow I don't think so <G>.
Maybe at the least the system has to add a content header into the mail messages to allow proper handling?
such as:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
or:
Content-type: text/plain; charset=us-ascii; x-mac-type="54455854";
x-mac-creator="4D4F5353"
Content-transfer-encoding: 7bit
X-Accept-Language: en
I ran through my mail files, and not all this information is added to every message. Some, MIME-type mailers add this. But, files going through the sendmail system from a program pipe only have what is manually added to them.
