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

[Chris Newman <Chris.Newman at Sun.COM>]

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
> 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






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