The Internet Email to Support Diverse Service Environments (Lemonade) Profile
RFC 5550

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

(Lisa Dusseault) Yes

(Chris Newman) Yes

(Jari Arkko) No Objection

Comment (2009-03-12)
No email
send info
Good work. Its nice to see an explanation how to use existing
protocol components to deal with the limits of a particular

I would have voted Yes on this if it weren't for the fact that
I'm not sufficiently familiar with all parts of the protocol
set to say for sure that you didn't miss anything.

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lars Eggert) No Objection

Comment (2009-03-11)
No email
send info
INTRODUCTION, paragraph 2:
>                           The Lemonade Profile

  Title doesn't describe the content. Title of RFC4550 was much clearer.
  Suggest to use it.

(Pasi Eronen) No Objection

Comment (2009-03-11)
No email
send info
Hannes Tschofenig's SecDir review identified a couple of places that
would benefit from some clarification of the text, and provided
editorial comments that should be taken into acccount.

(Russ Housley) (was Discuss) No Objection

Comment (2009-03-11)
No email
send info
  The 2nd paragraph of Section 7 says:
  > Note that the explicit usage of [SUBMIT] means that when opening a
  > connection to the submission server, clients MUST do so using port
  > 587 unless explicitly configured to use an alternate port [RFC5068].
  > If the TCP connection to the submission server fails to open using
  > port 587, the client MAY then immediately retry using a different
  > port, such as 25.  See [SUBMIT] information on why using port 25 is
  > likely to fail depending on the current location of the client, and
  > may result in a failure code during the SMTP transaction.
  It is unclear to me if this is a new MUST requirement or if it is
  intended to be clarification od one that is already in [SUBMIT].
  Please add text to clear this up.

(Cullen Jennings) No Objection

(Jon Peterson) No Objection

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2009-03-12)
No email
send info
Shouldn't this document update 4469 and 4467 since it adds a new capability (URL-PARTIAL)
to the CATENATE and URLAUTH extensions?

I also think the definition of the new URL-PARTIAL capability should be added to the
replacement for section 12 (summary of changes wrt 4550).

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund No Objection