Re: [EAI] Re: Your DISCUSS on draft-ietf-eai-framework-05

[John C Klensin <klensin at jck.com>]

Jari,

The IETF has never specified what happens between the point at
which the delivery MTA receives a message and the point at which
something that a mail reader connects to (a direct
mailbox-reader, POP or IMAP client, internal delivery mechanism
such as LMTP, etc.) might pick it up.  Our lack of
specifications in that area has been intentional and conscious,
not an accident.  But the absence of such specifications makes
it hard to specify how they should be extended for i18n email.  

We talk about "mailboxes" a lot  but they are an abstraction
without a precise definition (other than the 2821/2822
definition how they are named externally and the POP/IMAP
definitions of how they are named for access purposes).

In particular, suppose one assumes a model based on an
intermediate "mail store" (that model is _not_ required by
anything we now have standardized.  We lack protocols or
specifications for
   delivery-MTA -> mail store
   Format of mail store
   Format of data in mail store and what metadata are stored.
   API, primitives, or protocol for accessing the mail store
from (POP, IMAP, LMAP, and other protocols)

I suggest that assuming enough about those things, starting with
whether a mail store is required at all, to start specifying
i18n details is dangerous as well as hard and that putting in
further details would have us dancing on extremely thin ice.

More below.

--On Wednesday, 14 February, 2007 14:33 +0200 Jari Arkko
<jari.arkko at piuha.net> wrote:

>...
>> So not only is the final delvery agent incapable of knowing
>> the client's capabilities, it wouldn't help if it knew at the
>> time of delivery, because the capabilities might change at
>> any time. And messages in mailstores last for years, unline
>> messages in transit, which generally expire after days at
>> most, so it is very possible that a client's capabilities
>> will change over the lifetime of the message in the mailstore.
> 
> Exactly. That is why it is important that we do not downgrade
> mail permanently
> if we can avoid it. I reacted to the text because it seemed to
> be saying that. Specifically, it says the storage agent may
> downgrade i18n e-mail. Does that mean that it would actually
> downgrade it in the storage, or just for the purpose of
> serving it to this particular client at this one time?

If the interface between the delivery-MTA and the mailstore
(assuming there is one) is only capable of a legacy seven-bit
path, and the mailstore only offers legacy seven-bit interfaces
to things that read from it, then:

	(i) It is fairly stupid for the delivery-MTA to be
	offering these extensions at all because doing so will
	almost certainly cause a loss of information.  We can't
	prohibit that, because it is on the far side of a
	delivery boundary, but there is no question, with just
	about any protocol, that stupidity can be a source of
	problems.
	
	(ii) Because these interfaces are unspecified, all sorts
	of recoding options (not just downgrading in the sense
	specified by the WG)  are available to a mailstore that
	has some knowledge of the upgrades and intelligence
	about what is going on, even if its only storage options
	are 7bit.

But the bottom line is (i) yes, the message might be downgraded
before being stored if that seems to be the right thing to do
(ii) smart implementations won't get themselves into that
situation.

But (ii) is not unlike a ban on stupidity.

>> I don't know if this is enough clarification of why the text
>> is the way it is - do you need more information to clear your
>> DISCUSS?
> 
> Let me suggest a small reformulation:
> 
> Since the final delivery SMTP server (or, to be more specific,
> its corresponding mail storage agent) cannot safely assume
> that agents accessing email storage will always be capable of
> handling the extensions proposed here, it MAY either provide a
> downgraded version of the internationalized email to these
> agents, or specially identify messages that utilize these
> extensions, or both. In any case, the final delivery SMTP
> server SHOULD allow the original internationalized forms to be
> accessed by UTF8SMTP-aware agents without information loss,
> even if they are also accessed in downgraded form by other
> agents.

I am, personally, opposed to this change.  It assumes a model of
post-delivery processing that we have not standardized.  It
assumes  identification models have have been hotly debated in
the WG and concluded to be out of scope.  It imposes a
conformance requirement that is either so trivial and obvious as
to constitute a ban on stupidity or that requires the MTA
implementer to require the impossible (that the "mail storage
agent" be concurrently upgraded and in just the right way)... or
it imposes requirements on something whose existence we haven't
standardized.

At most, I think we could add a statement that says that it
would be ill-advised (and inconsistent with existing 2821
provisions prohibiting accepting mail that one expects to trash)
for a system to offer i18n extensions and mailbox names unless
it was capable of preserving the information in those messages
through to the message-receiving endpoint to the maximum limit
of that endpoints capabilities.   But, if we need to do that, I
propose, not entirely in jest, that we add a "Stupidity
Considerations" section and put this advice, and some related
points, into it.  :-(

Again, my opinion only.

regards,
    john


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