[RAI] draft-ietf-sieve-notify-sip-message

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

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

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.

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. (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.

/a
_______________________________________________
RAI mailing list
RAI@ietf.org
https://www.ietf.org/mailman/listinfo/rai