Frank,
I don't think a two-way debate between the two of us will be
useful to the WG or others, but I'd like to clarify four things.
(1) Randy and I worked together on 4409bis, 4409, and 2476. For
reasons that had a lot more to do with time availability than
anything involving decision-making, Randy was the primary
pen-holder for 2476 and 4409 and I took over with 4409bis. But
I think it is accurate to say that we consulted each other
closely on everything that was the slightest bit controversial.
More important, 4409bis-02 reflects a lot of comments that
neither Randy nor I would have made on our own. I'd have to go
through the document to tell you which changes we made that I
don't like (and don't consider that a good use of my time), but
my personal preferences are really not an issue in this.
(2) Having been involved in the various discussions about the
meaning of maturity levels and downward references over the
years, I do have strong opinions on the subject. Some of those
opinions got IETF consensus and are reflected in BCP 97. My
reading of those documents and the original rules is that the
exceptions are intended to apply to circumstances in which the
document that requires a downward reference represents a
protocol that is tested and mature, even if the document itself
hasn't been updated. It seems sensible to me to be even more
discriminating about that principle with Full Standards than
with Drafts although, maybe, some might disagree. Under that
criterion, 6186 just does not seem to be mature enough. If
someone demonstrates otherwise -- e.g., with an implementation
report that shows fairly widespread adoption-- I'd be delighted
to add it (see below).
(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 :-( ).
(4) As an editorial style matter, RFCs that specify protocols
tend to not reference supplemental documents that make
operational recommendations. The references run the other way
and the other way only. I would consider a reference from
4409bis to 5068 an exception to that general principle.
However, if the WG or IETF conclude that such a reference is
wanted, you will get absolutely no resistance from me to doing
so. I just have too many more important issues to worry about.
john
--On Wednesday, August 17, 2011 17:22 +0200 Frank Ellermann
<[email protected]> wrote:
>...
> [6
>> See
>> http://www.ietf.org/mail-archive/web/ietf/current/msg68465.ht
>> ml
>
> ACK, I interpret that as "John doesn't like RFC 6186",
> otherwise he would find a way to mention it somewhere. I had
> my share of "let's try discovery for NNTP" elsewhere, and
> won't mention it again here.
>
> But referencing RFC 5068 (BCP 134) would be good, if readers
> arrive at a "the IETF really wants this" conclusion.
>...
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
