[Re-sending, per list-maintainer's instructions]
Alexey Melnikov wrote:
I would suggest that the draft be amended to either *require* a
"method" URI parameter (with "MESSAGE" indicating the mechanism
described in this document), or to include additional information in
the ":options" tag that explicitly indicates the use of this
document's mechanism.
I think requiring the method URI parameter would be best.
I agree -- that would seem to require the least specification.
My second area of concern is with the handling of the "From" header
field. The draft-ietf-sieve-notify document clearly intends the
":from" value to indicate the value that is typically rendered to the
contacted party as the source of the message. This intended behavior
is upheld by the language in section 2.3 of
draft-ietf-sieve-notify-mailto-10 (it places this value in the SMTP
"From:" header, and even suggests using the value in the "RCPT FROM"
command -- despite the easy availability of an SMTP "Reply-To:"
header). This mismatch in semantics between the protocols causes me
concern, as it may surprise users to have radically different
treatment of the value in the ":from" tag among protocols. Given the
text in the base sieve-notify document, I believe that the behavior
in sieve-notify-mailto is correct, and that the behavior in
sieve-notify-sip should be modified to align with it.
Ok, you've convinced me that use of the SIP Reply-To header field is
not a good idea. Are you recommending use of the From SIP header field?
Yes. Subject to local policy, of course -- section 3.3 of the base spec
covers the policy aspects of ":from".
/a