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

[Alessandro Vesely <[e-mail]>]

SM wrote:
> At 01:52 07-12-2009, Alessandro Vesely wrote:
>> 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?
> 
> 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 registry already mentions SMTP and Submit.  Instructions to IANA 
> should be clear.  It is better to avoid terms like "other protocols".

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