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

SM <sm@resistor.net> Mon, 07 December 2009 15:24 UTC

Return-Path: <sm@resistor.net>
X-Original-To: yam@core3.amsl.com
Delivered-To: yam@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918463A6826 for <yam@core3.amsl.com>; Mon, 7 Dec 2009 07:24:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3zcpIVz0jiQ for <yam@core3.amsl.com>; Mon, 7 Dec 2009 07:24:43 -0800 (PST)
Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 75CB23A6A65 for <yam@ietf.org>; Mon, 7 Dec 2009 07:24:34 -0800 (PST)
Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id nB7FODpN013696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Dec 2009 07:24:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1260199461; x=1260285861; bh=xPIJt/2HNbxKq0ZnFrKNOu/492V2UT/birBPlU8EuCI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=EAQIMz4/3vvj+ruYOW/YNtrcwIt2qDuPUEd7ZXKJ5kxZTalMsiGp5nNnvyb4yMBXW hXkIMuukw+crW/vn/AORfQf1MCOKDOmQtbdiC0J9d7d5OsdZO0tG0jnA1HA8oyo1JM RWsSJUI7jqSNRRjXQ2yR8KxWaQuBkSeh/6gB7KPU=
DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=aTDS6GaSR8KQJ1K6Bxwob9vPvy2CVCbfAQviNhlcJtE2cBXoMy9O53wB2Fmy5O4zQ JfS1SmN8hSAihQJWlnHRGxY7US0UT/rB4oyuyTNi+b9WwpYutEY4VT6Jol9ME1LMC7x 4EGcrG5KfToGmp+fGNzceJAMKBmqR8p4vV6pB1o=
Message-Id: <6.2.5.6.2.20091207070135.04806158@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 07 Dec 2009 07:23:50 -0800
To: Alessandro Vesely <vesely@tana.it>
From: SM <sm@resistor.net>
In-Reply-To: <4B1CD072.5070109@tana.it>
References: <6.2.5.6.2.20091206010955.033ce0a0@elandnews.com> <4B1BE127.2010804@tana.it> <6.2.5.6.2.20091206100948.045f4670@resistor.net> <4B1CD072.5070109@tana.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: yam@ietf.org
Subject: Re: [yam] Issue #7: RFC 5321 Section 2.2.2: add a bullet for the definition of extensions
X-BeenThere: yam@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <yam.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/yam>
List-Post: <mailto:yam@ietf.org>
List-Help: <mailto:yam-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2009 15:24:44 -0000

Hi Alessandro,
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.  The IANA Considerations section of 4409bis would have 
to be updated with text about the registry.  There is already a 
registration procedure.

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

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

Is anybody working on the LMTP specification?

Regards,
-sm