Subject: [sieve] Fwd: RAI-ART review of draft-ietf-sieve-notify-sip-message-02

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 01 Sep 2010 16:47:36 -0600

Ask and ye shall receive! :)

Many thanks to Ben Campbell for the review.

/psa

-------- Original Message --------
Subject: RAI-ART review of draft-ietf-sieve-notify-sip-message-02
Date: Wed, 1 Sep 2010 17:30:48 -0500
From: Ben Campbell <[email-masked]>
To: [email-masked], [email-masked]
CC: Peter Saint-Andre <[email-masked]>

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