Sorry for not replying sooner. I concur with John.
One thing I miss from the Internet Mail Consortium days was Paul's
web page listing all email RFCs grouped by protocol. Such a resource
would be an excellent place to list RFC 6186 in reference to
submission.
At 11:54 AM -0400 7/21/11, John C Klensin wrote:
Alexey,
As editor, I consider it much more important to get this
document finished and out than to have extended arguments about
references or philosophy. That said, I was trying to respond
to Subramanian's note and issue list as the issues were stated
there. Comments below from a slightly different and more
personal perspective, leaving the Full Standard and current YAM
requirements aside entirely...
--On Thursday, July 21, 2011 13:04 +0100 Alexey Melnikov
<[email protected]> wrote:
...
RFC 6186 is a Proposed Standard and was published in March
2011. I am not aware of any effort to move it to Draft
Standard. As you mentioned, RFC 6186 does not update RFC
4409. A normative reference to RFC 6186 would be a
downward reference. As there hasn't been consensus for such
a change and based on the current status of RFC 6186, I
recommend no action in the current document.
I would love for RFC 6186 being mentioned (can I bribe you
guys :-)?). However I do agree that making it normative via
use of SHOULD is too strong. Maybe an Informative reference?
<rant>
I do find all arguments around "we can't add this reference
because it is going to be a downref" to be quite counter
productive. Why are we being so process oriented when having a
downref might be the right thing to do?
</rant>
What is said when a few of these things were being discussed
earlier wasn't really about downrefs. I have a bias that, if we
are going to direct someone from a Full Standard (or usually
even a Draft Standard) to something in a way that encourages
them to look at and use it, it should be relatively proven
rather than something we might take a look at in a few years and
say "never mind" (or worse, with the current 6to4 snit being an
example). "Direct someone" is deliberately informal and vague.
Certainly it applies to a normative requirement, so we agree
about SHOULD.
For an informative reference, my threshold for "relatively
proven" is fairly low, but it is still higher than "no known
defects" or "looks good in theory and on paper". That is
precisely why I asked about implementation reports: if it can be
shown that there is significant conforming implementation and
non-trivial deployment of the 5451 or 6186 specs, then a note
that essentially says "others have found these useful in
conjunction with submission servers, you ought to consider them
too" is appropriate, even if it doesn't get to a SHOULD-level
requirement. On the other hand, to the extent to which there
are few production implementations and deployments, it would be,
IMO, better to think about the right timing for either updates
to 5451 and 6186 or an Applicability Statement that would update
both and 4409bis to specify that implementers of submission
servers should look at those specs and MAY (or SHOULD) support
them.
I think mentioning RFC 5451 falls into a similar category to
RFC 6186.
Yeah. See above.
Just my opinion.
john
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly selected tag: ---------------
Look Bruce, the bat signal!!!
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
