Keeping this on ietf-smtp as requested... this draft is a dependency for an
EAI deliverable, so I'm interested in pushing it out ASAP.
Some comments that might want to be addressed before Last Call:
- In section 2.1, the entry description is free-form. I'd prefer a strict
format that fits the later registration templates.
- In section 2.1, the text claims that the class and subject sub-codes will
include the same info as the enumerated status code table. That seems a bit
strange.
- In section 2.1, I personally dislike "Owner", preferring "Change
controller". But that is a matter of personal taste.
- In section 2.1, "Text expected to be associated with the code" seems too
strong. We want to reinforce the idea that the text can change at the
implementor's whim; what about "Example of a message that might be sent
along with the code"?
- In section 2.2, "Specification required" should be allowed to stand on
its own, without the verbiage about "evidence of significant deployment";
"specification required" in the 2434 sense includes "this is specified in
Moon Software's MailBean applet manual, version 2.43, page 247", as long as
such a reference qualifies as "readily available".
- In section 2.4, the notation "2.XXX.XXX" seems confusing, since all the
real examples have one digit in the second position. "2.X.XXX" would be
better.
- In section 2.4, I would prefer to replace the "???" for "associated basic
status code" with "Not given". Before submitting for publication, the note
"NOTE: this table is incomplete" should go, no matter how incomplete the
table is.
(I also prefer a 2-column table; I get less confused that way. YMMV.)
- In section 2.4, I don't quite see the justification for X.7.10 and X.7.13
- if they have been in use in the industry, a sentence saying so would be a
Good Thing; if they're just thought up as "this seems like a good idea",
that should be stated too.
Hope these comments help improve the document!
Harald