I am the assigned RAI-ART reviewer for draft-ietf-sieve-notify-sip-message-02.

For background on RAI-ART, please see the FAQ at
<http://www.softarmor.com/rai/art/FAQ.html>.

Please resolve these comments along with any other comments you may receive.

Summary: This draft is on the right track, but needs some more work prior to publication.

Major Issues:

-- Section 3.1

You limit the method parameter to SIP or SIPS URIs. I can imagine several reasons you might have done this, most likely to cut down on the number of URIs that could would indicate the SIEVE rule was for SIP. But there are other perfectly legitimate URI types for SIP MESSAGE requests. For example TEL URIs are fairly common. IM URIs are also legal for SIP MESSAGE, although you're not likely to see those in the wild--but that could change in the future. SIP may add new legal URI types in the future.

One way around this would be to have some other part of the notify "method" parameter identify the fact that a SIP MESSAGE request is intended, and then allow any URI type that is legal for SIP MESSAGE.

You also include the SIP URI method=parameter for the sake of extensibility. This would be an issue if you allowed other URI types, since the method parameter is not necessarily defined for all URI types. I'm also not sure this gives you the extensibility you want--you would not be able to do anything useful with "method=FOO" without some additional SIEVE spec on how to send SIP FOO requests. I think you would be better off leaving off the method URI parameter, and instead encode something in the :options parameter. 

[Note: I assume you added the method parameter based on feedback from Adam from a while back. I note that he suggested using either the method parameter, or something in :options. I am not disagreeing with him--I'm just suggesting that the :options approach is the better choice.]

-- Section 3.2, and the security considerations

You need to consider how the SIEVE implementation deals with SIP authentication, digest challenges, etc. For example, if the peer SIP device responds with a 401 or 407 containing a digest-challenge, what credentials should be used to respond to the challenge? Would you suggest the credentials of a particular user? If so, are their security considerations around having the SIEVE implementation know the credentials of a particular user? Or should the SIEVE implementation authenticate with server-wide credentials?

Do you allow TLS mutual authentication? If so, what client certificate should be presented?

-- section 3.6, third paragraph: "The policy of retry delivery..."

I'm not sure what you have in mind here. If you are talking about request retransmission as described in 3261, those are not suggestions--they are mandatory parts of the SIP state machine. If you mean something like "try again later because the destination party is offline" SIP doesn't have much to say about that except in a few specific response scenarios.


Minor Issues:

-- Section 3.1: "The processing application MUST extract a SIP address from the URI in accordance with the processing rules specified in RFC 3261 [SIP]. The resulting SIP address MUST be encapsulated in SIP URI syntax as Request-URI and the value of the "To" header field of the SIP MESSAGE request."

I think you've got the right idea here, but the terminology is wrong--I.e. the SIP URI _is_ the  SIP address. I think what you are after is something more along the lines of forming a SIP Request based on an "external" URI, similarly to what you might do with a URI in a hypertext link or on a business card. I suggest merely saying something along the lines of "form a SIP request according to the rules in rfc 3261"

-- section 3.4:

Do you expect the :importance tag to set the importance of the SIP MESSAGE request, or to convey the importance of the email that generated the notification in the first place? If the first, then you're doing it right. If the second, it might be more reasonable to put something in the body.

-- section 3.5:

This section needs to mention the SIP MESSAGE request size limits from RFC 3428. Is the body still expected to have a content-type of text/plain if no :message tag is present?

-- section 3.6, 1st paragraph:

This seems to contradict section 3.2

-- Section 3.7:

How could you ever know this, short of trying the message? The implementation would have to be presence aware to ever return something other than "maybe", and even then it can't be certain.

-- Section 5, item 1:

There are length limits for SIP MESSAGE requests that this draft should consider. They are large enough to be generally non constraining for this usage, but they exist.

-- section 5, item 4:

Your examples don't include DATE