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

[Richard Barnes <[e-mail]>]

I see.  That makes sense.  If the WG approves, I would be OK with Option 2.
--Richard


On Sat, Jul 13, 2013 at 1:24 PM, Charles Shen <[e-mail]>wrote:

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