[Top] [All Lists]

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

2009-02-01 10:26:11

Adam Roach wrote:

Mary Barnes has asked me to perform an expert review on draft-ietf-sieve-notify-sip-message for the RAI area.

Hi Adam,
Thank you for the review and sorry for the slow response.

Overall, the approach in the document seems good. However, there are two relatively minor details that cause me some concern. I think these should be rather straightforward to fix.

My first area of concern is that, while this seems a reasonable way to perform this functionality in SIP, I don't think it's the only reasonable way to do it in SIP. Consequently, this document needs to take care not to preclude future SIP mechanisms for SIEVE notifications. For example, the conveyance of more semantic information in a PUBLISH message would be quite useful when there is a dynamically changing community of parties interested in receiving notifications. (The PUBLISH would be sent to an event agent, which could then receive SUBSCRIBE requests from interested parties). This may be applicable, for example, when monitoring shared resources, such as technical support email queues.

However, the draft makes an implicit assumption that any SIEVE notification method URI starting with "sip:" necessarily will make use of the mechanism it defines, and never any other. There is no means for disambiguating among multiple mechanisms. In fact, the draft seems to go out of its way to ruin an extensibility mechanism that it would have automatically inherited from SIP: "The URI parameter 'method' MUST be ignored, because only the MESSAGE method is allowed by this specification."

Right. I agree that allowing other SIP methods might be useful in the future.

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.

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?

(Indication of the sending server can be made via other means, such as the SIP Call-Info: header field).

Responses to the SIEVE working group mailing list, CC me.

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