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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf