Subject: Re: [EAI] LANG, UTF-8, and POP3

From: Shawn Steele <[email-masked]>
Date: Wed, 23 May 2012 19:24:59 +0000

I've been ignoring the whole thread, but I don't get what LANG is for?  

If I'm receiving mail in UTF-8, then I get UTF-8 mail and all is fine, what's LANG do for me?

If I'm sending mail in UTF-8, then the server can send it with SMTPUTF8.  If it can't be forwarded it's no more stuck that current EAI stuff, so what's LANG for?

So, IMO, the LANG thing seems orthogonal to the EAI UTF8 support problem, so I don't get why it lives in this draft.

-Shawn

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 May 2012 16:55:07 -0400

> is fine, what's LANG do for me?

Primarily, it permits the server to deliver error message text
in the local language.  Whether that is a good idea or not
depends on the implementation model and, in particular, how one
breaks up MUA and IMAP/POP server responsibilities in that
particular UA model.

FWIW, I'm not a good person to be defending this because I have
long favored codes that are as specific as possible,
standardized text in a canonical/interchange language to the
degree needed to supplement those codes, and then local
translation in the client.  I.e., localized message strings
appear only in the UI and not on the wire, even when that wire
is between the two pars of a split UA.  But I've been very much
in the rough on most of the occasions when this, and similar
issues, have come up in the IETF.  That said, POP (especially)
is an extra-difficult case because, unlike, e.g., SMTP, it
doesn't really use codes -- all the information other than
"success" or "failure" is in the text.

Partially because of that and partially because I believe that
the fewer capabilities we insist that IMAP and POP servers and
clients support the sooner we will see working implementations,
I'd be pretty strongly opposed to any attempt to require LANG
support.  But I don't think the current spec does that.

> If I'm sending mail in UTF-8, then the server can send it with
> SMTPUTF8.  If it can't be forwarded it's no more stuck that
> current EAI stuff, so what's LANG for?

This is strictly between IMAP/POP server and the associated
client, not anything related to transport.  Remember too that
IMAP actually permits option/capability negotiation (POP sort
of, almost, does).
 
> So, IMO, the LANG thing seems orthogonal to the EAI UTF8
> support problem, so I don't get why it lives in this draft.

Where "this draft" is the IMAP spec?

    john

---

From: Shawn Steele <[email-masked]>
Date: Wed, 23 May 2012 21:04:35 +0000

> Primarily, it permits the server to deliver error message text in the local language.

I'd forgotten that :)

>>  So, IMO, the LANG thing seems orthogonal to the EAI UTF8 support 
>>  problem, so I don't get why it lives in this draft.

> Where "this draft" is the IMAP spec?

Yes, and I still see it as orthogonal to UTF-8 support.  Eg: IMO, this is a "localized error messages" feature, not a "deliver/receive UTF-8 mail" feature.  And, as you mentioned, it could be done on the client.  Additionally, there are some tools/forwarders that use POP or IMAP to grab mailboxes but aren't the actual end user client.  In those cases, it could even be kind of bad because it might end up at some intermediate language instead of the true end user's language.

I'd be happy if LANG was cut so we don't have to talk about it.  If there's enough interest, it could be its own draft.

-Shawn

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 May 2012 18:17:25 -0400

>> Where "this draft" is the IMAP spec?

First, please will everyone I've confused forgive me.  LANG is
in the POP3 spec but is not in the (our) IMAP spec.  So we are
talking about POP3 here, per the subject line.

> Yes, and I still see it as orthogonal to UTF-8 support.  Eg:
> IMO, this is a "localized error messages" feature, not a
> "deliver/receive UTF-8 mail" feature.  And, as you mentioned,
> it could be done on the client.  Additionally, there are some
> tools/forwarders that use POP or IMAP to grab mailboxes but
> aren't the actual end user client.  In those cases, it could
> even be kind of bad because it might end up at some
> intermediate language instead of the true end user's language.

