[EAI] #1495 draft-ietf-eai-smtpext-06.txt 2.5. Using the ALT-ADDRESS parameter => new title
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EAI] #1495 draft-ietf-eai-smtpext-06.txt 2.5. Using the ALT-ADDRESS parameter => new title



Harald Tveit Alvestrand <harald at alvestrand.no> writes in gmane.ietf.ima:

> 1495 SMTPEXT 2.5/2.6: Reply code used on DATA
> Text proposed in -06.

Suggestion on diff format.  This is mostly editoral. Discussion follows.

-----------------------------------------------------------------------------
--- draft-ietf-eai-smtpext-06.txt	2007-06-05 06:40:53.000000000 +0300
+++ draft-ietf-eai-smtpext-06.txt-1495	2007-06-17 19:23:49.000000000 +0300
@@ -450,13 +450,18 @@
 
    address before xtext encoding.
 
-2.5.  Using the ALT-ADDRESS parameter
+2.5.  Using the ALT-ADDRESS parameter and message downgrading
 
    A message containing non-ASCII envelope addresses or header fields
    MUST NOT be sent to an SMTP server which does not support UTF8SMTP.
    Such a message MAY be rejected due to lack of the ALT-ADDRESS as
    discussed in section 2.2 of this document.
 
+   [EAI-utf8header] specifies "UTF8SMTP message" which requires
+   UTF8SMTP support.  Such a message MUST NOT be sent to an SMTP server 
+   which does not support UTF8SMTP. Such a message MAY be rejected due 
+   downgrade failure or lack of the downgrade support.
+
    When messages are rejected because they require UTF8SMTP, response
    code "550" is used, defined in [RFC2821], meaning "mailbox
    unavailable".  If enhanced mail system status codes [RFC3463] is
@@ -465,7 +470,7 @@
 
    If the response code is issued after the final "." of the DATA
    command, the response code "554" is used, defined in [RFC2821],
-   meaning "Transaction failed". if enhanced mail system status codes
+   meaning "Transaction failed". If enhanced mail system status codes
    [RFC3463] is used, the response code should be "5.6.z" [SMTP-codes],
    meaning that "UTF8SMTP downgrade failed".
 
-----------------------------------------------------------------------------

Discussion:


------start quote----------
2.5.  Using the ALT-ADDRESS parameter

   A message containing non-ASCII envelope addresses or header fields
   MUST NOT be sent to an SMTP server which does not support UTF8SMTP.
   Such a message MAY be rejected due to lack of the ALT-ADDRESS as
   discussed in section 2.2 of this document.

   When messages are rejected because they require UTF8SMTP, response
   code "550" is used, defined in [RFC2821], meaning "mailbox
   unavailable".  If enhanced mail system status codes [RFC3463] is
   used, the response code should be "5.6.x" [SMTP-codes], meaning that
   "alt-address is required but not specified".

   If the response code is issued after the final "." of the DATA
   command, the response code "554" is used, defined in [RFC2821],
   meaning "Transaction failed". if enhanced mail system status codes
   [RFC3463] is used, the response code should be "5.6.z" [SMTP-codes],
   meaning that "UTF8SMTP downgrade failed".

   [[anchor8: REMOVE THIS: IANA please assign the proper error codes for
   "5.6.x" and "5.6.z".]]
-------end quote----------------

1)

Now, when this section talks also DATA command and downgrade failure,
title "Using the ALT-ADDRESS parameter" does not describe it.

I suggested of alternative. Is someone better suggestion for title?


2)

It is better to give pointer to draft-ietf-eai-utf8headers 
(section 4.6 UTF8SMTP message), where is listed conditions
when message requires UTF8SMTP support. It does not make
sense reproduce them on here.


Another thing is that these conditions may be controversial. 
But it does not have effect to here.


More likely is that message is not rejected, but instead NDN 
is sent.  This text does not prevent that case. Generation of
NDN is mentioned on section 2.2 


/ Kari Hurtta



_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima




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