[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Martin Duerst wrote:


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.

Thank you for your feedback Martin.
Draft draft-melnikov-smtp-lang-05.txt is a revision of a draft that expired in 2001 (before LTRU was chartered) and I haven't been following LTRU. 


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?
No. Mike Garhns written the original IMAP LANGUAGE extension, this document is based on it. 


     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).

I think you are right.


     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.

Ok, I've removed the paragraph.


Please update the reference to RFC 3066 to RFC3066bis.

Done.


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".
Ok, this change would require some editing work on my part. I've added to my todo list. 


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.


Ok, removed.


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._
_
The server is actually [re-]using the same error code, but the error text might be different. This is actually quite useful for debugging implementation errors. However SMTP implementations are not required to do that anyway. 


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.*
*


Done.


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 reasonable 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.

Thanks. I removed the note.


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).*
*
Agreed. The list of all available langues is not returned for the reasons you stated. 


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.*
*


Actually, the LANG command already allows for priority list.


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.

Ok, this is a valid point. I will try to do this in a future revision.


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.

I've clarified this, thanks.


Also, on a first reading, I was thinking that if the desired language
wasn't available, the LANG parameter would no longer be used.*
*
Yes, that was my original intent. But this would change, if the draft is changed to allow for priority list. 


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.



_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.