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

[Charles Shen <[e-mail]>]

This makes a lot of sense, fully agree. Thanks!

Charles

On Tue, Jun 25, 2013 at 10:52 PM, Richard Barnes <[e-mail]> wrote:

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