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

From: Adam Roach <[email-masked]>
Date: Fri, 09 Jan 2009 15:24:02 -0600

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
[email-masked]
https://www.ietf.org/mailman/listinfo/rai

---

From: Adam Roach <[email-masked]>
Date: Mon, 02 Feb 2009 12:28:56 -0600

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.

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

/a

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 01 Feb 2009 15:14:33 +0000

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

> text in the base sieve-notify document, I believe that the behavior in 
> sieve-notify-mailto is correct, and that the behavior in 

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

---

From: Adam Roach <[email-masked]>
Date: Sun, 08 Feb 2009 10:17:31 -0600

[Re-sending, per list-maintainer's instructions]

/a