[EAI] Re: From Jari: Re: Your DISCUSS on draft-ietf-eai-framework-05 (fwd)

[Kari Hurtta <hurtta+gmane at siilo.fmi.fi>]

John C Klensin <klensin at jck.com> writes in gmane.ietf.ima:

> >> This implies, to me, that even if there are internal
> >> communications (LMPT,  porocmail scripts, whatever) for
> >> routeing mail for different local-parts  through different
> >> channels, the MTA itself needs to be configured with  basic
> >> information as to which local-parts/channels can offer the
> >> UTF8SMTP  capability. Sounds like a case for a bit of
> >> sendmail.cf hacking :-( .
> 
> In the most general cases, the MTA can't possibly know enough.
> Worse, things can happen after "final delivery" over which the
> MTA has no control.  For example, I would expect that, over
> time, mail stores would migrate from 7-bit-only to
> 8-bit-capable, not only in content and headers, but in keys,
> etc.  I would not expect them to migrate the other way, but see
> no way to ban that.   So, just as a given message in a mail
> store might be accessed by clients and user agents with a wide
> variety of different capabilities, there is no way for the MTA
> to know the behavior and capabilities, over time, of the message
> destination.
> 
> > On stronger form that  user/mailbox/store/system/whatever
> > system is arranged that way that non UTF8SMTP agents no not
> > see UTF8SMTP messages.
> 
> By "not see" you mean, perhaps, "be told that they aren't
> there?", "be told that they are not in a readable format?".
> Note that we've already got provisions for the cases that do
> work in the IMAP and POP documents, but, if a message is
> delivered to a mail store or mechanism that is, itself,
> UTF8SMTP-capable, but that store is accessed with a legacy POP
> server, things may happen that are not predictable (since they
> depend a lot on how the mail store and POP server are
> implemented) or standardizable by this WG.
> 
> > For local delivery agent (LDA) that means that UTF8SMTP and
> > ASCII messages are stored to different mailbox (files or
> > directories or whatever).
> 
> One could implement it that way.  One could also implement it in
> a variety of other ways.   Note that, if I have a mailbox for
> which I have established several names (by aliasing or
> otherwise), some of which involve non-ASCII addresses, and that
> mailbox is fully UTF8SMTP-capable, I would consider the
> restriction implied by the above completely unacceptable.

That means that when MUA is accesing directly (*) mailbox (files
or directories) and do not known about UTF8SMTP, it does not
not see UTF8SMTP messages, because it does not know from where 
to look them.

UTF8SMTP cabable MAU can be programmed to look also from
place where UTF8SMTP ares stored.  For _user_ this is still
one incoming mailbox. 

(*) "directly == via filesystem, not with POP or IMAP protocol"

> So I think you are talking about a whole series of
> implementation or configuration choices above.  They are choices
> I think our specifications should permit (even when I think they
> would be dumb).  But, unless one of you is actually suggesting
> standardizing something, I don't see where this discussion takes
> us.  And, if you are suggesting standardizing something, let's
> see the I-D.
> 
>      john

Well, seems that there need something to be said about mailstores.
Not actual implementation, but some requirements for them when
interacting with UTF8SMTP.   But I do not know yet, what these are.

"Mailstore requirements for Email Address Internationalization (EAI)" ?

/ Kari Hurtta


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