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

["Charles Lindsey" <chl at clerew.man.ac.uk>]

On Wed, 14 Feb 2007 15:23:04 -0000, John C Klensin <klensin at jck.com> wrote:

> 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 think it is clear from the existence of RFCs defining the POP3 and IMAP  
protocols that "mail stores" undoubtedly exist (and that "mailboxes" must  
exist inside them). Moreover, those protocols pretty well constrain what  
is kept inside those stores - just that what we specify is the external  
view visible through the protocols, rather than the actual format inside  
them. And we do not expect to be able to use the IMAP protocol on a store  
designed for POP3 (though the converse might be possible).

So I see no harm in referring to "mail stores" in our documewnts.  
Moreover, since our drafts define UTF8SMTP extensions for both POP3 and  
IMAP, we should be able to use the term "UTF8SMTP extended mail store" to  
describe a mail store capable of being accessed by our extended POP3 or  
IMAP.

And then all we need to say is that if the "final delivery" MTA knows (and  
it needs to know) that it is being asked to store into an extended mail  
store, then it does not downgrade, and if it is being asked to store into  
an un-extended mail store then it MUST downgrade (or bounce). And that is  
all we should say.

So it is none of our business whether, in communicating with a supposedly  
extended mail store, the data is compressed into 7-bits in a manner which  
enables it subsequently to be restored to 8-bit (as you say, if  
implementors are determined to be stupid, then we can't stop them). So  
indeed the present wording says too much.

And likewise, it is none of the MTA's business how the mail store  
negotiates with the final user as to whether he sees an up- or down-graded  
nessage, though that IS a matter for our POP3 and IMAP drafts, and some  
mention of those drafts in the framework document might be useful at this  
point.

> > 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 is an improvement on the present text, but I agree with you that it  
still goes too far. What we need is a text that says that it is the job of  
the mail storage agent (if it supports UTF8SMTP extensions at all) to  
arrange that UTF8SMTP-aware user agents see UTF8 and others don't. With  
reference to our POP3 and IMAP drafts.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 ;                      
   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

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