Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08
Charles Shen <charles@cs.columbia.edu> Sun, 14 July 2013 15:28 UTC
Return-Path: <charles.newyork@gmail.com>
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5A221F9E6E for <sip-overload@ietfa.amsl.com>; Sun, 14 Jul 2013 08:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+AcAREPyJZq for <sip-overload@ietfa.amsl.com>; Sun, 14 Jul 2013 08:28:11 -0700 (PDT)
Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id F101521F9C93 for <sip-overload@ietf.org>; Sun, 14 Jul 2013 08:28:10 -0700 (PDT)
Received: by mail-oa0-f41.google.com with SMTP id n10so14994552oag.28 for <sip-overload@ietf.org>; Sun, 14 Jul 2013 08:28:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=z6LHnOxynAnp8R5Zue85k8kL+l6muBzrNm3JtbMjEQY=; b=gXNZG4ZUnP/FjgLyk/eYDeMz4YOOppRhmI1gzvUT8f26SZcuZ9x4R3l2v5WWrm+wmb 5k0Fl3oL0ue7S6mrGKTE4C4Y5kYCLQkCzVPuVCY9cBDlNqE74ICtx8N0SDrOjbe4ZJrC 8uj/5xCtkOGLl30Yds74fm8f+ixJoQY0yKhQwNcdmgPbI5/rGHxWUB348jd+x65bDSKd A9W5K0X1SMZa+FCRK4J9deEmHtLmKugOXGDbgYM+xxiWXqj4O/WF4ihTdGFpikuucFPU ns/Ra0Bt59EWiF9NaLbv/NemB4fwbrxpRBG6Bod9CWyj0fSu8s7VVy7hPXzfm6wksMI1 x0nA==
X-Received: by 10.182.110.226 with SMTP id id2mr40849500obb.95.1373815689465; Sun, 14 Jul 2013 08:28:09 -0700 (PDT)
MIME-Version: 1.0
Sender: charles.newyork@gmail.com
Received: by 10.182.112.131 with HTTP; Sun, 14 Jul 2013 08:27:48 -0700 (PDT)
In-Reply-To: <CAL02cgRCiEqkgh9cmNca6iTXXVu-AsZ5HSpg-8JFZJAZ1PgTFQ@mail.gmail.com>
References: <CAL02cgQW3eJg+f0nwEwihJGRgE82o+B0gSx0LJ6vTP1M8F+n5w@mail.gmail.com> <CAPSQ9ZWuu5fS1jQw6XS4tyPt2ho2pkiCe0FKfboxNv8NrbsNZg@mail.gmail.com> <CAL02cgTD=EwVck90Je4Ou+9Te5aAnFMDMHfNMvBaGOK2EDUNxA@mail.gmail.com> <CAPSQ9ZVLVhepr59KjsjZUFk+C5=xxDuUYHa5CxhBD11Sni=4pQ@mail.gmail.com> <CAL02cgTq+0frn6e63ARm039w9DU8hOz3B==ENr8wjxGNef5kEg@mail.gmail.com> <CAPSQ9ZV2reortRkiR7NYZ=bMhNqkEmEHbbq6DNGnzzhAWi9WSg@mail.gmail.com> <CAL02cgRzwhG0V+M=Uf50hUaTx_pRFGB7XAumhht8Jg3RuiA+FQ@mail.gmail.com> <CAPSQ9ZXeDNPqp3uf2sYwjFy_3p8Z7NK55gBpR=Mw5dcYPNCmOA@mail.gmail.com> <CAPSQ9ZV8ervdD4NP6yTjazPT+-LnaXSX9ZHZstNzS+JJkhC7Nw@mail.gmail.com> <CAL02cgQ5BNyS87MOwLs4LC2emnsfESZ7=KZsJN7xLqpPXkVo4w@mail.gmail.com> <CAPSQ9ZVSqZqCWDf3EZBS_WAp4okpO=QGN3t=UY2JvKtQSRkvWg@mail.gmail.com> <CAL02cgRCiEqkgh9cmNca6iTXXVu-AsZ5HSpg-8JFZJAZ1PgTFQ@mail.gmail.com>
From: Charles Shen <charles@cs.columbia.edu>
Date: Sun, 14 Jul 2013 23:27:48 +0800
X-Google-Sender-Auth: 7AzKk75adrQhBCqVV5Xjmx7_1vc
Message-ID: <CAPSQ9ZWQm-tMxtffkXhjjcwmmTZncyZRMAO8qqeh=k_LWvdEpw@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Content-Type: multipart/alternative; boundary="089e0112ce202859cf04e17a64ab"
Cc: sip-overload@ietf.org, draft-ietf-soc-load-control-event-package@tools.ietf.org
Subject: Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-overload>
List-Post: <mailto:sip-overload@ietf.org>
List-Help: <mailto:sip-overload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Jul 2013 15:28:13 -0000
Great and thank you! On Sun, Jul 14, 2013 at 4:04 AM, Richard Barnes <rlb@ipv.sx> wrote: > 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 <charles@cs.columbia.edu>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 <rlb@ipv.sx> 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 <charles@cs.columbia.edu> >> 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 <charles@cs.columbia.edu> >> wrote: >> >>> >> >>> This makes a lot of sense, fully agree. Thanks! >> >>> >> >>> Charles >> >>> >> >>> >> >>> On Tue, Jun 25, 2013 at 10:52 PM, Richard Barnes <rlb@ipv.sx> wrote: >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> On Sun, Jun 23, 2013 at 12:50 AM, Charles Shen < >> charles@cs.columbia.edu> wrote: >> >>>>> >> >>>>> Hi Richard, please see additional questions regarding "tel" URL >> grouping: >> >>>>> >> >>>>> On Fri, Jun 21, 2013 at 7:00 AM, Richard Barnes <rlb@ipv.sx> wrote: >> >>>>>> >> >>>>>> Inline. Areas of agreement snipped. >> >>>>>> >> >>>>>> >> >>>>>> On Thu, Jun 20, 2013 at 1:40 AM, Charles Shen < >> charles@cs.columbia.edu> 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:+12125551212", >> 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:+12125551212. >> >>>>> >> >>>>> 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 >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>> >> >> >> > >> > >
- [sip-overload] AD review of draft-ietf-soc-load-c… Richard Barnes
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Richard Barnes
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Richard Barnes
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Richard Barnes
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Shida Schubert
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Richard Barnes
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Richard Barnes
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Shida Schubert
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Richard Barnes
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Richard Barnes
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Shida Schubert
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Shida Schubert
- Re: [sip-overload] AD review of draft-ietf-soc-lo… Charles Shen