On 9/18/12 8:45 PM, Ben Campbell wrote:
Nits/editorial comments: -- IDNits has some complaints; please check.
They were checked.
-- The abstract should mention that this obsoletes 5721
It does.
-- section 2.1, 2nd paragraph: "The character encoding format of maildrops may not be UTF-8 or ASCII." I'm confused by this sentence, as it seems to say that the format can't be UTF-8 or ASCII, which otherwise seem to be the only ones contemplated by the draft. Do you mean to say that it may be some format other than those?
Yes, I believe that is an editing error. I will confirm and put in an RFC Editor note.
-- same paragraph : "The UTF8 command MAY fail." Under what circumstances? (this seems sort of tacked onto the paragraph--does it belong there?)
AFAICT, it is simply a warning to client writers that the server may (for whatever reasons under whatever circumstances) send back an -ERR response to the command, even if it advertises the capability. Seems appropriate.
-- 2.1, 4th paragraph: "...need not be accurate, but it is preferable if they were." Not preferable enough for a SHOULD? (Note that the previous sentence used SHOULD for reporting actual message size counts)
There is no interoperability impact regarding sizes in STAT and free-form text (unlike LIST), so SHOULD is inappropriate.
-- section 7, 3rd paragraph: "It is possible for a man-in-the-middle attacker to insert a LANG command in the command stream, thus making protocol-level diagnostic responses unintelligible to the user." This seems a bit unnecessary to call out, given that a MiTM could just change the diagnostic responses into Klingon even in the absence of the LANG command. It's at least worth mentioning that the LANG command really doesn't make this issue worse than it already was.
Taken under advisement. pr -- Pete Resnick<http://www.qualcomm.com/~presnick/> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102