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

[[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.

I'm sorry, but that's simply a strawman. AFAICT nobody pushing back on this is
suggesting mapping MTA priority to or from a field with totally different
semantics. But there are plenty of fields in common use that are used to
control MTA priority. Those are the fields I'm talking about.

And yes, people will make mistakes. They always do. But as I commented
in a previous discussion, if we let that stop us we'd never standarize
anything.

> 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?

No. Like it or not, if you expect this to gain any traction at all, you're
going to have to accept the fact that people are going to want to tunnel it
through fields with the same general semantics but restricted as to possible
values.

  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.

I hadn't noticed importance listed as a possible source of MTA priority
information. That's actually committing the error of mapping a field with
entirely different semantics into MTA priority and at a minimum needs to be
removed - we should NOT be encouraging that.

> 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.

It seems you're complaining about other people doing something they never
wanted to do while actually making that error yourself.

				Ned