[EAI] POP Draft Open Issue: Up-conversion

[Randall Gellens <randy at qualcomm.com>]

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
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima