Downgrading Mechanism for Email Address Internationalization
RFC 5504

I was wondering why this was experimental - then I read Klensin's note from Jan 7. If that reflects general state of this document, it seems like it would be a good idea to add an IESG Note that adds a bit caution and highlights why this is experimental.

The two different fragments of ABNF have a different indentation,
which leads to an error from some parsers, e.g., BAP.

  The Gen-ART Review by Vijay Gurbani posted on 2-Jan-2009
  includes two comments:

  1) The last statement in S3.3 ("Applying this procedure to
  "Received" header field is prohibited.") ought to be moved
  elsewhere.  I think this is a fairly important statement
  and appearing as it does in a section for "unknown" header
  fields, I believe adequate attention may not be paid to it.

  A couple of places where it could be moved would be S1 or
  S5, when "RECEIVED downgrading" is discussed.

  2) In S5, under "RECEIVED downgrading", does it make sense
  to say "will not contain non-ASCII values" or "should not
  contain non-ASCII values" instead of "don't contain non-
  ASCII values."

The second and final bullets in the security considerations could be strengthened a bit, imho.

Specifically, in bullet 2 the authors might wish to say what implementations that attempt to
detect spoofing should do.  Do they rely on the Downgraded-* fields and ignore the rewritten
headers, or is some comparison between these fields in order?

The last bullet closes with the sentence "Such gateways violate [RFC2979] and can be upgraded
to correct the problem."  Unless there is a downside to this upgrade, the authors should
consider strengthening this to say the upgrade is recommended.