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

[Ned Freed <[e-mail]>]

> >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 registry already mentions SMTP and Submit.  Instructions to IANA
> 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.

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

> 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