Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities

Rex Buddenberg <budden@nps.navy.mil> Tue, 13 June 2006 19:09 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqEG7-00031k-RR; Tue, 13 Jun 2006 15:09:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqEG7-00031f-2b for ieprep@ietf.org; Tue, 13 Jun 2006 15:09:03 -0400
Received: from virginia.nps.edu ([205.155.65.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqEG5-00045I-4J for ieprep@ietf.org; Tue, 13 Jun 2006 15:09:03 -0400
Received: from north-latitude.nps.navy.mil ([131.120.179.249] RDNS failed) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 12:08:59 -0700
Subject: Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities
From: Rex Buddenberg <budden@nps.navy.mil>
To: Michael Schmeing <schmeing@fgan.de>
In-Reply-To: <20060612130135.GD9821@nordhorn.fkie.fgan.de>
References: <20060612130135.GD9821@nordhorn.fkie.fgan.de>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 13 Jun 2006 12:08:41 -0700
Message-Id: <1150225721.17922.135.camel@north-latitude.nps.navy.mil>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.0
Content-Transfer-Encoding: quoted-printable
X-OriginalArrivalTime: 13 Jun 2006 19:08:59.0626 (UTC) FILETIME=[D3769CA0:01C68F1C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Cc: ieprep@ietf.org
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

coupling of possibly disparate efforts.

Michael,

Suggest you check out Common Alerting Protocol to avoid gratuitous
incompatabilities.  CAP is designed as a content framework (essentially
an XML-based data dictionary) for alerting.  E-mail is one, among many,
means of delivery of such information.  Here's the .sig from the
discussion list that should have plenty of pointers:

-------------

This list is for public discussion of the Common Alerting Protocol.
This list is NOT part of the formal record of the OASIS Emergency
Management TC.  Comments for the OASIS record should be posted using the
form at
http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency
CAP-list mailing list
CAP-list@lists.incident.com
http://eastpac.incident.com/mailman/listinfo/cap-list

This list is not for announcements, advertising or advocacy of any
particular program or product other than the CAP itself.

-------------




On Mon, 2006-06-12 at 15:01 +0200, Michael Schmeing wrote:
> 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


_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep