<ned+ietf-smtp(_at_)mrochek(_dot_)com> wrote:
A reference is normative when an understanding of it is
needed to implement some aspect of the specification at
hand. This is not the case with SMTP submit - you need
understand nothing of it to implement SMTP proper.
If the MTA proper is used as MSA, depending on the port,
or for port 25 depending on the client, and the implementor
of said MTA never bothered to look in RFC 4409, then I fear
bad things can happen... Okay, making RFC 4409 normative
won't necessarily help in this situation.
Maybe adding an *informative* RFC 5068 reference near the
"SHOULD 4409" would help, for obvious reasons RFC 4409 has
no pointer to 5068.
I see nothing in RFC 2119 that restricts the terms in
such a way as to preclude such usage.
Yes, and of course RFC 2119 could not talk about the fine
art of splitting references into normative and informative.
[similar question about 3461 and 3464]
We're now talking about something that SHOULD be done in
order ancillary to proper implementation of this
specification. It therefore makes considerable sense for
these to be normative, and I certainly would not object
to doing so. OTOH, these are still describe a separate
facility so I'm not completely convinced our process
requires this change.
For [37] = RFC 3464 John convinced me that "for example"
means what it says => informative. For [35] = RFC 3461 he
might have missed the use in the ABNF <xtext> SHOULD. And
for [36] = RFC 3463 it is IMO similar, 3461+3463 normative.
OTOH, these are still describe a separate facility so I'm
not completely convinced our process requires this change.
Look at the ten uses of [35], [36], and [37], I think they
are pretty clear.
Frank