Unhappy with the complexity of pop-imap-downgrade
Arnt Gulbrandsen <arnt <at> gulbrandsen.priv.no>
2012-01-30 12:17:04 GMT
TL;DR: Change downgrading to support what's most important to the end
user, and drop the rest. Lessen the amount of code provided to implement
downgrade to the minimum possible.
Rationale: While I find the downgrading document is well written, the
downgrade itself is IMO much too complex to be worthwhile. There's too
much to implement, too many cases to test, etc.
It defines new header fields that are intended to be parsable by new
code and even encourages parsing them. That's not good. We want people
to spend their time and energy implementing EAI natively, not writing
clientside parsers for Downgraded-Header-Field-X.
Details: Below I give section numbers and suggested action.
Section 4 (about new parsable header fields, Downgraded-This-That):
New text: "Server MAY generate Downgraded- fields. Clients MUST NOT rely
on such fields or try to parse such fields."
Section 5 (about downgrading various syntax elements):
5.1.1: If any Received field cannot be sent to non-EAI POP or IMAP
clients, then all Received fields are silently suppressed.
5.1.4: Any comments that require EAI are silently excised when the
header field is sent to an non-EAI client.
As an aside, I really, really hate this:
Date: 14 aug 2011 12:00:00 +0200 (Mitteleuropäische Zeit)
5.1.5: Any MIME values that require EAI MAY be silently excised, or MAY
be converted to use RFC2231 syntax.
5.1.8: I like the algorithm, but I would prefer that the exact address
be explicitly undefined, so noone is tempted to detect EAI by looking at
a magic group name.
Btw. For reasons I cannot at the moment remember, I generate
"æ <at> æ.no" <invalid <at> eai.invalid>
instead of an empty group. I'm sure I had a reason, though.
5.1.9: Seems to overlap with 4. I think 5.1.9 is a better location than
5 for this.
5.2.x: I would change most of these to be examples showing the effect of
the relevant 5.1.x rule.
6 (about MIME bodypart fields): Replace with "If any MIME values (e.g. a
file name in content-disposition) require EAI, these values are silently
excised before showing the header field to the client. If any other part
of a bodypart fields requires EAI, the entire field is silently excised."
7. Strike about half, particularly the bit about parsing downgrade-*.
Add a sentence such as "Sending EAI to non-EAI aware recipients offers
new opportunities for misunderstandings, spoofing and deception, if the
recipient is unable to read or understand a part of the message's meaning".
I apologise for suggesting such large changes so late.
Arnt
_______________________________________________
IMA mailing list
IMA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ima
RSS Feed