Re: Last Call: <draft-melnikov-smtp-priority-07.txt> (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard

[Barry Leiba <[e-mail]>]

Ned:
>> Another issue is the silly prohibition against using Priority: and other
>> header fields to set priority levels. What if is existing site policy is in fact
>> to use those fields to determine message priority?

Alexey:
> I actually don't have a strong feeling against usage of other existing
> header fields.
> Some of the existing header fields don't have the exact semantics desired
> here. Others (like the MIXER's Priority) have the right semantics but don't
> support sufficient number of priorities required by MMHS (6 levels). That is
> why a new header field was introduced.

Right, this is the issue I have with Ned's desire to allow use of
other fields: those fields have inconsistent semantics, and
inconsistent and non-standard usage.  They're often used to indicate
visual importance of the message to the MUA, rather than anything
related to transmission priority.

That said, I'd have no problem with some sort of MAY-level permission
to *MSAs* to use these fields.  I'd feel very uncomfortable allowing
*MTAs* to do it.  Ned, would it be adequate to your needs to handle it
that way?  Something like this:

OLD
   Other message header fields, such as Importance [RFC2156], Priority
   [RFC2156] and X-Priority, MUST NOT be used for determining the
   priority under this "Priority Message Handling" SMTP extension.

NEW
   Other message header fields, such as Importance [RFC2156], Priority
   [RFC2156] and X-Priority, are used inconsistently and often with
   different semantics from MT-Priority.  Message Submission Agents
   [RFC6409] MAY use such fields to assign an initial priority in the
   absence of an SMTP PRIORITY parameter.  Otherwise, such fields
   MUST NOT be used for determining the priority under this "Priority
   Message Handling" SMTP extension.

Barry