[Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses

[Martin Duerst <[e-mail]>]

Hello Alexey,

I have looked at the draft. I'm not totally familiar with
all the details of email transmission, but will comment
mostly from an LTRU perspective. I have cc'ed the LTRU
WG, because I think your draft makes a good usage example
for the work of the LTRU WG, and some people may be able
to provide more feedback.

At 00:27 06/08/15, Alexey Melnikov wrote:

>       Title           : SMTP Language Extension
>       Author(s)       : M. Gahrns, A. Melnikov
This list of authors and the one in the draft seem to be
out of sync, probably a clerical error?

>       Filename        : draft-melnikov-smtp-lang-05.txt
>       Pages           : 0
This seems to be some administrative error, too, probably
a tool that counts drafts without explicit page breaks as
0 pages (I'd understand 1 page, 0 is really weird).

>       Date            : 2006-8-2


Section 3: "It also recommends that server recognizes languges that
   have multiple different tags (for example "ru" and "rus")."

   This is a bad idea. RFC 3066, and its successor RFC 3066bis
   (draft-ietf-ltru-registry-14.txt, approved by the IESG and in
    operation) both make it very clear that for languages that
   have both two-letter and three-letter codes, only the two-letter
   codes are used.

Please update the reference to RFC 3066 to RFC3066bis.

For language fallback, I suggest you have a look at
http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-15.txt
(also IESG-approved). This gives you the (basic) "language-range" ABNF
construct that includes the "*" wildcard.

Also, it seems that the matching going on on the server when the
client issues a LANG command (e.g. in Example 5) is very close to
and can (and should) be described in terms of Section 3.4, Lookup,
of the above draft. The only difference I see is that Section 3.4
requires a solution (maybe default) in all cases, whereas in your
case, the default if no matching language is found is not i-default,
but "no change" or in other words, "previously selected language".


I think the discussion of mul and und is overkill. There is no
interoperability problem if the client uses 'mul', it is just
a language that's not supported. Suggesting, as in Example 2,
that the server has specific code for that issue is a bad idea,
it will tend to make the server more complex than necessary.


Somewhere in example 1, probably in the comment that starts with
"< Once the client changes...", you should say that the example
here doesn't show accents because they cannot be represented
in this format, but that accented characters, encoded in UTF-8,
would be present in the actual protocol exchange.


Note 1: This is in part overkill, and in part incorrect.
If you do fallback on the server, then you have to leave
the decision to the server (or the server programmer or
administrator). There is no a-priori difference between
the special prefixes i- and x- and two-letter and three-
letter prefixes. It's very well possible that for i-foo-bar
and i-foo-baz, there is a mutually intellegible i-foo on
the server. The server will most probably only have i-foo
if the mutual intellegibility is a reasonal assumption.
On the other hand, for some people, zh-Hans (Chinese
written in simplifed script) and zh-Hant (Chinese written
in traditional script) are not mutually intellegible,
and so it may be a bad idea to make "zh" available on
the server. I think that if you refer to the abovementioned
two drafts, that should be enough.

Aside: You could get rid of server-side fallbacks if you
could assume that the server can always send the complete
list of available languages. However, I think this would
be a bad idea, because a) there may be dozenz or hundreds
of languages, and just sending the list may present somewhat
of a scalability problem, and b) it may be much easier
computationally for the server to check for the existence
of a requested language (or it's fallback) than to list
all languages available (which may require an extensive
search for files in a large number of directories).


For the LANG command, you only allow one language.
You could extend that to use a language priority list,
but this is not really necessary, the client can
simulate a language priority list by using successive
requests until one of them is successful.

On the other hand, for the LANG parameter for the MAIL
command should allow a language priority list. The reason
for this is that (if my understanding is correct), this
parameter is passed on along the relay chain of SMTP servers,
and is supposed to go back to the original sender, and
using a list increases the chance that there is something
at the relevant server that can be understood by the
originator.

I'm also not completely clear on / happy with the following
paragraph:

>>>>
   If the message is relayed to another SMTP server that supports LANGUAGE
   ESMTP extension, the MTA acting as the client MUST check if the receiving
   MTA lists the language specified in lang-param ("requested language") in
   the list of supported language tags in LANGUAGE EHLO response.  If the
   receiving MTA either lists the requested language or doesn't list any
   language tag (i.e. the receiving MTA is unable to list languages it
   supports) the sender MUST issue LANG command for the requested language.
   After that, regardless of the result of LANG command, the client MTA MUST
   specify LANG parameter in MAIL command.
>>>>

After repeated reading, I think this is okay, but some clarification
might help. In particular, it should be pointed out that trying to
use the LANG command is done so that potential error messages in
this relay step can be sent back to the original sender in the
appropriate language if possible.

Also, on a first reading, I was thinking that if the desired language
wasn't available, the LANG parameter would no longer be used.
I think the reason for this misunderstanding is that the last two
lines come very late. I think it would be easier to understand if
the paragraph started out as follows:

   If the message is relayed to another SMTP server that supports the
   LANGUAGE ESMTP extension, the MTA acting as the client MUST do
   the following two things, in the following order:
   1) Attempt to set the language of server responses to the requested
      language(s).
   2) Independently of whether 1) is successful, use the LANG
      parameter on the MAIL command to transmit the requested
      language(s) to the next relay.

If you think more explanations and details for 1) are needed, they
should come after this list.


Regards,     Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[e-mail]     


_______________________________________________
Ltru mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ltru