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

[Charles Shen <[e-mail]>]

Hi Richard,

After putting up more thoughts on this as I finalize the revision, I feel
that there are really two options:

Option 1:

<from>
    <many>
        <except prefix="+1-212-854"/>
        <except domain="manhattan.example.com"/>
    </many>
</from>

Option 2:

<from>
    <many>
        <except domain="manhattan.example.com"/>
    </many>
    <many-tel>
        <except-tel prefix="+1-212-854"/>
    </many-tel>
</from>

I also attach below the respective changes to the XML of these two options.
Both will require extended definition of the RFC4745 identity element
(unless we want to call it a different name), option 1 is cleaner in terms
of usage. but requires extended definition of not only the RFC4745
"identity", also RFC4745 "many" and "except", Option 2 requires extended
definition of RFC4745 "identity" but use separate names to extend "many"
and "except". Since "many-tel" is independent of "many", everytime we want
to include group of identities covering both sip and tel uris we have to
specify both "many" and "many-tel". Is there one option that you prefer
over the other?

Thanks!

Charles



OPtion 1: redefinition of identity / many / except

   <!-- SIP ID TYPE -->
   <xs:complexType name="sip-id-type">
     <xs:sequence>
     <element name="from" type="lc:identityType" minOccurs="0"/>
     <element name="to" type="lc:identityType" minOccurs="0"/>
     <element name="request-uri" type="lc:identityType" minOccurs="0"/>
     <element name="p-asserted-identity" type="lc:identityType"
           minOccurs="0"/>
     <any namespace="##other" processContents="lax" minOccurs="0"
           maxOccurs="unbounded"/>
     </xs:sequence>
     <anyAtrribute namespace="##other" processContents="lax"/>
   </xs:complexType>

    <!-- //conditions/identity -->
    <xs:complexType name="identityType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:choice  minOccurs="1" maxOccurs="unbounded">
                    <xs:element name="one" type="cp:oneType"/>
                    <xs:element name="many" type="lc:manyType"/>
                    <xs:any namespace="##other" processContents="lax"/>
                </xs:choice>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>

    <!-- //identity/many -->
    <xs:complexType name="manyType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:choice minOccurs="0" maxOccurs="unbounded">
                    <xs:element name="except" type="lc:exceptType"/>
                    <xs:any namespace="##other"
                    minOccurs="0" processContents="lax"/>
                </xs:choice>
                <xs:attribute name="domain"
                use="optional" type="xs:string"/>
                <xs:attribute name="prefix"
                use="optional" type="xs:string"/>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>

    <!-- //many/except -->
    <xs:complexType name="exceptType">
        <xs:attribute name="domain" type="xs:string" use="optional"/>
        <xs:attribute name="prefix" type="xs:string" use="optional"/>
        <xs:attribute name="id" type="xs:anyURI" use="optional"/>
    </xs:complexType>


OPtion 2: redefinition of identity plus defining additional many-tel /
except-tel

   <!-- SIP ID TYPE -->
   <xs:complexType name="sip-id-type">
     <xs:sequence>
     <element name="from" type="lc:identityType" minOccurs="0"/>
     <element name="to" type="lc:identityType" minOccurs="0"/>
     <element name="request-uri" type="lc:identityType" minOccurs="0"/>
     <element name="p-asserted-identity" type="lc:identityType"
           minOccurs="0"/>
     <any namespace="##other" processContents="lax" minOccurs="0"
           maxOccurs="unbounded"/>
     </xs:sequence>
     <anyAtrribute namespace="##other" processContents="lax"/>
   </xs:complexType>

    <!-- //conditions/identity -->
    <xs:complexType name="identityType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:choice  minOccurs="1" maxOccurs="unbounded">
                    <xs:element name="one" type="cp:oneType"/>
                    <xs:element name="many" type="cp:manyType"/>
                    <xs:element name="many-tel" type="lc:many-telType"/>
                    <xs:any namespace="##other" processContents="lax"/>
                </xs:choice>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>
    <!-- //identity/many-tel -->
    <xs:complexType name="many-telType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:choice minOccurs="0" maxOccurs="unbounded">
                    <xs:element name="exceptTel" type="lc:except-telType"/>
                    <xs:any namespace="##other"
                    minOccurs="0" processContents="lax"/>
                </xs:choice>
                <xs:attribute name="domain"
                use="optional" type="xs:string"/>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>
    <!-- //many/except -->
    <xs:complexType name="except-telType">
        <xs:attribute name="prefix" type="xs:string" use="optional"/>
        <xs:attribute name="id" type="xs:anyURI" use="optional"/>
    </xs:complexType>





On Wed, Jun 26, 2013 at 8:40 AM, Charles Shen <[e-mail]>wrote:

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