On 05/03/2012 19:40, Barry Leiba wrote:
2. I, too, noticed all the lower-case should and may words. I
suggest that the best way to handle this is to make the following
change to the RFC 2119 citation text at the beginning of section 2:
NEW
The key words MUST, MUST NOT, REQUIRED, SHALL,
On 05/03/2012 18:00, Murray S. Kucherawy wrote:
-Original Message-
From: Alexey Melnikov [mailto:alexey.melni...@isode.com]
Sent: Monday, March 05, 2012 4:00 AM
To: Murray S. Kucherawy
Cc:ietf@ietf.org
Subject: Re: Last Call:draft-melnikov-smtp-priority-07.txt (Simple
Mail Transfer
Hi Ned,
On 05/03/2012 15:34, Ned Freed wrote:
That said, I think an important omission in this document is that it
only allows MSA's to change message priorities to conform to site
policy.
MTAs should also be allowed to do this.
Can you elaborate a bit more on possible use cases?
Is the following better:
tThe 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
On 3/3/12 7:07 PM, ned+i...@mauve.mrochek.com wrote:
This draft also defines the MT-Priority header field. �It is quite unusual
for a SMTP extension specification to define a mail header field. ...
This is my major concern about this protocol as well, as I note in the
PROTO writeup (which,
On 01/03/2012 20:49, Barry Leiba wrote:
I had expected that we'd deal with my shepherd review before doing the
last call on the document. Because that didn't happen, I'll re-post
my review here, as public last-call comments. Maybe that will prevent
people from raising the same things I've
Hi Murray,
Thank you for the comments. Some answers below.
On 01/03/2012 04:43, Murray S. Kucherawy wrote:
I have several comments on this draft. But first, this is a big improvement
since the last version I reviewed, so kudos to the authors.
A couple of these refer to issues in the document
Hi Ned,
On 02/03/2012 06:12, Ned Freed wrote:
The most significant item that needs to be called out is the issue of
tunneling the PRIORITY value through non-conforming MTAs by turning it
into a message header field (MT-Priority) and then back again. This
is a problematic technique, but is an
On 03/03/2012 18:07, ned+i...@mauve.mrochek.com wrote:
[...]
So I have two suggestions. One is to leave it as is, and make it
experimental. If it turns out the tunnels all work the same way, you
can come back and add the spec about how they work and rev it as
standards track. The other is to
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
I do prefer the latter as well (and yes, happy to remove the restriction),
but I don't feel very comfortable pretending that tunneling wouldn't happen.
Of course people will tunnel stuff. But will they all tunnel it the same
way, in which case a standard could be useful, or will they each
That said, I think an important omission in this document is that it
only allows MSA's to change message priorities to conform to site policy.
MTAs should also be allowed to do this.
Can you elaborate a bit more on possible use cases?
Nobody is going to simply allow priorities to be set
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
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
At 20:11 02-03-2012, John Levine wrote:
So I have two suggestions. One is to leave it as is, and make it
experimental. If it turns out the tunnels all work the same way, you
can come back and add the spec about how they work and rev it as
standards track. The other is to take out the tunnel
-Original Message-
From: Alexey Melnikov [mailto:alexey.melni...@isode.com]
Sent: Monday, March 05, 2012 4:00 AM
To: Murray S. Kucherawy
Cc: ietf@ietf.org
Subject: Re: Last Call: draft-melnikov-smtp-priority-07.txt (Simple
Mail Transfer Protocol extension for Message Transfer
2. I, too, noticed all the lower-case should and may words. I
suggest that the best way to handle this is to make the following
change to the RFC 2119 citation text at the beginning of section 2:
NEW
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT,
2. I, too, noticed all the lower-case should and may words. I
suggest that the best way to handle this is to make the following
change to the RFC 2119 citation text at the beginning of section 2:
NEW
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT,
I've used text like this before, and the IESG has never objected to
it. One advantage with this formulation, which uses the standard 2119
text and *appends* to it, is that idnits likes it and doesn't generate
a warning.
More generally, ID-nits is supposed to be helpful. Straightjackets are
I do prefer the latter as well (and yes, happy to remove the restriction),
but I don't feel very comfortable pretending that tunneling wouldn't happen.
Of course people will tunnel stuff. But will they all tunnel it the same
way, in which case a standard could be useful, or will they each
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
On Mon, Mar 5, 2012 at 22:02, Ned Freed ned.fr...@mrochek.com wrote:
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]
This draft also defines the MT-Priority header field. �It is quite unusual
for a SMTP extension specification to define a mail header field. ...
This is my major concern about this protocol as well, as I note in the
PROTO writeup (which, unfortunately, can't be seen publicly because of
a
Barry Leiba wrote:
What I'm interested in community input on is
whether the mechanism of transferring the information back and forth
between the two, and having SMTP protocol get involved in inspecting and
altering header fields is a good thing.
I may be too old school, but I still believe
On Fri, Mar 2, 2012 at 6:47 AM, Hector sant9...@gmail.com wrote:
If I understand where you going with this, IMV, I don't think it is a good
thing SMTP systems should be expected will be processing the payload or its
headers before the EOD is issued.
This document doesn't specify anything that
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Barry
Leiba
Sent: Friday, March 02, 2012 6:27 AM
To: ietf@ietf.org
Subject: Re: Last Call: draft-melnikov-smtp-priority-07.txt (Simple
Mail Transfer Protocol extension for Message Transfer
Barry Leiba wrote:
On Fri, Mar 2, 2012 at 6:47 AM, Hector sant9...@gmail.com wrote:
If I understand where you going with this, IMV, I don't think it is a good
thing SMTP systems should be expected will be processing the payload or its
headers before the EOD is issued.
This document doesn't
This draft also defines the MT-Priority header field. �It is quite unusual
for a SMTP extension specification to define a mail header field. ...
This is my major concern about this protocol as well, as I note in the
PROTO writeup (which, unfortunately, can't be seen publicly because of
a
I had expected that we'd deal with my shepherd review before doing the
last call on the document. Because that didn't happen, I'll re-post
my review here, as public last-call comments. Maybe that will prevent
people from raising the same things I've already raised.
First, two additional points:
At 16:42 29-02-2012, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Simple Mail Transfer Protocol extension for Message Transfer
Priorities'
draft-melnikov-smtp-priority-07.txt as a Proposed Standard
The IESG plans to
This draft specifies a SMTP extension. The IANA Considerations does not
mention registration in the the SMTP Service Extensions registry.
It certainly does, in the first paragraph:
This specification requests IANA to add the PRIORITY SMTP extension
to the SMTP Service Extensions
Also, because it's not publicly visible, here's my PROTO writeup for
this document:
The publication of draft-melnikov-smtp-priority as a Proposed Standard
is requested by an individual contributor.
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational,
Hi Barry,
At 13:53 01-03-2012, Barry Leiba wrote:
It certainly does, in the first paragraph:
I missed that.
Section 3:
7. The PRIORITY extension is valid for the submission service
[RFC6409] and LTMP [RFC2033].
And that one.
This is my major concern about this protocol as
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM
Sent: Thursday, March 01, 2012 1:36 PM
To: ietf@ietf.org
Cc: Alexey Melnikov
Subject: Re: Last Call: draft-melnikov-smtp-priority-07.txt (Simple
Mail Transfer Protocol extension for Message
...@ietf.orgjavascript:;]
On Behalf Of SM
Sent: Thursday, March 01, 2012 1:36 PM
To: ietf@ietf.org javascript:;
Cc: Alexey Melnikov
Subject: Re: Last Call: draft-melnikov-smtp-priority-07.txt (Simple
Mail Transfer Protocol extension for Message Transfer Priorities) to
Proposed Standard
This draft
From: barryleiba.mailing.li...@gmail.com
[mailto:barryleiba.mailing.li...@gmail.com] On Behalf Of Barry Leiba
Sent: Thursday, March 01, 2012 3:01 PM
To: Murray S. Kucherawy
Cc: ietf@ietf.org
Subject: Re: Last Call: draft-melnikov-smtp-priority-07.txt (Simple Mail
Transfer Protocol
Barry Leiba barryle...@computer.org wrote:
Oh, it's absolutely true that if one is to define this sort of thing as a
combination of SMTP protocol and message header fields, that should be done
in a single specification. What I'm interested in community input on is
whether the mechanism of
What I'm interested in community input on is whether the mechanism of
transferring the information back and forth between the two, and
having SMTP protocol get involved in inspecting and altering header
fields is a good thing.
you're kidding, right? talk about primrose path. did you not
The most significant item that needs to be called out is the issue of
tunneling the PRIORITY value through non-conforming MTAs by turning it
into a message header field (MT-Priority) and then back again. This
is a problematic technique, but is an important capability for those
who need and
On 2 mar 2012, at 00:00, Barry Leiba wrote:
What I'm interested in community input on is whether the mechanism of
transferring the information back and forth between the two, and having SMTP
protocol get involved in inspecting and altering header fields is a good
thing.
No, not change
I have several comments on this draft. But first, this is a big improvement
since the last version I reviewed, so kudos to the authors.
A couple of these refer to issues in the document that need to be resolved
before it can move forward, but you probably already know what they are. The
rest
The IESG has received a request from an individual submitter to consider
the following document:
- 'Simple Mail Transfer Protocol extension for Message Transfer
Priorities'
draft-melnikov-smtp-priority-07.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks,
42 matches
Mail list logo
