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

[Charles Shen <[e-mail]>]

Hi Richard,

The reason I think we need to have <many-tel> is that we also want to
allow the situation when we only filter a group of phone numbers with
the same prefix "eg., +1-212-854", similar to filtering a group of sip
ids with the same domain, e.g., "sip.example.com", if we only use
<exclude-tel> we would have to list all available prefixes except that
one, which doesn't seem very plausible. it looks like <many> in
RFC4745 only accepts "domain" attribute, so we need a <many-tel> with
the following schema.

<xs:complexType name="manyTelType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:choice minOccurs="0" maxOccurs="unbounded">
                    <xs:element name="exceptTel" type="lc:exceptTelType"/>
                    <xs:any namespace="##other"
                    minOccurs="0" processContents="lax"/>
                </xs:choice>
                <xs:attribute name="prefix"
                use="optional" type="xs:string"/>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>

Then we can say

<many-tel prefix="+1-212-854"/>

in a way similar to
<many domain="sip.example.com>

Is this something you would agree with?

Thanks!

Charles




On Sat, Jul 13, 2013 at 2:57 AM, Richard Barnes <[e-mail]> wrote:
>
> Keep in mind that you're *extending*, not redefining the RFC 4745 schema here.
>
> Option 1 doesn't work.  The schema for <except> in RFC 4745 doesn't allow for attributes other than "domain".
>
> Option 2 is overkill.  You don't need to define a new <many> element, you can just define a new exception element inside of <many>
>
> Option 3:
>
> <from>
>   <many>
>     <except-tel prefix="+1-212-854"/>
>   </many>
> </from>
>
> Then your extension schema is:
>
> <xs:element name="except-tel" type="exceptTelType"/>
> <xs:complexType name="exceptTelType">
>   <xs:attribute name="prefix" type="xs:string" use="optional"/>
>   <xs:attribute name="id" type="xs:anyURI" use="optional"/>
>   <xs:anyAttribute>
> </xs:complexType>
>
>
>
>
>
>
>
> On Thu, Jul 11, 2013 at 11:21 AM, Charles Shen <[e-mail]> wrote:
>>
>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>