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

[Jari Arkko <jari.arkko at piuha.net>]

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

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

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.

Jari


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