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