[Ieprep] Discussion of Internet-Draft for SMTP priorities
Michael Schmeing <schmeing@fgan.de> Mon, 12 June 2006 13:11 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpmCm-0003qQ-2q; Mon, 12 Jun 2006 09:11:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpmCk-0003lC-Do for ieprep@ietf.org; Mon, 12 Jun 2006 09:11:42 -0400
Received: from mailguard.fgan.de ([128.7.3.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpm30-0007RL-Lk for ieprep@ietf.org; Mon, 12 Jun 2006 09:01:41 -0400
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with smtp (Exim 4.50) id 1Fpm2z-0007nQ-BD for ieprep@ietf.org; Mon, 12 Jun 2006 15:01:37 +0200
Received: from nordhorn.fkie.fgan.de ([128.7.5.132]) by mailhost.fgan.de with smtp (Exim 3.36 #5 (Solaris)) id 1Fpm2y-0004n6-00 for <ieprep@ietf.org>; Mon, 12 Jun 2006 15:01:36 +0200
Received: by nordhorn.fkie.fgan.de (sSMTP sendmail emulation); Mon, 12 Jun 2006 15:01:35 +0200
Date: Mon, 12 Jun 2006 15:01:35 +0200
From: Michael Schmeing <schmeing@fgan.de>
To: ieprep@ietf.org
Message-ID: <20060612130135.GD9821@nordhorn.fkie.fgan.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Organization: Forschungsgesellschaft fuer Angewandte Naturwissenschaften e.V. (FGAN)
User-Agent: Mutt/1.5.11+cvs20060403
X-Virus-Scanned: yes (FGAN VirusScan III)
X-Scan-Signature: d2cf15bdfe212a5b41ac9f74731b6b74
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Subject: [Ieprep] Discussion of Internet-Draft for SMTP priorities
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Errors-To: ieprep-bounces@ietf.org
Hello all, sorry it took so long for me to get back to you, but it has been a very busy time. As there appears to be some interest in at least discussing the draft, I will start by summarising Dan Wings´s input (both his submissions to the list and his suggestions he made directly to me) and give my view on these suggestions. Dan´s first suggestion in his email directly to me was to use priority levels 0, 100, 200, 300 and 400 instead of 0, 1, 2, 3 and 4. As the length of the priority identifier is now limited to three digits, I think that is a valid suggestion. I plan to include that in the next version of the draft, unless someone can give good reasons to stick with the old scheme or use a completely new one. Another of Dan´s suggestions in that email was to use the IANA to register the priority levels. He mentions that this would remove the problem with the Priority: and Precedence: header fields where some vendors use keywords and others (numerical) values. I am not sure it is really required to register the priority levels with IANA basically for two reasons: 1. The draft (and therefore the standard if it ever comes to that) defines the allowed value of the PRIORITY keyword to be only a numerical value. Thus the problem with the AFAIK not standardised header fields can not occur: Anyone conforming to the standard has to use numerical values according to the priority policy indicated. If anyone decides not to obey the standard, they would not care about IANA registration either. 2. The provided policy is only an example. Priority policy enforcement across administrative domain boundaries is difficult to say the least. For the general Internet, the most that I expect to be realistic is some form of Quality-of-Service, where Internet Providers would transport emails (or any other content) of some customers (which probably have to pay extra for this) more quickly than the traffic of other customers (keyword: net (non-)neutrality). They would define their own policy with their own priority levels for the use of email priorities, if they allow their customers to downgrade their service level on a per-email/per-connection basis. If, on the other hand, the group feels that we should go for IANA registration, that is fine with me. In that case, I would just ask someone to provide a wording example for this, because I have never done it yet. A problem Dan mentions in his email to the mailing list is the problem of authorisation. He asks the question of what will stop him from using highest priority on all emails and says that it can be solved within an administrative domain but probably not across them. As I have already indicated above, I see this problem as well. When I created the I-D, it was for a scenario of cooperating administrative domains and thus, this problem did not present itself: The domain administrations had agreed on a policy for the use of priorities. Of course, one thing preventing excessive use of high priorities is the size limit on high-priority emails. You can not put much data in two or four kilobyte, so you have to use lower priorities for larger emails. Other than that, I only have one rough idea so far how this issue could be addressed in a general case that I would like your opinion on: The policy could impose a frequency with which one sender may issue emails of the higher priorities. Together with the smaller size of high-priority emails that should guarantee at least some space for lower priority emails Best regards, Michael Schmeing -- **************************************************** | Michael Schmeing E-Mail: schmeing@fgan.de | | FGAN/FKIE Tel: (+49) 228/9435 593 | | Neuenahrer Strasse 20 Fax: (+49) 228/9435 685 | | D-53343 Wachtberg, Germany | **************************************************** _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep
- [Ieprep] Discussion of Internet-Draft for SMTP pr… Michael Schmeing
- Re: [Ieprep] Discussion of Internet-Draft for SMT… Janet P Gunn
- Re: [Ieprep] Discussion of Internet-Draft for SMT… Michael Schmeing
- [Ieprep] Re: Discussion of Internet-Draft for SMT… John Rosenberg
- Re: [Ieprep] Re: Discussion of Internet-Draft for… Janet P Gunn
- Re: [Ieprep] Discussion of Internet-Draft for SMT… ken carlberg
- Re: [Ieprep] Discussion of Internet-Draft for SMT… Rex Buddenberg
- Re: [Ieprep] Discussion of Internet-Draft for SMT… Michael Schmeing
- Re: [Ieprep] Discussion of Internet-Draft for SMT… ken carlberg
- Re: [Ieprep] Discussion of Internet-Draft for SMT… Michael Schmeing