ietf-smtp
[Top] [All Lists]

Re: More references in 2821bis

2007-04-01 08:21:41




--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.

I am strongly supportive of John in this. I will also observe that while a
"white room" implementation strategy is marginally less well served by having
such context in the document, implementations produced by such strategies tend
not to be the best when it comes to interoperability. Like it or not, context
is useful in getting things to work, especially when dealing with corner cases.

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.

This one's a nobrainer as far as I'm concerned. Any reference to a draft either
creates a dependency that has to be resolved before publication or, if it's
allowed in the final document, due to RFC Editor rules ends up creating a
pointer that is difficult for people to resolve. (I happen to disagree with the
way the RFC Editor handles these, but the process is what it is.)

[[ 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.

Yep.

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.

Editor's choice as far as I'm concerned.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>