Re: Last Call: draft-klensin-rfc2821bis

> > > > In an IETF that believes the potential recursion of URNs and
> > > > NAPTR records is reasonable, it is really hard for me to get
> > > > excited about that one possible extra lookup.   YMMD, of course.
> >
> > I can't get excited about this either.
> >
> > > 	Doug's issue, which sparked off this latest debate, would
> > > 	be addressed by codifying "MX 0 .".  This would allow hosts
> > > 	to say that do not accept email and any email (MAIL FROM)
> > > 	claiming to come from such a domain to be dropped in the
> > > 	SMTP session.
> >
> > OTOH, I think standardizing this convention makes all sorts of sense, but
> > not, of course, in 2821bis.

> 	Why not in 2821bis? 

Mainly because this entire exercise is focused on a move to draft with this
revision and a move to draft is not the time to introduce new features.

> Is 2821bis really that time critical?

It is somewhat time critical, but to be blunt I'm much more worried that if we
delay long enough to get consensus on this change and force a recycle at
proposed the necessary energy to move this document to draft won't be there
when it is possible to do so.

I'm also concerned that opening the door to new features and additions to
this document will result in a slew of additional well intentioned proposals
for changes and additions that will delay things even more.

This entire effort to revise the core email protocol documents has only been
been able to reach some sort of closure because we've managed to keep a pretty
narrow focus on just cleaning ujp what's there in the base specifications. And
even then it has taken a huge amount of work. I don't think you realize the
potential for harm opening the door the way you propose can do.

				Ned
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf