Subject: [EAI] POP Draft Open Issue: Up-conversion

From: Randall Gellens <[email-masked]>
Date: Thu, 26 Jul 2007 13:24:13 -0700

One open issue for the POP draft that was discussed in today's 
meeting is upconversion.

Currently, Section 5 of the draft requires up-conversion of certain 
headers, and encourages up-conversion of MIME headers and embedded 
body parts.  Up-conversion is required when the mail store is 7-bit. 
Up-conversion is prohibited of multipart/signed.

This text doesn't specify exactly how up-conversion is to be done, 
and doesn't mention down-graded messages in a UTF-8 mail store.  If 
there is any difference between messages that were downgraded on 
final delivery into a 7-bit store compared to those that were 
downgraded in transit, the draft is silent.  In theory, I don't think 
there is any difference.

Should up-conversion be a reversal of the downgrade process? 
Specifically, should 'downgraded-' header fields be decoded and the 
original header field name and value extracted?  So, 'downgraded-to' 
is decoded and replaces the 'to' that presently exists?  If so, what 
about cases where there are multiple occurrences of a header field? 
Or what about situations where the header was mucked with subsequent 
to the downgrade?  For example, a UTF8 message is sent to a UTF8 list 
which adds 'list-*', 'reply-to' and 'sender' header fields containing 
UTF8 addresses.  One recipient is an ASCII list.  The message is 
downgraded in order to be sent to the ACII list's server.  So there 
are now 'downgraded-list-*', 'downgraded-reply-to' and 
'downgraded-sender' header fields.  The ASCII list replaces some of 
the 'list-*' header and the 'reply-to' and 'sender' fields with its 
own values.  The ASCII list sends the message to a POP user.  The POP 
server up-converts by replacing the ASCII list's 'list-*', 'reply-to' 
and 'sender' header fields with those of the UTF8 list, extracted 
from the 'downgraded-*' header fields.

We can say "This is what happens when one list is subscribed to 
another, too bad."  We can even say "This shows why lists should not 
replace 'sender' and 'reply-to'.  Or is this how it should behave?

We have been saying "downgrade is officially a one-way process, but 
if a client wants to extract downgraded data for display or reply 
purposes, it is free to do so, but we don't specify how."  That may 
be fine for clients.  But here we are talking about servers, where 
presumably we want the behavior to be deterministic and clients to 
know what to expect.  Specifically, if the server is going to 
up-convert to make life easy for the client, it should up-convert 
everything, right?  So we should be very clear on this.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
wabi (wah-BI; Japanese; noun): a flawed detail that creates an
elegant whole.

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Chris Newman <[email-masked]>
Date: Fri, 27 Jul 2007 14:10:53 -0500

Speaking as a technical participant:

I have a preference to have the POP server up-convert RFC 2047, RFC 2231 on 
behalf of the client.  POP clients have had lots of problems in practice with 
white space handling in RFC 2047 and I've seen clients with a much smaller 
charset vocabulary than the typical server.  Given that people rarely get paid 
much to work on desktop mail clients, it's possible they'll be patched to add 
UTF-8 header display support but I'm dubious we'll get a lot more from desktop 
clients.  It's also more efficient and simpler for thinner clients.

Beyond that, the less the document says, the better IMHO.

It is impossible in the general case to provide a command to fetch a message as 
it was prior to message store insertion.  However, I neither support nor oppose 
adding a mechanism to fetch a message as stored in the mail store.

I suspect it's unwise to attempt to fully reverse down-conversion and not worth 
the trouble.  I see little value in up-converting IDN as the ugly form works 
and clients have to implement IDN up-conversion for UI consistency regardless. 
IDN also lacks the white space and charset issues that make 2047/2231 
problematic for clients.  I view IRI/URI conversion in the same class as IDN 
(the 7-bit URI works, and clients need an up-converter for consistency anyway). 
Replacing the "From" with "Downgraded-From" or the equivalent for other address 
headers seems problematic to me.

                - Chris

Randall Gellens wrote on 7/26/07 13:24 -0700:

> One open issue for the POP draft that was discussed in today's meeting is
> upconversion.
>
> Currently, Section 5 of the draft requires up-conversion of certain headers,
> and encourages up-conversion of MIME headers and embedded body parts.
> Up-conversion is required when the mail store is 7-bit. Up-conversion is
> prohibited of multipart/signed.
>
> This text doesn't specify exactly how up-conversion is to be done, and
> doesn't mention down-graded messages in a UTF-8 mail store.  If there is any
> difference between messages that were downgraded on final delivery into a
> 7-bit store compared to those that were downgraded in transit, the draft is
> silent.  In theory, I don't think there is any difference.
>
> Should up-conversion be a reversal of the downgrade process? Specifically,
> should 'downgraded-' header fields be decoded and the original header field
> name and value extracted?  So, 'downgraded-to' is decoded and replaces the
> 'to' that presently exists?  If so, what about cases where there are multiple
> occurrences of a header field? Or what about situations where the header was
> mucked with subsequent to the downgrade?  For example, a UTF8 message is sent
> to a UTF8 list which adds 'list-*', 'reply-to' and 'sender' header fields
> containing UTF8 addresses.  One recipient is an ASCII list.  The message is
> downgraded in order to be sent to the ACII list's server.  So there are now
> 'downgraded-list-*', 'downgraded-reply-to' and 'downgraded-sender' header
> fields.  The ASCII list replaces some of the 'list-*' header and the
> 'reply-to' and 'sender' fields with its own values.  The ASCII list sends the
> message to a POP user.  The POP server up-converts by replacing the ASCII
> list's 'list-*', 'reply-to' and 'sender' header fields with those of the UTF8
> list, extracted from the 'downgraded-*' header fields.
>
> We can say "This is what happens when one list is subscribed to another, too
> bad."  We can even say "This shows why lists should not replace 'sender' and
> 'reply-to'.  Or is this how it should behave?
>
> We have been saying "downgrade is officially a one-way process, but if a
> client wants to extract downgraded data for display or reply purposes, it is
> free to do so, but we don't specify how."  That may be fine for clients.  But
> here we are talking about servers, where presumably we want the behavior to
> be deterministic and clients to know what to expect.  Specifically, if the
> server is going to up-convert to make life easy for the client, it should
> up-convert everything, right?  So we should be very clear on this.
> --
> Randall Gellens