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

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

Jari,

As I assume you know by now, your message to the WG of 14
February got stuck somewhere and was apparently never circulated
to the WG until now.

Again with the understanding that this is a personal note/
explanation that may or may not represent a WG position...

--On Wednesday, 07 March, 2007 23:46 +0100 Harald Tveit
Alvestrand <harald at alvestrand.no> wrote:

> ------------ Forwarded Message ------------
> Date: 14. februar 2007 14:33 +0200
> From: Jari Arkko <jari.arkko at piuha.net>
> To: Harald Alvestrand <harald at alvestrand.no>
> Cc: iesg at ietf.org, EAI WG <ima at ietf.org>
> Subject: Re: Your DISCUSS on draft-ietf-eai-framework-05
> 
>>> > 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 downgrade internationalized emails or
>>> > specially identify messages that utilize these extensions,
>>> > or both. If this done, the final delivery SMTP server
>>> > SHOULD include a mechanism to preserve or recover the
>>> > original internationalized forms without information loss
>>> > to support access by UTF8SMTP-aware agents.
>>> 
>>> Does this suggest that the final server downgrades mails
>>> without knowing that the client is uncapable of reading
>>> them in the internationalized form? This seems surprising.
>>> Can you elaborate why? And what is the identification
>>> mechanism, and how does it affect POP/IMAP access to the
>>> messages?
>> Since this is an issue with a bit of substance, I'm CCing the
>> WG on this note.
>> The issue with POP and IMAP servers is that there is no
>> knowing what kind of client software the user will use to
>> connect to the mail store the *next* time it connects.
>> 
>> Especially in the case of IMAP, it is not uncommon to connect
>> to a single mailbox using multiple clients (often including a
>> Web client) - at the same time, serially, or switching
>> randomly between them.
>> 
> 
> Right.
> 
>> 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?

Actually, it doesn't say a thing about the storage agent
because, as far as 2821 is concerned, there is no such thing as
a storage agent.  More specifically, while there might be one,
its properties and interfaces are not defined at all.
Certainly, if one can avoid loss of information, one should do
that.  We can say that in the document, but it seems too
self-evident to be worth much discussion.   But suppose that (i)
the interface to the mail store, or the store itself, cannot
support messages with any non-ASCII content and (ii) at the time
the message is received, the POP and IMAP servers associate with
the mail store are known to the person implementing or
configuring the delivery SMTP server to have no mechanisms or
conventions for converting from mail-store format back to
UTF8SMTP and header format.   Storing the information in UTF-8
form is simply not a possibility here, nor is storing it in some
form from which the UTF-8 form can be reconstructed.

That leaves two options/theories:

	(a) The delivery MTA has no business offering the
	UTF8SMTP option if the situation downstream is that
	weak.  There is an additional complication with this,
	involving different mail stores for different addresses:
	see below.
	
	(b) It is desirable to deliver the mail if at all
	possible, even if it is somewhat damaged.

That language and the "MAY" provision were intended to allow for
the second case since "deliver something if at all possible" is
often chosen in practice.

>> What is knowable is whether or not the *mailbox server* is
>> capable of supporting UTF8SMTP; in the case of delivery via
>> SMTP or LMTP, the "UTF8SMTP" extension is a good way of
>> signalling such support.
>> 
>> The issues in the specific context of IMAP and POP, including
>> identification mechanisms, are addressed in the drafts
>> specific to these protocols; however, I think it would not be
>> appropriate to go into details on those protocols in an
>> overview document - also because those proposals are still
>> under discussion by the WG, and might change considerably
>> before they are finished.
> 
> Fair enough.

>> 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:

This really doesn't work any better than the original and it
ignores some important cases.  Dissection below.

> Since the final delivery SMTP server (or, to be more specific,
> its corresponding mail storage agent) 

As mentioned above, "mail storage agent" is not well-defined or
formally part of the model

> cannot safely assume that agents accessing email storage

It is a little worse than that.  It may use some protocol --
either LMTP or something that is not standardized in the IETF --
to deliver to the mail store.  If the mail store, or the path to
it, doesn't have UTF8SMTP capability, the delivery SMTP server
is stuck.   Worse, it may deliver messages to different
addresses (mailboxes) into different message stores using
different protocols.  If some of them are fully capable of
handling UTF-8 headers and message content, and some are not, it
should probably advertise the options but it is not clear what
it should do in the cases in which, e.g., someone has assigned a
non-ASCII address to a UTF-8-incapable mail store.  That case is
arguably a configuration error, but some others, including those
involving backward-pointing addresses might not be.

> 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.

And, of course, the final delivery SMTP server isn't doing any
allowing because, in general, it doesn't talk to the servers or
access methods that support the "other agents" you posit.

I am sure the vocabulary and concepts her could be straightened
out but strongly suspect that the result would not be
substantively different from what is in the text now.  The
problems here reflect both the history and context of email work
in the IETF (e.g., POP and IMAP assume the existence of a mail
store, but SMTP does not) and some implementation options and
flexibilities that are 2821/2822-conforming.

best,
     john


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