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.