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

From: SM <[email-masked]>
Date: Sun, 06 Dec 2009 01:24:55 -0800

Hello,

SMTP is generally used for mail transfer.  There are other protocols 
for message submission such as RFC 4409 (see Section 3.6.3).  I do 
not support adding the following bullet to Section 2.2 of RFC 5321:

    Future SMTP extensions SHOULD explicitly specify if they are
    valid on the Submission port."

to keep the two protocols separate and to avoid an additional 
normative reference in RFC 5321.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 06 Dec 2009 17:51:51 +0100

Hi SM,

SM wrote:
> SMTP is generally used for mail transfer.  There are other protocols for 
> message submission such as RFC 4409 (see Section 3.6.3).

5321 and 4409 are both on the yam list. Which one(s) of them define 
extensions? They'll have to agree with each other... Perhaps, it would 
be more comfortable to decide about this issue after having given some 
thought to RFC 4409. In this case, I'd be curious to know whether the 
2-step process would allow working on both in parallel.

> I do not support adding the following bullet to Section 2.2 of RFC 5321:
> 
> to keep the two protocols separate and to avoid an additional normative 
> reference in RFC 5321.

Which one? (As you say, RFC 4409 is referenced already.)

---

From: SM <[email-masked]>
Date: Sun, 06 Dec 2009 10:29:30 -0800

Hi Alessandro,
At 08:51 06-12-2009, Alessandro Vesely wrote:
>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.

>this issue after having given some thought to RFC 4409. In this 
>case, I'd be curious to know whether the 2-step process would allow 
>working on both in parallel.

Yes.

>Which one? (As you say, RFC 4409 is referenced already.)

The reference to RFC 4409 is Informative.

Regards,
-sm

---

From: Ned Freed <[email-masked]>
Date: Sun, 06 Dec 2009 12:30:47 -0800 (PST)

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

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

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 07 Dec 2009 10:52:50 +0100

SM wrote:
>> extensions?

Yes it is, but no IANA registry of extensions is defined. RFC 4409 
defines no registry either, but lists its initial values. Will that 
list have to be updated for 4409bis? And how will it be maintained 
thereafter?

>> They'll have to agree with each other...
>

This can be avoided with a well crafted IANA registry definition: 
RFC 5321 may just acknowledge that the extension mechanism can be 
reused by "other protocols", if they are similar enough to SMTP. The 
extensions IANA table definition may thus provide for adding a 
column for each look-alike protocol, and a row for each extension. 
The RFCs where the look-alike protocol is defined must also provide 
the column values for already registered extensions --which is what 
4409bis would then do. Likewise, as new extensions register 
additional rows, they must provide the values for already existing 
columns.

That way, 2033bis would be able to add its own column as well, 
without circular normative references.

---

From: SM <[email-masked]>
Date: Mon, 07 Dec 2009 07:23:50 -0800

Hi Alessandro,
At 01:52 07-12-2009, Alessandro Vesely wrote:
>list have to be updated for 4409bis? And how will it be maintained thereafter?

There is a SMTP Service Extensions registry defined in Section 2.2.2 
of RFC 5321.  The IANA Considerations section of 4409bis would have 
to be updated with text about the registry.  There is already a 
registration procedure.

>additional rows, they must provide the values for already existing columns.

The registry already mentions SMTP and Submit.  Instructions to IANA 
should be clear.  It is better to avoid terms like "other protocols".

>without circular normative references.

Is anybody working on the LMTP specification?

Regards,
-sm

---

From: Ned Freed <[email-masked]>
Date: Mon, 07 Dec 2009 15:32:46 -0800 (PST)

> should be clear.  It is better to avoid terms like "other protocols".

I agree. The relevant protocols here are SMTP and Submit. In the absence of
information about a future protocol that reuses some or all of SMTP and which
reuses some or all SMTP/Submit extensions, it is impossible to know what
registry tweaks will be needed to accomodate it.

If such a case does come up, as it might if LMTP goes standards-track, it will
be up to those documents to make the necessary changes and updates.

> Is anybody working on the LMTP specification?

John Myers indicated that he was interested in doing an update some time back.
I don't know what progress, if any, has been made, and I don't think this
is the proper venue to deal with it in any case.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 08 Dec 2009 09:40:41 +0100

SM wrote:
> There is a SMTP Service Extensions registry defined in Section 2.2.2 of 
> RFC 5321.

Of course there is! My bad :-(

>> This can be avoided with a well crafted IANA registry definition: RFC 
>> 5321 may just acknowledge that the extension mechanism can be reused 
>> by "other protocols", if they are similar enough to SMTP. The 
>> extensions IANA table definition may thus provide for adding a column 
>> for each look-alike protocol, and a row for each extension. The RFCs 
>> where the look-alike protocol is defined must also provide the column 
>> values for already registered extensions --which is what 4409bis would 
>> then do. Likewise, as new extensions register additional rows, they 
>> must provide the values for already existing columns.
> 

The term can be amended, e.g. "SMTP-like", "Mail Transport Extension 
Compatible", or any abstract class name that 4409bis and 5321bis can 
claim to inherit from.

It probably implies more work than it may seem worth to do just for 
design cleanliness. Rebuilding the registry may be worth if other 
amendments are needed (e.g. quoting the exact RFC 2119 keywords for 
the port indication, or listing an extension's commands.)