> (3) As far as my "not liking" 6186 is concerned, it just isn't
> true. If you searched the mail archives into fairly ancient
> history, long before RFC 2782, you would find me whining about
> the problems associated with manual configuration of outbound
> SMTP servers (what we'd now call Submission Servers) into email
> clients. That whining got particularly loud when I had to
> deploy a lot of email clients for clueless users around 94-95.
> Many of us thought for a while that IMSP and later ACAP would do
> the job, changing the "where to find the outgoing SMTP server(s)
> specifically" into "where to find that IMSP/ACAP server so it
> could supply the rest of the information". When ACAP failed in
> the marketplace (more's the pity, IMO), 6186 came along (you'd
> have to ask Cyrus but I strongly believe that, had ACAP been
> wildly successful, the equivalent of 6186 would be titled "SRV
> Record for Locating ACAP Servers".
> But my disliking it or being opposed to it? Nah, not a chance.
> I just wish I had it in my MUA (sorry, Cyrus :-( ).
Complete agreement with John here.
Full standard is supposed to give operators confidence that there won't be any
problems with the technology. It does this by demonstraing substantial
sucessful operational experience. AFAIK such experience does not presently
exist for RFC 6186. As such, much as I like RFC 6186 and would like
to see it widely deployed, referencing it in 4409bis is completely and totally
inappropriate.
Anyone who disagrees should feel free to describe the multiple commonly used
clients that support it as well as the multiple large operational setups that
have succesfully used it. If that happens I'll happily change my position and
support a downref to RFC 6186.
In short, this is a substantial concern about there being a lack of operational
experience. It is not simply a matter of blindly following process rules.
Ned
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