I think those tools would be pretty stupid to specify a language
and, if they were implemented for that purpose only, to even
have the code there to support LANG.  From a client point of
view, it seems to me that it is quite harmless if not used.
 
> I'd be happy if LANG was cut so we don't have to talk about
> it.  If there's enough interest, it could be its own draft.

Personal view (the WG should debate this to the extent needed):
I'd prefer to just leave it there because it has been there for
quite a while now and the burden is on those who want to take it
out to convince the WG to do so.  Note in particular that LANG
appeared in RFC 5721 so, if we take it out, someone is
presumably going to ask us to explain why (and maybe show
experimental evidence that it is a problem).  I think we can
deal with that, but it is unlikely to be pain-free.  The optimal
time to get rid of it would have been sometime in 2009.  But I'd
support clear language that points out the disadvantages and
risks of trying to support it (most of which can be extracted
from our conversation in these four notes).

   john

---

From: [email-masked]
Date: Wed, 23 May 2012 17:51:35 -0700 (PDT)

> breaks up MUA and IMAP/POP server responsibilities in that

As a practical matter, localization has to happen somewhere, and there
are advantages and disadvantages to every possible location.

Putting it in the back end server has the advantage that it saves having to do
the work in what are often multiple clients. And the server is in the best
position to know what a given error actually means.

The main disadvantage is lack of flexibility - the server cannot respond to
local client conditions because it is usually unaware of them.

The conditions are flipped in the client case, of course.

THe one place I really don't like seeing it done is in the web service layer.
There are probably arguments for doing it there, but I've yet to hear one
that's I found compelling.

> is between the two pars of a split UA.

I agree that this is a superior model.

>  But I've been very much

The main problem with doing it on the client side is that a significant number
of clients are for whatever reason unwilling or unable to support localization
locally. I don't really understand this, but I'm not a client author.

The SMTP case needs to be broken down into SUBMIT and SMTP relay. SUBMIT is
close enough to IMAP that a similar model makes sense. But SMTP relay is a much
more difficult problem because it necessarily crosses administrative, local,
and even national boundaries. In addition to the problem of how the server even
becomes aware of the language preference across multiple hops, this creates
another one of those situations so common in email: Asymmetric cost/benefits.
Why should I care about internationalizing my SMTP server to a bunch of
languages my user base doesn't use? And similarly, why should someone in some
other country give a crap about making my users happy?

But even though the server-side model doesn't really make sense for SMTP relay,
the clients capable of internationalizing either SMTP responses, let alone DSNs
or MDNs, are very rare. Makes no sense to me, but again, I'm not a client
author.

> support.  But I don't think the current spec does that.

I agree.

				Ned

---

From: "Jiankang YAO" <[email-masked]>
Date: Thu, 24 May 2012 11:17:09 +0800

Why LANG was there since UTF-8 is enabled?
I think that one reason is that:
Unicode includes many languages' characters such as Chinese, Korean, and Russia.....
If there is a LANG command, the server and client can talk with the languages preferred by client and server.
Otherwise, the server may respond with Korean characters, but the user of the client may not know it and say "pls send me with Chinese".

Jiankang Yao 

----- Original Message ----- 
From: "Shawn Steele" <[email-masked]>
To: "John C Klensin" <[email-masked]>; <[email-masked]>
Sent: Thursday, May 24, 2012 5:04 AM
Subject: Re: [EAI] LANG, UTF-8, and POP3

> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: Shawn Steele <[email-masked]>
Date: Thu, 24 May 2012 16:56:51 +0000

It had come up before & I'd forgotten :)  I'm happy with or without it, whatever's easier.

-Shawn

-----Original Message-----
From: Jiankang YAO [mailto:[email-masked]] 
Sent: Wednesday, May 23, 2012 8:17 PM
To: Shawn Steele
Cc: John C Klensin; [email-masked]
Subject: Re: [EAI] LANG, UTF-8, and POP3

Jiankang Yao