Hi Lisa,
Thank you for the clarification here and in your post regarding I-Ds.
It is my engineering opinion, that we can have new "clarification"
statements for existing 2821 statements which will not alter its meaning
(as it is currently stated), nor change 25 years of wide practice based
on the statement that is currently stated, yet provide the opportunity
for new development to continue with legitimacy, and also not force
certain undesirable operations (post smtp processing with accept/bounce
exploit potential).
A lock down will pretty much force POST-SMTP processing for the new
augmenting technologies currently under way.
While an extension is conceivable, it will not have provide the maximum
impact for legacy operations as would adding new clarifications will have.
With a lock down, the extension will come in one of two flavors:
1) "break" (update) the new lock down statements being
considered for 2821bis:
- All reply codes in multi-line responses must be the same,
- "1yz-" must not be used in standard 2821 operations.
2) Introduce new response codes which implies new client support
(no legacy support).
#1 will have the highest impact, but I don't think it is desirable to do
break or change existing protocol (if it was written in 2821bis).
#2 would be the more practical approach, but will not provide the
highest impact.
So at this point, I agree with Hansen the "do nothing" conservative
approach is probably the best approach. It will at least allow for
extension #1 to have a better change of being proposed.
Yes, if need be, I would be more than happy to author an extension. How
it is structure will depend on whats decided here.
Thanks for your consideration.
--
HLS
Lisa Dusseault wrote:
Hi Hector,
John's got my support and Tony's to reject new capabilities, extensions,
etc in this round of changes, and he's not enforcing that
preferentially. In fact there's strong process pressure to reject any
additions in order to achieve the status of Draft Standard, so these are
IETF rules, not John's rules.
Do you disagree with John on the basis that your proposed change is too
important to be put off ? or that it's not a new capability but merely
a clarification?
If it's a new feature, please do consider writing up SMTP extension
proposals in I-D form -- the fact that John's working on 2821bis should
not prevent people from working on useful extensions. The two efforts
can and should be separated as far as we can tell.
Lisa
On Apr 10, 2007, at 7:04 AM, Hector Santos wrote:
You might be able to overcome some of these difficulties in an
extension, but it certainly does not belong in the base spec.
I disagree but I defer to your rules. Thats too bad because I can't
help but feel if someone else would had brought this up, you would
take a more open minded consideration. I am sorry to say that only
because I find it extremely odd that technical clarity in this case is
not taken serious when in reality the less serious nits are being
debated else where. The odds are very good systems you will be
confronted with this ISSUE more so than some of the other issues that
essentially have little to no impact in improving the system.