Inline. =A0Areas of agreement snipped.

On Thu, Jun 20, 2013 at 1:40 = AM, Charles Shen <charles@cs.columbia.edu> wrote:

To be clear on this, the ambiguity here is with regard to the <exc= ept domain=3D"..."> case. =A0In the <one id=3D"...&quo= t;> case, you just do Tel URI comparison.

Thinking on this a little more, it looks like your use = of the "domain" parameter actually breaks with RFC 4745. =A0Accor= ding to RFC 4745, there must be an exact match between the "domain&quo= t; value provided by the using protocol and the value in the "domain&q= uot; parameter. =A0I can't think of a way that this document could defi= ne a way to extract a domain from a telephone number that would meet the se= mantic you seem to be intending.

So it seems like you need to do one of the following:
1. Define a rule for how you compute a domain value from a tel: UR= I.
2. Define a new element for use under <many> (since <= except> lacks an extension point)

3. Drop support for excluding phone numbers by domain (you just have t= o enumerate the exceptions individually)

[CS] If we opt = for Option 1, can we do the following:

a. assume E.164 numbers always start with + sign, so we= can use the digits after the + sign (after removing any visual separaters,= as in the Tel URL comparison rules) as the presumed domain value.=A0

b. for local numbers (numbers that do not start with +), the &quo= t;phone-context" contains the domain value.=A0
=

Are you sure that gives you the expressive= ness you want? =A0It doesn't allow you to exclude based on an arbitrary= prefix. =A0For example, <except domain=3D"+1212"> would no= t match the URI "tel:+12125551212", because the "domain"= ; value for that URI would be "12125551212".

It seems like (2) is the option that's most likely = to give you what you want. =A0Suggest defining something like a "<e= xcept-tel>" element, so that you could say something like <excep= t-tel prefix=3D"+1212">.

To be clear, the concern here isn't about a policy that combines = two actions in the same rule. =A0The concern is when two rules match the sa= me call, in which case both actions must be applied.

For example suppose you have the following rule set:
RULE 1: Reject all calls from example.com=A0
-- Conditions: <from><ide= ntity><many domain=3D"example.com"/></identity></from>

-- Actions: <accept alt-action=3D"reject"><rate>= 0</rate></accept>
RULE 2: Redirect all calls from alice@example.com
-- Conditions: <from><identity><one id=3D"sip:alice@example.com= "/></identity></from>

-- Actions: <accept alt-action=3D"redirect" alt-target=3D= "sip:eve@ex= ample.com"><rate>0</rate></accept>
=

It doesn't seem like there's a sensible way to combine t= hose rules. =A0In principle, it seems like the simplest thing would be to s= ay that a policy MUST NOT specify two rules that could apply to the same SI= P message. =A0Would people feel comfortable that you could efficiently chec= k this exclusivity? =A0It does scale as the square of the number of rules.<= /div>

[CS] Very good point. We propose an=A0easy &q= uot;the first-match rule", i.e., the call is handled based on the firs= t rule that matches.=A0What do you think?=A0

=A0

That seems pretty sensible. =A0I thin= k the way to state this is add some text to Section 7.4 defining the Combin= ing Rule (to use the phrase from RFC 4745) for the <accept> action.

Thanks,

--Richard

<= /div>

--089e013c66b4abde9804df9de987--