Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08
Richard Barnes <rlb@ipv.sx> Fri, 12 July 2013 18:57 UTC
Return-Path: <rlb@ipv.sx>
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 5D41921F9FF6 for <sip-overload@ietfa.amsl.com>; Fri, 12 Jul 2013 11:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 ENHAqwoWgipw for <sip-overload@ietfa.amsl.com>; Fri, 12 Jul 2013 11:57:02 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 390BC21F9F96 for <sip-overload@ietf.org>; Fri, 12 Jul 2013 11:57:02 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id wo10so11765190obc.31 for <sip-overload@ietf.org>; Fri, 12 Jul 2013 11:57:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ErA2OTL0yH13NkRNtS5bxb7z1UZKdzmv+/B6vvK92Xk=; b=oHOwzoizHhNGLqZP+zWTW9uF0tOTHloES4pgFCHVwdKtWFuUWZqY6PdT5fOrqQO+hC 4p5rWYVbnbv0oTy77j410NN2GPCMFoZKfvd1KeYEv2AE2OuuSnez7XWVrBygyHGe1QEq 35VFUNPhF3NUVUbKLPyCVHC3jbzpgIfO/J18a4yWITocZ/4mSaNA90OZ8JMfmpr9+DzP 7xku4PUctuozOSIZX7WLKTIrUOVbxXzjWoEKJD9dFvAXWTYOBGttOeOFVaxGMORm6e79 ikFvkCf05thDKykTk4oJucBvX91839xWPTrrvSoRW9qRAGuc7n1SCYWgNZQAsc9+9I8i mDHw==
MIME-Version: 1.0
X-Received: by 10.182.165.133 with SMTP id yy5mr37029740obb.89.1373655420679; Fri, 12 Jul 2013 11:57:00 -0700 (PDT)
Received: by 10.60.26.135 with HTTP; Fri, 12 Jul 2013 11:57:00 -0700 (PDT)
X-Originating-IP: [128.89.253.61]
In-Reply-To: <CAPSQ9ZV8ervdD4NP6yTjazPT+-LnaXSX9ZHZstNzS+JJkhC7Nw@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>
Date: Fri, 12 Jul 2013 14:57:00 -0400
Message-ID: <CAL02cgQ5BNyS87MOwLs4LC2emnsfESZ7=KZsJN7xLqpPXkVo4w@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Charles Shen <charles@cs.columbia.edu>
Content-Type: multipart/alternative; boundary="001a11c2e76a64c47904e15513c7"
X-Gm-Message-State: ALoCoQktPivyClU2ghCdY+SKGWrcTdEG7FdpdHw+qvdl1d+OU4RP6t68O+FobcpG8yCdNp4bmrkw
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: Fri, 12 Jul 2013 18:57:08 -0000
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