SMTP Submission Service Extension for Future Message Release
Note: This ballot was opened for revision 04 and is now closed.
(Bill Fenner) Yes
(Ted Hardie) Yes
(Jari Arkko) No Objection
(Ross Callon) No Objection
(Brian Carpenter) No Objection
Comment (2006-06-19 for -)
Nits from Gen-ART review by Francis Dupont: - the "MSA" abbrev is never introduced (I suggest to both explain what it stands for and to put a reference to n3) - (in 6) standards-track -> Standards Track - I can't parse the first statement of 7 (where is the verb "who" is the subject?) - (in 9) Jauuary -> January)
(Lisa Dusseault) No Objection
(Lars Eggert) (was Discuss) No Objection
(Sam Hartman) No Objection
Comment (2006-06-22 for -)
I'm uncomfortable with the claim that this extension can only be offered over the submission port. I can see the reason you don't want it offered over the smtp port. However I'm going to be really annoyed if I try to set up a test server on some random port and it ends up offering a different feature set because of the port I used.
(Russ Housley) (was Discuss) No Objection
Two comments from the SecDir review Radia Perlman: Under security considerations, it says "an MSA that supports future message release MUST also support at least one of the authorization mechanisms." That is, the MSA may not require the client use it. If this is true, then there needs to be an error that indicates that the MSA could not accept your future-release message because authentication will be required. There is an error for a user exceeding his own quota. Assuming that the MSA is willing to overbook and there are a lot of users using this feature, the total shared storage might be exceeded. Should there be a separate error for "you didn't exceed your own quota, but I still don't have any room left for your future-release message".
(Cullen Jennings) (was Discuss) No Objection
(Jon Peterson) No Objection
(Dan Romascanu) No Objection
(Mark Townsley) No Objection
Magnus Westerlund (was Discuss) No Objection
Section 6: According to the IANA website, this extension will be added to the list of SMTP extensions on the Mail Parameters webpage once this draft becomes a Standards Track RFC. Although I don't think this will be missunderstood by IANA, I think it is a bit incorrect to say that the registration will not happen until it becomes a Standards track RFC. Normally IANA do the registration upon the approval of the document by the IESG and before the publication as an RFC. I think one normally simple request that IANA performs the registration without being explicit about which phase.