Downgrading Mechanism for Email Address Internationalization
RFC 5504

Note: This ballot was opened for revision 12 and is now closed.

(Chris Newman) Yes

(Jari Arkko) No Objection

Comment (2009-02-12 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The two different fragments of ABNF have a different indentation,
which leads to an error from some parsers, e.g., BAP.

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Pasi Eronen) (was Discuss) No Objection

(Russ Housley) No Objection

Comment (2009-02-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  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."

(Cullen Jennings) No Objection

Comment (2009-02-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Tim Polk) No Objection

Comment (2009-02-12 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection