[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@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru