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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf