mail-ng
[Top] [All Lists]

Re: Some existing proposals for next-generation email

2004-01-30 09:48:51

Wrote Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>, on Thu, Jan 29, 2004 at 
03:29:04PM -0800:
So, let me say it again: this list is about determining the needs in 
new protocols, not fixing current ones.

To re-cast what is said above in terms appropriate for this list: 
"the receiving user agents in the next-generation protocol should not 
lose messages just because the user hasn't checked in a while".

From your announcement, I had the impression it was partly prompted to
explore why people are proposing next generation mail protocols, what
their needs are.

This is hard to do without talking about protocols, because current mail
protocols do everything that is "needed", or can be extended to do so.
Sometimes the extensions make you scratch your head, and think this is
way harder than it should be, though.

Theoretially, with the advantage of 25 years of hindsight, simpler
protocols could be developed (leveraging utf-8, xml, ...). Would they
actually DO different things though, or just BE different?

So, I think what many people have a problem with /is/ the protocols, not
the functionality, putting protocols out of scope might be hard.

++

That said, I have some candidates for "need"s.

--> Requirement: all candidate protocols should be text-based.

--> Requirement: that the underlying message structure be useful in a
number of different situations, such as email, news, instant messaging
(draft-ietf-impp-cpim-msgfmt-08.txt), etc.

--> Requirement: The "type" of values stored in mail/news messages
(text/multilingual, email address sequence, message ID, etc.) should be
self-describing/carried in the message encoding, so that basic
manipulations of the message can be done without having to have
pre-knowledge of what is being carried.

Sorry my phrasing is so awkward.

Current header field names in rfc2822 can be structured ("Received"),
can be multilingual free text ("subject"), or can be a combination
("from"), a URL ("list-unsubscribe"), and probably many other things.

The type of the value of a field is not carried in the message, though.

An example of when this is a problem: NNTP wants to allow binary utf-8
mail, and convert between utf-8 and rfc2047 at gateways. This turns out
to be difficult, because when the gateway sees an unknown header
("Friends"), it doesn't know whether (mail->news) that field is allowed
to be multi-lingual, and so whether to attempt to convert it to utf-8 if
it sees rfc2047-like tokens in it.

XML would fulfill this, possibly, a rfc822 field naming convention like
"text.Subject" or "adr-list.Bcc" might also work, and ASN.1 encodings
have type information, too, though I think binary application protocols
are a bad idea.

Cheers,
Sam

-- 
Sam Roberts <sroberts(_at_)certicom(_dot_)com>