Hi.
I had a lengthy, and very constructive and helpful, conversation
with Lisa yesterday. Among other things we discussed the state
of rfc2821bis and how to get it un-stuck.
I'd like to propose the following as a way of moving the
document forward without an IESG Note or other (IMO) nonsense.
Note that parts of it are probably an improvement to the
document and its organization. The rest is, IMO, _very_
innocuous and might actually be helpful to any complete fool who
actually reads it and might otherwise think that the examples
should be coded and placed in an inner, frequent-iteration, loop.
Of course, Lisa needs to try to "sell" this to the IESG. I
don't believe there are any guarantees about that, but I want to
be sure I'm ready to go if the IESG is willing to sign off.
Section references are to -11. However, neither the section
numbers nor the relevant text have changed in a _long_ time.
Most of you will be able to deduce what is being proposed from
the context of this note.
Proposal:
(1) Rename section 2.3, now called "Terminology" to "SMTP
Terminology"
(2) Create a new section 1.5, titled "Document Conventions"
(suggestions about better names would be welcome, but I think
this does the job).
(3) Move the 2119 boilerplate from 2.3 to 1.5. That puts it
closer to the front of the document, where it probably belongs
anyway. <snide> The fact that there is not yet a requirement
about exactly where 2119 text goes may be an oversight, but is a
discussion for the proposed new I-D Checklist, not this list.
</snide>
(4) Create a new, second (i.e., after the 2119 text), paragraph
of 1.5 that reads:
Because this document has a long history and to avoid
the risk of various errors and of confusing readers and
documents that point to this one, most examples and the
domain names they contain are preserved from RFC 2821.
Readers are cautioned that these are illustrative
examples that should not actually be used in either
code or configuration files.
OK? If the IESG is willing to agree to this, silence on the
list will probably be taken as consent.
--john
p.s. This proposed agreement has to do with getting the document
published and avoiding any further delays that might be caused
by the need to fight over an IETF Note imposed as a note to the
RFC Editor or even to have further discussions about whether or
not to have that fight. Any remaining issues are, IMO, part of
unresolved questions associated with the earlier appeal and
response. I would be happy to discuss the latter group of
issues in Dublin with anyone interested, ideally in the presence
of appropriate beverages. But my instinct right now is that we
should get 2821bis finished and published if we can do so
without having negative and/or distracting text inserted into
the document.