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

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.