Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01

S Moonesamy <sm+ietf@elandsys.com> Tue, 10 January 2012 17:29 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3B321F84E7 for <apps-discuss@ietfa.amsl.com>; Tue, 10 Jan 2012 09:29:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.687
X-Spam-Level:
X-Spam-Status: No, score=-102.687 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7t-DEwJ1tPq for <apps-discuss@ietfa.amsl.com>; Tue, 10 Jan 2012 09:29:37 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA7521F8495 for <apps-discuss@ietf.org>; Tue, 10 Jan 2012 09:29:36 -0800 (PST)
Received: from SUBMAN.elandsys.com ([41.136.237.250]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0AHTEx8020196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Tue, 10 Jan 2012 09:29:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1326216575; i=@elandsys.com; bh=ROdREfGssGUnhugD3baCkja8EWrcJTlfgWlec0won6c=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=0bFkuPyF6QGwE9PTxWLtECLEM4SgLRreIA5L67ObkBjTjJDrX53olk8ybE+P9pl/T cm2ETVNj3iB5YqRG03ZEfHwjJ6EnxwNEVP65RfE/mtsw2mo4MddlUknpU1WO7CvQFW EaP9VqFktoc5Ofgf0wsgRA+9STYp9BHWYP4u0NFM=
Message-Id: <6.2.5.6.2.20120110084205.0cee1da8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 10 Jan 2012 09:12:30 -0800
To: apps-discuss@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <4F0C595B.2020909@tana.it>
References: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com> <4F06EEFD.1060707@tana.it> <6.2.5.6.2.20120106140451.09c30c18@resistor.net> <4F0896E2.7040303@tana.it> <6.2.5.6.2.20120107114742.0ba21628@resistor.net> <4F0AC75E.3030709@tana.it> <6.2.5.6.2.20120109133139.08d63218@resistor.net> <4F0C595B.2020909@tana.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jan 2012 17:29:41 -0000

At 07:29 10-01-2012, Alessandro Vesely wrote:
>Since you said one doesn't have to be the registrant of localhost.com
>in order to use it as a list-id, it's still not clear.  Does the spec
>mandate that list-id-namespace MUST be an existing domain name?

No, but it can still discuss about how to avoid namespace collisions.

>Nevertheless, BCP 167 proposes List-Post as a candidate domain
>identifier.  Accordingly, DKIM driven heuristics should use that field
>rather than List-Id.

That BCP is about DKIM.

>By keeping them separate, you turn this state of affairs into a
>tradition.  I mean that more stiffness will be needed to merge them in
>the future, assuming they will happen to be rewritten simultaneously
>again.

Ok.

>Yeah, it is curious that we consider number databases more solid in
>that respect.  (Is it because we only have five?)  To ease the

Sorry, I cannot comment about this.

>One side effect of merging 2919 into 2369 is to corroborate the idea
>that List-Id is tailored for discussion lists.  You may have
>alternative ideas to express the same concept without merging.  In any
>case, since the possibility to use it as a policy element of bulk
>commercial messaging is not fully supported, it may make sense to tell it.

The drafts are about interoperability.  If commercial messaging 
causes interoperability issues, it can be discussed in the draft.

>BTW, isn't it worth to reference BCP 167?

No.

Thanks for the comments.

Regards,
S. Moonesamy