--On Wednesday, 17 January, 2007 12:25 -0800 Randall Gellens
<randy(_at_)qualcomm(_dot_)com> wrote:
....
(This could also be mentioned in the smtpext document.)
I haven't seen that possibility raised. I'm somewhat
skeptical that it would be an improvement (it makes the
delay before error reporting variable), but it's worth a
discussion. WG?
If it is a temporary failure, and the message is sent
successfully after retrying, then it was a good thing to do.
If there is always an ASCII-only SMTP server in the path, then
retrying only adds delay to the failure. So: is it advisable
for a system to be optimistic that the message will be able to
be sent? I think so, as the document says:
the fact that the selection of submission servers are
presumably under the control of the sender's client and
the selection
of potential intermediate relays is under the control of
the
administration of the final delivery server.
This makes the most sense when sending non-ASCII to non-ASCII,
I think. It also makes sense when sending ASCII to non-ASCII
and the sender's submission server is UT8SMTP compliant. I'd
probably not do it when sending non-ASCII to ASCII.
In any event, I think this is a quality-of-implementation
thing: it should be suggested by the documents but certainly
not required for compliance.
Speaking for myself only, I'd prefer to see this mentioned in
the downgrade document, and maybe in the SMTPext one, but not in
Framework. In any event, I'd recommend/request that you specify
text and where it should go.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf