--On Sunday, 01 April, 2007 13:44 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
John C Klensin wrote:
[13] (RFC 1176, the original IMAPv2 spec) is used as part of a
comment about historical development, for which [14] (RFC
3501, IMAPv4r1) would just be inappropriate.
Okay, those are intentional references to obsolete RFCs:
The problems associated with ill-formed messages were
exacerbated by the introduction of the split-UA mail reading
protocols (RFC937 [11], RFC1939 [31], RFC1176 [13], RFC1056
[27]).
How about writing something like this:
The problems associated with ill-formed messages were
exacerbated by the introduction of the split-UA mail reading
protocols like POP and IMAP (now POP3 [31] and IMAPv4r1 [14]).
I haven't heard of PCMAIL before, apparently a kind of BBS. I
fear that's not more relevant today. With the proposed
wording you could remove the historical [11], [13], and [27]
from the references.
Actually, PCMAIL was the original "disconnected mode" protocol.
We had POP (strictly offline mode -- messages downloaded from
server and deleted), PCMAIL (disconnected mode -- messages kept
on server but cached on client), and IMAP (online or kiosk
mode). With IMAPv4, the other two modes were added to IMAP and,
depending on the client and server, more or less well
implemented. And part of the point here is that it was those
older protocols that marked the change being discussed, not the
newer, consolidated, IMAP and the newer POP which is somewhat
bloated relative to historical assumptions about its role.
More generally, you are making an assumption with which I
disagree. I believe that, when a document is being produced
that updates or summarizes a well-established protocol,
information about the sources of differences and evolution is
important. Putting things in context that was may not be
optimal for a completely new, "white room", implementation of
SMTP but it is often useful in reviewing an older implementation
or collection of modules to understand what must be updated and
why.
You may, of course, disagree. If you do, you need to convince
Tony (and others) that pulling the contextual text out is
substantive and valuable and not just a cosmetic change that
carries some risk.
tampering with the references is not completely
straightforward...
Yes. but in some cases it's easy, e.g. for [12] you'd need the
new draft-ietf-openpgp-rfc2440bis when it survived the IESG
evaluation, and if you keep it in chapter 7.1 -- I'd like to
defer "chapter 7.1" issues for some I-Ds, rewriting it from
scratch later (separately).
Our definitions of "easy" also differ. As far as I know, the
normative references to documents that have been superceded were
all updated before -01 was posted. By referencing RFC2440 in
[12], there is a reference to a published RFC. To change that
to a reference to an I-D --an I-D that the IESG has not yet
signed off on-- raises all sorts of problems about people being
able to actually find the relevant document. If the reference
to 2440 is retained, then anyone who looks at the RFC index will
find out about updates when it is published and anyone who does
not will get, from 2440, a general idea about what is going
on... and the latter is all the informative reference is about.
If 2440bis is approved, assigned an RFC number, and published
before 2821bis is published, it would, of course, be appropriate
to update the reference, but it is not, IMO, appropriate to do
so on the basis of an I-D.
Again, you may disagree and should certainly try to convince
people if you do, but I personally believe that changing [12] to
point to an I-D instead of to RFC 2440 would be a cosmetic
change and one that would move things in the wrong direction.
[[ Oops, "Apparenly-To" is already mentioned in 7.2, I've
added it to
<http://permalink.gmane.org/gmane.ietf.message-headers/37> ]]
If we were trying to do a more significant revision, I think
I'd try to reduce the number of such references, rather than
increasing them.
That "If" belongs to the TINW.
Those are the rules under which we got rfc2821bis out of the
"indefinite hold/ there isn't sufficient energy to deal with
this" state. If you still want to try to convince people that
an upgrade to 2821 is not worth doing unless it can be
completely restructured, I would personally recommend and
request that you focus on that, rather than trying to gain that
effect by exhaustion.
Some concepts are stated more
than once, "tuning" them at one place could be inconsistent
with their use in another place. For an example see three
cases of the old "bounce := reject" terminology in chapters
2.4, 3.4, and 3.5.3, inconsistent with the revised terminology
in chapters 61. and 6.2:
<http://permalink.gmane.org/gmane.ietf.smtp/5395>
These have been fixed (although some of the resulting
constructions seem clumsy), but this risk of catching some
places and not others is precisely why I was reluctant to try to
change that terminology.
I'm personally disinclined to start down the path of trying to
significantly upgrade, or even fine-tune, the external
references (although, if people really want it and supply
specifics, I'll try to find time).
For the POP and IMAP cases I think it's better to use the names
instead of obsolete RFC numbers, with references to the actual
RFCs, but that's mainly a matter of taste and editorial issue.
yes. and see above.
For the "missing" 3848 link there's a clear place _where_ I
miss it, in section 4.4, in the ABNF comment for
<Attdl-Protocol>:
- ; Additional standard names for protocols are
- ; registered with the Internet Assigned Numbers
- ; Authority (IANA) in the "mail parameters"
- ; registry. SMTP servers SHOULD NOT use
- ; unregistered names.
+ ; Additional standard names for protocols are
+ ; registered in the "mail parameters" registry
+ ; as specified in [RFC 3848]. SMTP servers
+ ; SHOULD NOT use unregistered names.
Partially to demonstrate the advantages of supplying specific
context and textual suggestions, this reference has been added.
If anyone objects, say so.
2119-keywords and references in an ABNF comment are again a
matter of taste, I'd convert it to prose. What does "Attdl"
stand for ?
Your preferences is noted and classified as cosmetic unless
others feel strongly about this.
It stands for "Additional"
john