Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08

[Richard Barnes <[e-mail]>]

On Sun, Jun 23, 2013 at 12:50 AM, Charles Shen <[e-mail]>wrote:

> Hi Richard, please see additional questions regarding "tel" URL grouping:
>
> On Fri, Jun 21, 2013 at 7:00 AM, Richard Barnes <[e-mail]> wrote:
>
>> Inline.  Areas of agreement snipped.
>>
>>
>> On Thu, Jun 20, 2013 at 1:40 AM, Charles Shen <[e-mail]>wrote:
>>
>>> To be clear on this, the ambiguity here is with regard to the <except
>>>> domain="..."> case.  In the <one id="..."> 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.  According to RFC 4745, there must
>>>> be an exact match between the "domain" value provided by the using protocol
>>>> and the value in the "domain" parameter.  I can't think of a way that this
>>>> document could define a way to extract a domain from a telephone number
>>>> that would meet the semantic 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: URI.
>>>> 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 to
>>>> 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.
>>> b. for local numbers (numbers that do not start with +), the
>>> "phone-context" contains the domain value.
>>>
>>
>> Are you sure that gives you the expressiveness you want?  It doesn't
>> allow you to exclude based on an arbitrary prefix.  For example, <except
>> domain="+1212"> would not match the URI "tel:[phone]", 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.  Suggest defining something like a "<except-tel>" element, so that
>> you could say something like <except-tel prefix="+1212">.
>>
>
>  I am absolutely fine adding another element, but just want to make sure I
> indeed understand your concern before doing that.
>
> According to the current texts (paragraph 2, pg.18), when the specified
> domain value starts with a "+" sign, it denotes a number prefix, if its
> "+1-212", the prefix is "1212" (after removing any visual separaters, as
> in the Tel URL comparison rules, this needs to be added explicitly), and
> this prefix is used to match numbers (again after removing any visual
> separaters), therefore, it should match the number "1212551212" in the
> tel URL tel:[phone].
>
> Did I miss something here? thanks!
>
> Charles
>

I think the concern here isn't with the definition, it's with the fact that
you're "re-interpreting" an existing field.  That's bad for
interoperability, since if one of these policies is provided to an
implementation that doesn't know about the reinterpretation, that
implementation with interpret the field incorrectly.  I agree that the risk
of misinterpretation is pretty low here (since it's buried in a
call-identity element), but it's best to be unambiguous.

So I would just augment your existing schema to define a new element with
the same semantic you have described above.

--Richard