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

[Harald Alvestrand <harald at alvestrand.no>]

(Apologies for my previous mail, which should have been addressed to 
Lars Eggert)


You raised an issue at IESG, with the following text:

> Jari Arkko:
>
> Discuss [2007-02-08]:
> I believe this is important work and long overdue.
> I do have a question abou the server downgrade
> behaviour, however:
>
> > 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.

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.

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.

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?

                      Harald, document shepherd




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