![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
I also believe that draft-gellens-submit-06.txt is an incomplete protocol addressing inadequately considered requirements. It aims too low and ends up shooting way too low. Since a new port number has been assigned to this protocol, there are no backwards compatibility and current installed base interoperability issues. Therefore, the expectation is that this new protocol -- which is to address a sensitive and important area of Internet Mail -- be well thought out, complete and extendible. Instead it is yet another hack on top of the more than 15 year old SMTP. Given a clean plate (port 587) and given what has been learned from the SMTP and X.400 experience over the past 15 years, we should be able to do a lot more for message submission than what draft-gellens-submit-06.txt attempts to do. For example: better authentication, better error reporting, less historic options, better efficiency, submission server referrals, ... I second Greg's suggestion of: >>>>> On Wed, 22 Apr 1998 13:42:35 -0500, "Vaudreuil, Greg" <gregv at lucent.com> said: Greg> Lets have a working group to finish this work and consider Greg> the full requirements of this important function for Internet Mail. I believe that restricting ourselves to "SMTP Message Submission Protocol" instead of considering a brand new "Message Submission Protocol" is an architectural mistake. If we go to a new port number, then we have a clean plate and we should take full advantage of it. Judicial re-use of proven technology is very different from hacking on top of Simple 15 year old protocols. The next millennium need not also be the era of Simple Protocols. Going to a new port number opens the door for moving Internet Mail Protocols forward. But, we are not planting the right seeds with draft-gellens-submit-06.txt. More work is needed here, both at the analysis and requirements gathering level as well as at the architecture and design level. ...Mohsen.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.