[Top] [All Lists]

Re: draft-ietf-sieve-notify-sip-message

2009-02-08 11:33:13

[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".


<Prev in Thread] Current Thread [Next in Thread>