Re: [yam] Issue #7: RFC 5321 Section 2.2.2: add a bullet for the definition of extensions

[Ned Freed <[e-mail]>]

> Hi Alessandro,
> At 08:51 06-12-2009, Alessandro Vesely wrote:
> >5321 and 4409 are both on the yam list. Which one(s) of them define
> >extensions? They'll

> The Extension Model is defined in Section 2.2 of RFC 5321.

> >  have to agree with each other... Perhaps, it would be more
> > comfortable to decide about

> Yes but it is better not to have each document reference each other
> normatively.

I agree that as a general principle excessive normative references are
something to be avoided, but disagree that that argument applies in this
particular case.

This is a situation where we have two documents one which describes a protocol
and a set of use cases, and another that tweaks that protocol in order to deal
with another, overlapping, use case.

No two ways about it, it is essential to keep these documents in sync with each
other. And more to the point, it is important that it be clear that any
extensions that are defined clearly state which use cases they apply to.

Currently we have the normative reference pointing in one direction only, from
4409 to 5321, and an informative reference in the other direction.  This plus
the fact that both documents are being processed by the same group at the same
time, plus both are moving from draft to full where incompatible changes aren't
allowed anyhow, should be sufficient to address the sync issue without
additional references. But I note that this cuts both ways, and in fact as
Alessandro points out the circumstances reduce the cost of bidirectional
normative references quite substantially.

And extensions are another matter. I can name a couple right off (DSN and
TRACKING) that AFAIK don't discuss submission separate from relay and probably
could have benefitted from such a discussion. So I regard the addition of such
a requirement as sufficiently a Good Thing to justify an additional normative
reference.

				Ned