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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Is the following better:
>
> <t>The Importance <xref target="RFC2156"/> header field MUST NOT be used for
> determining
>      the priority under this "Priority Message Handling" SMTP extension.
>      In absence of both the PRIORITY MAIL FROM parameter and the MT-Priority
> header field,
>      other message header fields, such as Priority <xref target="RFC2156"/>
> and X-Priority,
>      MAY be used for determining the priority under this "Priority Message
> Handling" SMTP extension.
> </t>

What I don't like about that are:
1. It forbids using Importance, but doesn't say *why*, which could
invite misuse of other similar fields that are floating around.
2. I think MAY is fine for MSAs, but too weak for MTAs.  I accept what
Ned says, that MTAs will do this regardless of what we say.  That can
argue against MUST NOT, but I think SHOULD NOT is appropriate.  I
think the *standard* does want to discourage it, even while accepting
that it will happen.

I'd still like to wait for Ned's version of some text.  While we wait,
let me alter my earlier proposal and re-propose it here:
----------------------------
  Other message header fields, such as "Importance" [RFC2156],
  "Priority" [RFC2156] and "X-Priority", are used inconsistently and
  often with different semantics from MT-Priority.  Fields, such as
  "Importance", that are used to show a sense of importance to the
  end user are particularly ill-suited to convey transport priority, as
  these are distinct aspects of a message. Fields used inconsistently,
  such as "X-Priority", are problematic in this regard: we don't know
  what the intent was when the field was added.

  Therefore:

  1. Message header fields that have a sense of showing importance
  to the end user MUST NOT be used to determine the priority under
  this SMTP extension.

  2. Message Submission Agents [RFC6409] MAY use other header
  fields that have a sense of transport priority in order to assign an
  initial priority in the absence of an SMTP PRIORITY parameter.

  3. Message Transfer Agents handling messages after submission
  SHOULD NOT use any field other than MT-Priority to determine the
  priority under this SMTP extension.
----------------------------

Are we getting close?

Barry
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]