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
send info
Good work. Its nice to see an explanation how to use existing protocol components to deal with the limits of a particular environment. 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
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
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
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
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).