Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14

Dave Crocker <dhc@dcrocker.net> Mon, 04 June 2012 20:15 UTC

Return-Path: <dhc@dcrocker.net>
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 83E4211E80EC; Mon, 4 Jun 2012 13:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 iuxPqvlbYGjV; Mon, 4 Jun 2012 13:15:37 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CAE2911E80E8; Mon, 4 Jun 2012 13:15:36 -0700 (PDT)
Received: from [192.168.2.101] (g225186006.adsl.alicedsl.de [92.225.186.6]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q54KFTTh025262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Jun 2012 13:15:31 -0700
Message-ID: <4FCD175D.30307@dcrocker.net>
Date: Mon, 04 Jun 2012 22:15:25 +0200
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>
References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com>
In-Reply-To: <4FCA6BFE.3050609@isode.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 04 Jun 2012 13:15:36 -0700 (PDT)
Cc: draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
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: Mon, 04 Jun 2012 20:15:38 -0000

Alexey,


On 6/2/2012 9:39 PM, Alexey Melnikov wrote:
>>>>> 5.2. Timely Delivery
>>>>>
>>>>> An important constraint (usually associated with higher priority
>>>>> levels) is that messages with high priority have some delivery time
>>>>> constraints. In some cases, higher priorities mean a shorter maximum
>>>>> time allowed for delivery.
>>>>>
>>>>> Unextended SMTP does not offer a service for timely delivery. The
>>>>> "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in
>>>>> [RFC2852] is an example of an SMTP extension providing a service that
>>>>> can be used to implement such constraints. But note that use of the
>>>>> DELIVERBY extension alone does not guarantee any priority processing.
>>>>
>>>> It seems as if this section introduces an issue but does not actually
>>>> deal with it. Perhaps there should be some discussion of the possible
>>>> (or required?) interaction between the two extensions it discusses?
>>>
>>> There is no issue and no real interaction in this specific case. A
>>> client that wants to use both against a server that supports both should
>>> consider this issue.
>>
>> Specifications that say an implementer should consider something but
>> which gives no guidance about the consideration aren't doing much
>> useful, in my view.
>>
>> As this set of text was proceeding, I thought it was going to provide
>> some useful guidance about possible uses of the combined options,
>> since it seemed like the combination could be, well, useful.
>
> The client can decide to use smaller values. In this case it is up to
> the client to pick them, this is not controlled by the site policy.

Once again:  it is not reasonable to have different clients apply 
different semantics (policies) for choosing values.  The values need to 
have consistent meaning across the entire the trust environment that is 
supporting this mechanism.

Otherwise, it won't work properly.

The environment will be left with individual clients taking more than 
their fair share. Or trying to.

Absent very specific rules to be applied consistently across the trust 
environment, what is most likely is that every client will always claim 
top priority and no one will actually get it.  (This is a well-known 
phenomenon for this sort of game-theoretic condition.)

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net