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

[Richard Barnes <[e-mail]>]

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