Re: [yam] Extension spec mandating multiple venues?

S Moonesamy <> Fri, 12 February 2010 00:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 026A63A72A6 for <>; Thu, 11 Feb 2010 16:06:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.913
X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OD0vM1FkHSFg for <>; Thu, 11 Feb 2010 16:06:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4675B3A6816 for <>; Thu, 11 Feb 2010 16:06:06 -0800 (PST)
Received: from ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id o1C07FcR028617 for <>; Thu, 11 Feb 2010 16:07:21 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple;; s=mail; t=1265933242; x=1266019642; bh=YXbXuCOMxSQA1erxEkMIpBzmAFs=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type; b=wgBbzG2Ko7cwQhjqI4/vKqlYNE8lJiP5QPCBOVPPnq4i4UbyL4Nc7eHVxcpTXaYKg d16fkk3C+MDFVpubTR/7yH71jXMNyYHY7s7GP+xDstBrYneL5YFc2GuQqPPoKOeypa 4gbRxWzFtL89dq04PmTRN/p3n47D0xTt/z2raHn8=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Thu, 11 Feb 2010 16:06:53 -0800
From: S Moonesamy <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: Re: [yam] Extension spec mandating multiple venues?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Feb 2010 00:06:07 -0000

At 10:33 11-02-10, Dave CROCKER wrote:
>On 1/25/2010 1:55 AM, Alessandro Vesely wrote:
>>On 20/Jan/10 23:45, wrote:
>>>Title : SMTP Service Extension for 8-bit MIME Transport
>>Should section 2 mention that the extension is valid for both SMTP and
>>Submit? I haven't got that bit quite straight, yet...

This is being tracked as Issue # 17.  I added Dave's comment with 
it.  If you would like them to be tracked as separate issues, please 
send me an email.

>Given that an extension like this declares its intended venue -- 
>note "/SMTP/ Service Extension"  I would guess that it should also 
>declare other venues that it is valid for.  So yeah, it might be 
>appropriate to have it declare that it's for Submit, also.
>But I'm not positive.  I'm particularly concerned that there might 
>be a subtle issue here that I'm missing.

As an individual comment, it may be more of a legacy issue than a 
subtle issue.  Section 7 of RFC 4409 lists 8BITMIME as a SHOULD for 
Submit together with a reference to RFC 1652.  When an extension 
specification declares its intended venue, there is an IANA 
registration and the requirement level as a guidance for 
implementers.  I don't see any issue for RFC 1652bis as a person 
implementing Submit will find the declaration in RFC 4409.

S. Moonesamy