From nobody Wed Mar 1 00:21:39 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3F61294C9 for ; Wed, 1 Mar 2017 00:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CYYvL9dZPwq for ; Wed, 1 Mar 2017 00:21:36 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A6B1294BD for ; Wed, 1 Mar 2017 00:21:36 -0800 (PST) X-AuditID: c1b4fb30-677ff70000001a00-5e-58b6848dafbe Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 75.4A.06656.D8486B85; Wed, 1 Mar 2017 09:21:34 +0100 (CET) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 1 Mar 2017 09:21:33 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dg5WIfUvMWieqoO4gHXZdfNDGfou6ImSUPXTot2JwT4=; b=gOZbqWP70gdv1O8079r7a3z715ojgz9CHw2XMzeaPcVgpNfPRp5vjKvY7jKSLzgnng42IyKRiN0y7h95xizLazDJYeMV/GbX947gBr+lQ/1LtgDzW//3GMdUl6MOJUgWBANn9SpF7KIQpIZOeQ6Ov4+wGEKeqB7Im55dpp4W7/g= Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) by AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Wed, 1 Mar 2017 08:21:32 +0000 Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) by AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) with mapi id 15.01.0947.012; Wed, 1 Mar 2017 08:21:32 +0000 From: Ivo Sedlacek To: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-content-id-00.txt Thread-Index: AQHSe0i3OcxEApvMsUa8nZTAZChHJKFTOfcAgAIsEpCAAIkmgIABR2kAgABbb4CAKD0EgA== Date: Wed, 1 Mar 2017 08:21:32 +0000 Message-ID: References: <148581549631.29908.11634008821807861861.idtracker@ietfa.amsl.com> <63750599-ba34-92f1-9828-f89d5797598f@comcast.net> <60a288a9-ba92-65b0-8462-1929e9cc9923@comcast.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [193.179.210.162] x-ms-office365-filtering-correlation-id: 7b04afe0-0d4a-47d9-2e04-08d4607bf7eb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2468; x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2468; 7:k3F6oclhgjk9bxHfscCSHFYhBAAhzur3zYpLg8U1MFqqXDfQyASbSzt48X/KuAqIJVbuT6GmcFD0S68J/mEUPyWxizE3gzzOeaWUaZENr5T/qm0f1r9r6w9ykSS083Acf6IC1/cmWj2T/xE5Je5NDPDYLQAFn9sxk2uZzt7Nfj5szUl84g1EViZwHrmvGfuGLUjk1ht0KYXEUohpWmE1gmaw5DL+iIqOnFyaB8bCMx819wR+bMDrqDdzNtmRWIBZPJrmidfUCYIe4lfMqvTEGfw6S7zvQ00Gd81SM42zNnIcb6z5jilYBRUA2Q+6D8hEC3X03UJfTLANLxy1eSQHqQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:AM5PR0701MB2468; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2468; x-forefront-prvs: 0233768B38 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(106116001)(53936002)(450100001)(2351001)(122556002)(92566002)(189998001)(2906002)(6916009)(3660700001)(2501003)(86362001)(3846002)(6116002)(230783001)(3280700002)(790700001)(102836003)(6246003)(38730400002)(110136004)(33656002)(236005)(50986999)(93886004)(54356999)(5660300001)(66066001)(7696004)(76176999)(5630700001)(2900100001)(6506006)(6436002)(77096006)(8936002)(606005)(99286003)(2950100002)(6306002)(1730700003)(8676002)(54896002)(7906003)(229853002)(81166006)(9686003)(55016002)(25786008)(5640700003)(7736002)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2468; H:AM5PR0701MB2468.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB24686B27CFE00E14E97D20FAE5290AM5PR0701MB2468_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2017 08:21:32.0599 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2468 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURjHOe9lvlsNjvP2oEKwiryUmZREhBYELUK6YkNCXfmi5nS6qWQ3 DO3iMnOBmct00tCM6QdTW1qm0zBLVIaM8FKJ103MEq9p0bZXwW+//+UcnudwGFKko72ZxJR0 Vpkik4t5AqpE+iZ8T0FuozS4pj3w4MJyHe8Ikuj1K8RpFCU4HMfKEzNZ5d6wWEFCy5NuOlV3 7Gp+cx8vG00fUiM+A3g/zLQukWokYES4FkHxnA05AhHutIvnvo6Awg9JWDJbeFyrlIC6e9nr 4gsC24DWeYSHg0BT30E72B37Q9Vig4uD3fBx0DYNIs6XgPmvheI4EnqmPzh9Cu+AoreVhIOF OBY6iv8Q3BiLBKibzjuYj8Ph9o8p5/0Ie8LSZ4OzQ2IvGBgrJ7h9MOjf9ZIce4B19B/tGBTh Bwh+lVnWS9uh/vHseikCpp518Dg+BSPmCRfHAcAFJJh1BXbB2IUCakqjuM5JsOY9orlOGQET +nmKC3zB1tZLcMEkDSMGG82t7w3D/XmIY1+YGnpPc2MrwLBWThWiXdpNW2g3RVrna7hCV8kY xfm7Qdc8x+M4ECorpskN7m4dJTb7OuTyCnmoWNWl5PiQkCBWmXhZpVKkBKWw6XXI/m/a6leD jcg6edSEMIPEW4WphQ1SES3LVGUlmxAwpNhdmJvWKBUJ42RZ11ilIkaZIWdVJuTDUGIvYWj1 9wsiHC9LZ5NYNpVVbqQEw/fORvVuIpPkZ2ua67llzxN1mgiRX6dl/kVOz0p/obTG/0r5eFdM bcZAjuvLHs3kmdKevtkb/Ls+5p1+0QrjsEvv/Hi+yRKmLJrx26YxSj5KSwJuVg3eN34dOhAh v1V9fa3v6UJkX95ZdUV0wKf2pN+hVL+hpOgOa7R+e726pelieItNTKkSZPsCSKVK9h/XTpcN MwMAAA== Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-content-id-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 08:21:38 -0000 --_000_AM5PR0701MB24686B27CFE00E14E97D20FAE5290AM5PR0701MB2468_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I re-read the comments raised at the sipcore list to draft-ietf-sipcore-con= tent-id-00 and identified: Comment-1) Paul pointed that the draft can be read as the SIP Content-* hea= der fields are mandatory. Response: I attempt to address the comment by added a clari= fication in -01 that the body part formed from a SIP message contains the S= IP header fields, >>if included in header fields of the SIP message<<. Comment-2) Randall indicated that RFC2045 uses "entity" rather than "body p= art". Response: RFC3261 and RFC5621 use body parts. RFC2398 uses = "body part" and "MIME entity" interchangeably. Thus, I would rather stick t= o "body part". Comment-3) Paul suggested to state that the body part is formed from *all* = the SIP header fields (rather than just those identified in section 3.3.) Response: - Paul's suggestion would require that all SIP header field= s are registered by IANA as MIME header fields. - We would need to do so to ensure that none can register e= .g. a MIME "History-Info" header field with syntax or semantic deviating fr= om the SIP "History-Info" header field. - IMO, this makes too much dependency between SIP and MIME = and thus I would prefer to stick to explicitly identified SIP header fields= which form the body part, as in section 3.3. Furthermore, I identified that MIME-Version should be listed as a SIP heade= r field which also forms the body part, and included it in section 3.3. We have created a pull request with the changes: https://github.com/cdh4u/d= raft-content-id/pull/1 We intend to submit a new version of the draft befo= re the Chicago cut-off, so please take a look. Kind regards Ivo --_000_AM5PR0701MB24686B27CFE00E14E97D20FAE5290AM5PR0701MB2468_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I re-read the comments raise= d at the sipcore list to draft-ietf-sipcore-content-id-00 and identified:

 

Comment-1) Paul pointed that= the draft can be read as the SIP Content-* header fields are mandatory.

 

    &nbs= p;           Response: I = attempt to address the comment by added a clarification in -01 that the bod= y part formed from a SIP message contains the SIP header fields, >>if= included in header fields of the SIP message<<.

 

Comment-2) Randall indicated= that RFC2045 uses "entity" rather than "body part".

 

    &nbs= p;           Response: RF= C3261 and RFC5621 use body parts. RFC2398 uses "body part" and &q= uot;MIME entity" interchangeably. Thus, I would rather stick to "= body part".

 

Comment-3) Paul suggested to= state that the body part is formed from *all* the SIP header fields (rathe= r than just those identified in section 3.3.)

 

    &nbs= p;           Response:

    &nbs= p;           - Paul's sug= gestion would require that all SIP header fields are registered by IANA as = MIME header fields.

    &nbs= p;           - We would n= eed to do so to ensure that none can register e.g. a MIME "History-Inf= o" header field with syntax or semantic deviating from the SIP "H= istory-Info" header field.

    &nbs= p;           - IMO, = this makes too much dependency between SIP and MIME and thus I would prefer= to stick to explicitly identified SIP header fields which form the body pa= rt, as in section 3.3.

 

Furthermore, I identified th= at MIME-Version should be listed as a SIP header field which also forms the= body part, and included it in section 3.3.

 

 

We have created a pull reque= st with the changes: https://github= .com/cdh4u/draft-content-id/pull/1  We intend to submit a new vers= ion of the draft before the Chicago cut-off, so please take a look.

 

Kind regards

 

Ivo

--_000_AM5PR0701MB24686B27CFE00E14E97D20FAE5290AM5PR0701MB2468_-- From nobody Thu Mar 2 09:23:37 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4C812957E; Thu, 2 Mar 2017 09:23:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148847541670.19523.17381027323312735165.idtracker@ietfa.amsl.com> Date: Thu, 02 Mar 2017 09:23:36 -0800 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 17:23:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core of the IETF. Title : A SIP Response Code for Unwanted Calls Author : Henning Schulzrinne Filename : draft-ietf-sipcore-status-unwanted-04.txt Pages : 8 Date : 2017-03-02 Abstract: This document defines the 666 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-status-unwanted-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 3 15:59:06 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 258EE129676; Fri, 3 Mar 2017 15:55:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858532915.15846.12304433447469189053.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:29 -0800 Archived-At: Cc: ben@nostrum.com, sipcore@ietf.org Subject: [sipcore] sipcore - Requested session has been scheduled for IETF 98 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:29 -0000 Dear Adam Roach, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sipcore Session 1 (2:00:00) Thursday, Afternoon Session II 1520-1720 Room Name: Montreux 3 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Session Initiation Protocol Core Area Name: Applications and Real-Time Area Session Requester: Adam Roach Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: netvc xrblock webpush stir mmusic rtcweb avtext perc avtcore dispatch ice sipbrandy People who must be present: Adam Roach Ben Campbell Jean Mahoney Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Mar 6 15:30:54 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82BD129545 for ; Mon, 6 Mar 2017 15:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuMNkZYIGCIl for ; Mon, 6 Mar 2017 15:30:41 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E08129539 for ; Mon, 6 Mar 2017 15:30:41 -0800 (PST) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v26NUeDE048307 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 6 Mar 2017 17:30:41 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: "'SIPCORE'" From: Adam Roach Message-ID: Date: Mon, 6 Mar 2017 17:30:35 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] WGLC: draft-ietf-sipcore-name-addr-guidance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 23:30:44 -0000 [as chair] We've spoken to the author of draft-ietf-sipcore-name-addr-guidance about its current state, and he indicated that he believes the document to be complete, with no open issues. Given its relative simplicity and the fact that it is addressing a real-world problem being encountered in the field, we would like to get the publication ball rolling. Today, we start a two-week working group last call for the document, ending Monday, March 20th. Please direct comments to the SIPCORE WG mailing list. Thanks! /a From nobody Tue Mar 7 12:47:49 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D95129576; Tue, 7 Mar 2017 12:47:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148891966899.17640.11013846875357780343@ietfa.amsl.com> Date: Tue, 07 Mar 2017 12:47:49 -0800 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 20:47:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core of the IETF. Title : SIP Call-Info Parameters for Labeling Calls Author : Henning Schulzrinne Filename : draft-ietf-sipcore-callinfo-spam-00.txt Pages : 9 Date : 2017-03-07 Abstract: Called parties often wish to decide whether to accept, reject or redirect calls based on the likely nature of the call. For example, they may want to reject unwanted telemarketing or fraudulent calls, but accept emergency alerts from numbers not in their address book. This document describes SIP Call-Info parameters and a feature tag that allow originating, intermediate and terminating SIP entities to label calls as to their type, spam probability and references to additional information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sipcore-callinfo-spam-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 7 12:57:38 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42DB129428 for ; Tue, 7 Mar 2017 12:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.519 X-Spam-Level: X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57DzkV10M_2N for ; Tue, 7 Mar 2017 12:57:36 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9CF1293F5 for ; Tue, 7 Mar 2017 12:57:35 -0800 (PST) Received: from pps.filterd (m0102171.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v27KmqBH002649 for ; Tue, 7 Mar 2017 20:57:33 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0051.outbound.protection.outlook.com [23.103.198.51]) by mx0b-0024ed01.pphosted.com with ESMTP id 28ytde2rch-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 07 Mar 2017 20:57:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=m1IdFZL89fN0bNwO8Zl1FTieMOkfYwlerqG9xRJlIzI=; b=HKeNTswiXCj36pcYt0iPcv17DcwLGy9hRMaPd5XEO8WDMZ2FifWu5J+Jz7qvWmwXCi6KEKqKJn7N3YggoSmaSS2pgD4MqfvRSTOZUZfc15PxyBoEvVkLs3QJE8ZspmR17n9MBMC8kehhWkY7ay802StcTFe/tNB7i5CQ3oWb360= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 7 Mar 2017 20:57:31 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0947.020; Tue, 7 Mar 2017 20:57:31 +0000 From: Henning Schulzrinne To: SIPCORE Thread-Topic: Callinfo draft submitted Thread-Index: AdKXhNCz16so7NmERPyS+mIJaUSWSQ== Date: Tue, 7 Mar 2017 20:57:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: fd5f713f-0249-4852-1c9e-08d4659c9292 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0634; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 7:0+wnCZZUI6xKKs1QYFa4XONTIztWoa283oc4/hL95Stc8dqjeMNRSu+k5ie2qKLc80oQzHQc7Glqt6JJCAxFLP/cjmrID2V9GQFzIeXil5nkHDinZQdlTweM242rzLAAw7dawrLBRzHcvRhmHIXhKM/30h9R81qtn5tc3dy35yFVggXVa9+IZtaw+onZVWmSrlCATZbfyHrlNa/vYB7QVTMyrDQ0yrQkoNN727B3QlEG9+ZcqDtSxMkwGpv89suMhNY9O+Z4QafnwlihmUYHinbhXn0TOu80zYVGe2QAOpvjdBT2AkhgPiZIvmAHQbOJX3P5dWcje1S7ZtI68t8emA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123558025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39450400003)(3660700001)(19609705001)(66066001)(8676002)(3280700002)(6916009)(189998001)(3480700004)(33656002)(81166006)(6306002)(7696004)(2906002)(122556002)(2900100001)(8936002)(86362001)(54896002)(3846002)(102836003)(77096006)(6436002)(54356999)(6506006)(50986999)(6116002)(25786008)(790700001)(9686003)(7736002)(74316002)(38730400002)(7116003)(99286003)(55016002)(110136004)(5660300001)(53936002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634B55E8BEF8E20D6A593C8EA2F0CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2017 20:57:31.3341 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-07_16:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [sipcore] Callinfo draft submitted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 20:57:37 -0000 --_000_CY1PR09MB0634B55E8BEF8E20D6A593C8EA2F0CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have submitted the draft draft-ietf-sipcore-callinfo-spam-00, which has b= een re-organized compared to draft-schulzrinne-dispatch-callinfo-spam-00, b= ased on earlier comments. Differences are at https://www.ietf.org/rfcdiff?url1=3Ddraft-schulzrinne-dispatch-callinfo-spa= m-00&url2=3Ddraft-ietf-sipcore-callinfo-spam-00 Additional comments are appreciated. Henning --_000_CY1PR09MB0634B55E8BEF8E20D6A593C8EA2F0CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have submitted the draft draft-ietf-sipcore-callin= fo-spam-00, which has been re-organized compared to draft-schulzrinne-dispa= tch-callinfo-spam-00, based on earlier comments.

 

Differences are at

https://www.ietf.org/rfcdiff?url1=3Ddraft-schulzrinn= e-dispatch-callinfo-spam-00&url2=3Ddraft-ietf-sipcore-callinfo-spam-00<= o:p>

 

Additional comments are appreciated.

 

Henning

--_000_CY1PR09MB0634B55E8BEF8E20D6A593C8EA2F0CY1PR09MB0634namp_-- From nobody Tue Mar 7 15:42:41 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3851D129444 for ; Tue, 7 Mar 2017 15:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em5BBWFn0ROY for ; Tue, 7 Mar 2017 15:42:36 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1067C126BF7 for ; Tue, 7 Mar 2017 15:42:35 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v27NgYBS000628 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 7 Mar 2017 17:42:34 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: draft-ietf-sipcore-status-unwanted-04.all@ietf.org, SIPCORE Date: Tue, 07 Mar 2017 17:42:32 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: [sipcore] AD Evaluation of draft-ietf-sipcore-status-unwanted-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 23:42:39 -0000 Hi, This is my AD evaluation of draft-ietf-sipcore-status-unwanted-04. I have a few substantive and and some editorial comments. I don't think any of these need block the IETF last call, which I will request shortly. These can be resolved along with any IETF LC comments. Thanks! Ben. ----------------- - Substantive Comments: -- section 4, first paragraph: I'm struggling to understand what a sending a 666 when canceling a branch of a forked call would mean. Are we talking about a scenario where a forking proxy notes that one device responds with a 666, then the proxy sends that to the other branches? If so, some elaboration of the use case might be helpful. -- Section 4, paragraph 3: There's some imprecision in whether explicit user action is expected when deciding to send a 666. I think the intent is that explicit user action (e.g. a spam button) is just one of multiple ways a called UA could decide to do so. But the last sentence of the paragraph seems to indicate an expectation for explicit UI action, in spite of the earlier sentences that allowed otherwise. It's not clear to me if those previous sentences describe when to _send_ a 666, or just what one might do when receiving one. -6, 3rd paragraph from end: How can one reasonably know that an identity has been reassigned? I can see the case where the callee's service provider is the same as the caller's service provider, but that's a degenerate case. Are we expecting the calling SP to inform the callee SP out of band, and the callee SP to believe them? Given how poorly that seems to work in the context of email, I wonder if there's any useful advice to give here. - Editorial Comments: -- There's some general imprecision in the use of "UAC" and "UAS". I think the intent is to speak of the UAC and UAS in the context of the dialog-initiating transaction (at least when a dialog is involved), but it ends up with language of the form of "... when the UAS sends a BYE request...". Perhaps terms like "caller UA" and "callee UA" would be more clear? (Not that I particularly those, when caller and callee or called vary by a single letter.) -- section 1, first paragraph, sentence starting with "This document addresses only the last mode..." The sentence is convoluted. Can it be broken into a few simpler sentences? -- 4, 2nd paragraph: Please avoid 2119 keywords (in this case MAY), in a non-exhaustive list of examples, as it implies that additional MAYs exist but are not explicitly mentioned. Consider something along the lines of "...MAY perform some action based on local policy, for example, add the party to a local blacklist, ..." --4, 4th paragraph: I'm not sure I believe the sentence starting with "In other words" paraphrases any previous words :-) --6: 2nd to last paragraph: A citation for call transfer might be nice. (Maybe the call flows RFC?) From nobody Tue Mar 7 16:23:13 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA4D129528; Tue, 7 Mar 2017 16:23:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> Date: Tue, 07 Mar 2017 16:23:06 -0800 Archived-At: Cc: draft-ietf-sipcore-status-unwanted@ietf.org, ben@nostrum.com, sipcore@ietf.org, sipcore-chairs@ietf.org Subject: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 00:23:06 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'A SIP Response Code for Unwanted Calls' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-03-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the 666 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Mar 7 20:03:00 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7596A12946D for ; Tue, 7 Mar 2017 20:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04jCF7lXXBmd for ; Tue, 7 Mar 2017 20:02:57 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FDDB124281 for ; Tue, 7 Mar 2017 20:02:57 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-08v.sys.comcast.net with SMTP id lSoRcmIquy4bMlSoScUobW; Wed, 08 Mar 2017 04:02:56 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-18v.sys.comcast.net with SMTP id lSoQcC8vdpxUzlSoRcs4QE; Wed, 08 Mar 2017 04:02:55 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2842sBJ031223; Tue, 7 Mar 2017 23:02:54 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2842rlC031217; Tue, 7 Mar 2017 23:02:53 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Adam Roach In-Reply-To: (adam@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 07 Mar 2017 23:02:53 -0500 Message-ID: <87varkbeky.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfHgkXCZq5jQF7Dvlpd3VcUzlBqecB36lZ4/a5UaHTiOq4Rs4quoYowZATxETC+TPjKlQMK/5JWDkuf1IEYehoTJRIJl8plpsCAhn3g5NDoPi7eY7FDzY ELjXLdnykwXT8c1e+D7MeIyYA9QThKAifJ7jtBP7fkClkg4h25yP4Ou7MCfloka95Aw0up+B+PwISg== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-name-addr-guidance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 04:02:58 -0000 Of course, I favor approval of draft-ietf-sipcore-name-addr-guidance. I do think there are some nits that need to be resolved. Though since I haven't been following this draft closely, these points may already have been discussed. Dale ---------------------------------------------------------------------- Abstract It also updates those extension SIP header fields that use the alternative to clarify that the constraint applies (RFCs 3325, 3515, 3892, 4508, 5002, 5318, 5360, and 5502). This isn't parallel to the 1st sentence of the paragraph, where the object of "updates" is "RFC3261". Perhaps It also updates the RFCs (3325, 3515, 3892, 4508, 5002, 5318, 5360, and 5502) that define the extension SIP header fields that use the alternative to clarify that the constraint applies. 1. Introduction It is important to note that a message formed without honoring the constraint will still be syntactically valid, but would be interpreted differently. This is a subtle point... If the <...> is omitted, the header will necessarily still be syntactically valid according to the BNF, reading the original URI as an addr-spec -- the BNF is ambiguous in that way. What *might* happen is that the header becomes parsable according to the BNF in a different way also, one that parses the URI as multiple elements. E.g., From: sip:10.0.0.1,sip:x@10.0.0.0 can be either parsed as one URI with user "10.0.0.1,sip" and password "x", or two URIs, one "sip"10.0.0.1" and one "sip:x@10.0.0.0. OTOH, From: sip:10.0.0.1,@10.0.0.0 can only be parsed with the BNF as a single URI, because "@10.0.0.0" doesn't parse as a URI. So it's more accurate to say It is important to note that a header formed without honoring the constraint will still be syntactically valid, but might be syntactically ambiguous and interpreted differently than it was formed. 4. IANA Considerations This memo has no considerations for IANA. Shouldn't the new RFC be listed in the IANA table of SIP header fields (http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2) as a reference for these header fields: P-Asserted-Identity P-Preferred-Identity P-Profile-Key P-Refused-URI-List P-Served-User Permission-Missing Refer-To Referred-By Reply-To And while we're at it, shouldn't RFC 4508 be a reference for Refer-To? (Perhaps I'm not understanding how the "Reference" column of that table is to be used.) 5. Security Considerations One pre-existing consideration is worth reiterating: messages produced without honoring the constraint will be mis- interpreted by the receiving element. This should say "may be mis-interpreted", as discussed in the item for section 1. [END] From nobody Wed Mar 8 03:28:10 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFB4129479; Wed, 8 Mar 2017 03:28:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148897248810.20183.9623466917751703005@ietfa.amsl.com> Date: Wed, 08 Mar 2017 03:28:08 -0800 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-content-id-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 11:28:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core of the IETF. Title : Content ID header field in Session Initiation Protocol (SIP) Authors : Christer Holmberg Ivo Sedlacek Filename : draft-ietf-sipcore-content-id-01.txt Pages : 8 Date : 2017-03-08 Abstract: This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-content-id/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sipcore-content-id-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-content-id-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 8 03:33:46 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68E5129456 for ; Wed, 8 Mar 2017 03:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVxnkWIkIEKP for ; Wed, 8 Mar 2017 03:33:43 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B62B129421 for ; Wed, 8 Mar 2017 03:33:43 -0800 (PST) X-AuditID: c1b4fb30-84e7298000007a5b-d7-58bfec157c58 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id E6.F2.31323.51CEFB85; Wed, 8 Mar 2017 12:33:41 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0319.002; Wed, 8 Mar 2017 12:33:31 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Draft new version: draft-ietf-sipcore-content-id-01 Thread-Index: AQHSl//PCDd6Ar/9BUi+VASH0BRsXA== Date: Wed, 8 Mar 2017 11:33:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D4E5B95318FEBchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7oq7om/0RBps7FC1OvTrNbPH1xyY2 ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvjzdZdjAWneSsW/3vJ2sB4jLuLkZNDQsBE 4tiHRtYuRi4OIYF1jBLLnm5mgXAWMUrsmDifsYuRg4NNwEKi+582SIOIgKbE8m9b2UFsZgEj iQX3PjCB2MICNhIfZ95ihahxlOjsaGGBsPUk9r2ZwgxiswioSHze0QfWyytgLXFu2mmwekYB MYnvp9YwQcwUl7j1ZD4TxHECEkv2nGeGsEUlXj7+B1YvCjRz+fM1zCCnSQgoSUzbmgZiMgsk SJzckwkxXVDi5MwnLBMYhWchGToLoWoWkiqIEgOJ9+fmM0PY2hLLFr6GsvUlNn45ywjRai1x 9K8kspIFjByrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQLj6eCW3wY7GF8+dzzEKMDBqMTD a8C8P0KINbGsuDL3EKMEB7OSCK/uE6AQb0piZVVqUX58UWlOavEhRmkOFiVxXrOV98OFBNIT S1KzU1MLUotgskwcnFINjN2JkyVOrmZtfMFx1X31tcUM5w0F5K6omtvp/hGet3Pe6ls/Yv96 ib7+6lsw7a5R3b6CuRaXa7Ybxc1N7DaVfzD9nI31Py0dg/4I68jtrnNU5Fd/m78x71x7m3i0 9jQmd8d5uy3C3i/+eOGWsp/qhbAPGbcFGH3YskV9WQ6cDXUSe3ve6vFvYyWW4oxEQy3mouJE AIOqvk+jAgAA Archived-At: Cc: SIPCORE Chairs Subject: [sipcore] Draft new version: draft-ietf-sipcore-content-id-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 11:33:45 -0000 --_000_D4E5B95318FEBchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Based on the list discussions, we=92ve submitted a new version (-01) of dra= ft-ietf-sipcore-content-id. The changes are based on the pull request provi= ded earlier. The authors are not aware of any open issues. The authors think the draft i= s ready for WGLC, so we encourage people to take a look, to see whether the= re is still something that needs to be addressed before that. Thanks! Regards, Christer --_000_D4E5B95318FEBchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Based on the list discussions, we=92ve submitted a new version (-01) o= f draft-ietf-sipcore-content-id. The changes are based on the pull request = provided earlier.

The authors are not aware of any open issues. The authors think the dr= aft is ready for WGLC, so we encourage people to take a look, to see whethe= r there is still something that needs to be addressed before that.

Thanks!

Regards,

Christer
--_000_D4E5B95318FEBchristerholmbergericssoncom_-- From nobody Thu Mar 9 06:03:41 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CB3129631 for ; Thu, 9 Mar 2017 06:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKMYWt4JBkSI for ; Thu, 9 Mar 2017 06:03:39 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7AF129630 for ; Thu, 9 Mar 2017 06:03:38 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id u30so81330760uau.0 for ; Thu, 09 Mar 2017 06:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=fW16p8ipHMprbsP+CPvJHhVTVMD1olLI2ugu44t7/PM=; b=uVOutQ9QFiKIhxFp3LIYfMP5vlx2M5EpWwH9fMLpFfXsvs39iZGlUMtoFzLUaZgWbh LWtNPrSXEcrvrC3S9cyTGf0JtRHiNbolqXI1WSvfukL+hL3c0Aapp//E43PhbwCIrs9o w7HonPAN+xB6lesQAl+EzELOtB12LRVmywRLhb0TSZnoYBy6VyRv6RMuKQKNstnFf2D7 nKxcOQkCrA48JRHUHBzSWHN6rg/N/uSPARLjYjXfgZb2PHK0YCMA4lznmdUKLR+NQib6 XxD9OhCqlXlllMTnINgE3RfiXqtpsDY5qSQUxwMPLETID7Gvhm3BJDmvJ+XJetFYveYJ HsWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fW16p8ipHMprbsP+CPvJHhVTVMD1olLI2ugu44t7/PM=; b=rEIGK9n6lnec9DiMY3r/NNEU7Ppa+d+91K4SmRpnUgo/sXwd/XwSrwrJJqfb/d1bwP +AOVPzA1aZEGwRySgrkPc7UAhW+Vp2HW/VyL61MRVgaqy3u+XKnNUXHJSNhtS65mWg7w 635F5anatlmSW9a0wR58vcPwS3FTKcNhAgYpVpmaWI2jTmkrQV3qVk5+Ucddq+rbCevd VUgI+4RK7Swqa2MARGeZhwaxbQaN1qfVM/Sr7Dp3+oGl/p3WsWeaBsIdDy3s8E2XmvWm bd5toaE4ehyUL+pKJT3etbFJrxNcOxXr7QSpitTNeBIGhnpkXruSF0EbQHBYyDd6YQRp N12g== X-Gm-Message-State: AMke39kKETNvft++5JWNNuGWcbhiJ1D6V3tz42H8idLW6+h7WuVosCf1nfrWPAjHzravC8RrjcOM1FtAsKdBaQ== X-Received: by 10.176.16.23 with SMTP id f23mr7238217uab.99.1489068217825; Thu, 09 Mar 2017 06:03:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.146 with HTTP; Thu, 9 Mar 2017 06:03:37 -0800 (PST) From: Rifaat Shekh-Yusef Date: Thu, 9 Mar 2017 09:03:37 -0500 Message-ID: To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=f403045e1d642b7dac054a4cb688 Archived-At: Subject: [sipcore] SIP Digest - Open Issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 14:03:40 -0000 --f403045e1d642b7dac054a4cb688 Content-Type: text/plain; charset=UTF-8 Hi, There is an open issue around the Digest draft and I would like to get some thoughts from the WG about it: https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ The issue is related to section 2.5 Forking: Is this a real use case? if so, the current text calls for the proxy to aggregate the responses and for the UAC to respond to the the ones it support; is this a reasonable approach? Appreciate any thoughts about this. Regards, Rifaat --f403045e1d642b7dac054a4cb688 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

There is an open issue around the D= igest draft and I would like to get some thoughts from the WG about it:

The issue= is related to section 2.5 Forking:
Is this a real use case? if s= o, the current text calls for the proxy to aggregate the responses and for = the UAC to respond to the the ones it support; is this a reasonable approac= h?

Appreciate any thoughts about this.

Regards,
=C2=A0Rifaat

<= /div> --f403045e1d642b7dac054a4cb688-- From nobody Thu Mar 9 11:42:42 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD60412944C for ; Thu, 9 Mar 2017 11:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykv8vzF18pjH for ; Thu, 9 Mar 2017 11:42:39 -0800 (PST) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [63.128.21.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042BF1293DA for ; Thu, 9 Mar 2017 11:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GjXjICF/LaAICHeU+D4ebpsiCLUx31aL/4d1zwEV4Yo=; b=gVQIHhX2ydMtMhGwwscRwnoxUSZjqbzdYJ4jcGEphzI/8RCAsyHu9QcVVDK5zNnynm1oKnukcCCxHcrpA2c2MyNj1n2XJfS11GaoXWafvpeIh8YLbezLklvbQwrWNEKcLKPR3jPRvsOxWHLUkuOQdkBf0O7wl+Uv2w4Ous+LvYg= Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp0017.outbound.protection.outlook.com [216.32.181.17]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-66-CBhZTdXGMFCgusJToguESw-1; Thu, 09 Mar 2017 14:42:35 -0500 Received: from CO2PR03MB2342.namprd03.prod.outlook.com (10.166.93.14) by CO2PR03MB2344.namprd03.prod.outlook.com (10.166.93.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 9 Mar 2017 19:42:32 +0000 Received: from CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) by CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) with mapi id 15.01.0947.020; Thu, 9 Mar 2017 19:42:32 +0000 From: "Asveren, Tolga" To: Rifaat Shekh-Yusef , "sipcore@ietf.org" Thread-Topic: [sipcore] SIP Digest - Open Issue Thread-Index: AQHSmN368yki92IL2E2DEljx8rtZdKGM5B3w Date: Thu, 9 Mar 2017 19:42:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 9860bfed-a3e6-4ac9-8866-08d467246de1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR03MB2344; x-microsoft-exchange-diagnostics: 1; CO2PR03MB2344; 7:OnjjxehI2Xld7xKwjd0XsyDQQzjMlIukXRO2qDepA5E26Qbm8NumJxkATFFoyzc0x2NjLVpvKIVdLivuXEAOdEUnuaJZry4rRYUD+R8/65wxgoUIUC1u2b6nTSgxWqRKYMgvxfjMpHFkjBx8fIHn6b72pIhDDFQffQH88RGLKDRfEXtBHRLAyWALu98F9bqTQWLwdeyCfRPFdicQ2n5wpMfw8W/d5d39hCQ15nxL4seHnT8wrjm/4NFIaRvCvx3o2/dXn1Sl8YxO83A4BuyOOwcGjM5AfOHRsPIIw47U8CsSvjvB86JaNRgAsfBuE+409cWF3KjHPPdZft8UTz+G9Q==; 20:+zvHILK3yBp7EEFgGwxnyTFbfWw0X/eRSo283kwj+JrZEZU6cKwvO/71nMjrrnHj8gYj57azkQU48UFpf3kft2660OglyHexHzMzbk+I0VI9Xp51hLNd6SWWDsMNYhdp91HwE1KHZCP/2AsGvqPzWkpeRsBoYC6qlGtOUQ7E8Zk= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(20161123558025)(6072148); SRVR:CO2PR03MB2344; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2344; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(18543002)(377454003)(122556002)(38730400002)(25786008)(39060400002)(606005)(54356999)(86362001)(53546006)(2900100001)(3280700002)(99286003)(102836003)(106116001)(3846002)(6116002)(6246003)(2501003)(66066001)(2906002)(33656002)(3660700001)(790700001)(6306002)(77096006)(81166006)(229853002)(236005)(55016002)(53936002)(9686003)(50986999)(54896002)(76176999)(6436002)(7906003)(2950100002)(8676002)(7696004)(5660300001)(7736002)(8936002)(6506006)(19609705001)(189998001)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR03MB2344; H:CO2PR03MB2342.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 19:42:32.2300 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2344 X-MC-Unique: CBhZTdXGMFCgusJToguESw-1 Content-Type: multipart/alternative; boundary="_000_CO2PR03MB234275628ACD940D566E0103B2210CO2PR03MB2342namp_" Archived-At: Subject: Re: [sipcore] SIP Digest - Open Issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:42:41 -0000 --_000_CO2PR03MB234275628ACD940D566E0103B2210CO2PR03MB2342namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 aS0gSSB0aGluayBpdCBuZWVkcyB0byBiZSBoYW5kbGVkLiBJdCBtYXkgaGF2ZSBhIGNvaG9ydCBv ZiBhbnRpLWZhbnMgYnV0IGZvcmtpbmcgaXMgcGFydCBvZiBSRkMzMjYxIGFuZCBzaG91bGQgYmUg Y292ZXJlZCBmb3IgYW55IHNjZW5hcmlvL25ldyBtZWNoYW5pc20uDQoNCmlpLSBJIGFtIG5vdCBz dXJlIHdoZXRoZXIg4oCcVUFDIHJlc3BvbmRzIHdpdGggdGhlIG9uZXMgaXQgc3VwcG9ydHPigJ0g aXMgdGhlIHJpZ2h0IGFwcHJvYWNoLiBOZXcvdXBkYXRlZCBpbXBsZW1lbnRhdGlvbnMgbWF5IGZv bGxvdyB0aGF0IGFkdmljZSBidXQgd2hhdCBhYm91dCBleGlzdGluZyBVQUNzPyBJIHRoaW5rIHRo ZXJlIG1heSBiZSBhIG5lZWQgdG8gZGVmaW5lIGEgbmV3IG9wdGlvbi10YWcgaW5kaWNhdGluZyBz dXBwb3J0IGZvciBTSEEqLiBJZiB0aGF0IGlzIG5vdCBwcmVzZW50LCBvbmx5IE1ENSBzaG91bGQg YmUgdXNlZC4gQW5kIGFjdHVhbGx5IHRoaXMgY29tbWVudCBpcyBhcHBsaWNhYmxlIGZvciBhbnkg c2NlbmFyaW8sIG5vdCBqdXN0IGZvciBmb3JraW5nLiBGb3IgZm9ya2luZywgYWdncmVnYXRpb24g c2hvdWxkIGNvbnNpZGVyIHRoZSBvcHRpb24tdGFnLg0KDQppaWktIFVBQyBzdXBwb3J0aW5nIFNI QSogYW5kIHJlY2VpdmluZyBjaGFsbGVuZ2VzIGZvciBib3RoIE1ENS9TSEEqIHNob3VsZCByZXBs eSBmb3IgYm90aCBvZiB0aGVtLiBBdXRob3JpemF0aW9uIGhlYWRlcnMgc2hvdWxkIGJlIG9yZGVy ZWQgYmFzZWQgb24gdGhlIG9yZGVyIG9mIHJlY2VpdmVkIFdXVy9Qcm94eS1BdXRoZW50aWNhdGUg aGVhZGVyIGlmIGNoYWxsZW5nZXMgZm9yIGJvdGggTUQ1L1NIQSogYXJlIHJlY2VpdmVkIGZvciB0 aGUgc2FtZSByZWFsbS4gVGhpcyB3b3VsZCBiZSBuZWVkZWQgaWYgZm9ya2luZyBoYXBwZW5zIGFu ZCBvbmUgb2YgdGhlIGZvcmtlZCBjaGFsbGVuZ2VycyBzdXBwb3J0IG9ubHkgTUQ1LiBGb3JraW5n IHByb3h5IHNob3VsZCBzZW5kIG9ubHkgTUQ1IEF1dGhvcml6YXRpb24gaGVhZGVyIHRvIHN1Y2gg YW4gZW50aXR5Lg0KaXYtIEluIGdlbmVyYWwsIEkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhIG5l ZWQgdG8gcmVwZWF0IOKAnFVwZGF0ZXMgdG8gSFRUUOKAnSBldGPigKYsIHdoaWNoIGFyZSBhbHJl YWR5IHByZXNlbnQgaW4gUkZDMzI2MS4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogc2lwY29y ZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpZmFhdCBT aGVraC1ZdXNlZg0KU2VudDogVGh1cnNkYXksIE1hcmNoIDksIDIwMTcgOTowNCBBTQ0KVG86IHNp cGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFtzaXBjb3JlXSBTSVAgRGlnZXN0IC0gT3BlbiBJc3N1 ZQ0KDQpIaSwNCg0KVGhlcmUgaXMgYW4gb3BlbiBpc3N1ZSBhcm91bmQgdGhlIERpZ2VzdCBkcmFm dCBhbmQgSSB3b3VsZCBsaWtlIHRvIGdldCBzb21lIHRob3VnaHRzIGZyb20gdGhlIFdHIGFib3V0 IGl0Og0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteXVzZWYtc2lwY29y ZS1kaWdlc3Qtc2NoZW1lLw0KDQpUaGUgaXNzdWUgaXMgcmVsYXRlZCB0byBzZWN0aW9uIDIuNSBG b3JraW5nOg0KSXMgdGhpcyBhIHJlYWwgdXNlIGNhc2U/IGlmIHNvLCB0aGUgY3VycmVudCB0ZXh0 IGNhbGxzIGZvciB0aGUgcHJveHkgdG8gYWdncmVnYXRlIHRoZSByZXNwb25zZXMgYW5kIGZvciB0 aGUgVUFDIHRvIHJlc3BvbmQgdG8gdGhlIHRoZSBvbmVzIGl0IHN1cHBvcnQ7IGlzIHRoaXMgYSBy ZWFzb25hYmxlIGFwcHJvYWNoPw0KDQpBcHByZWNpYXRlIGFueSB0aG91Z2h0cyBhYm91dCB0aGlz Lg0KDQpSZWdhcmRzLA0KIFJpZmFhdA0KDQo= --_000_CO2PR03MB234275628ACD940D566E0103B2210CO2PR03MB2342namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2NzgxMjAwMTk7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzA3ODM5MDIgMjEwNjA4Mjg5MCA2NzY5ODcx MyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6JTEtOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDouNzVpbjsN Cgl0ZXh0LWluZGVudDotLjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5pLSBJIHRoaW5rIGl0IG5lZWRzIHRvIGJlIGhhbmRsZWQuIEl0IG1heSBoYXZlIGEgY29ob3J0 IG9mIGFudGktZmFucyBidXQgZm9ya2luZyBpcyBwYXJ0IG9mIFJGQzMyNjEgYW5kIHNob3VsZCBi ZSBjb3ZlcmVkIGZvciBhbnkgc2NlbmFyaW8vbmV3IG1lY2hhbmlzbS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ aWktIEkgYW0gbm90IHN1cmUgd2hldGhlciDigJxVQUMgcmVzcG9uZHMgd2l0aCB0aGUgb25lcyBp dCBzdXBwb3J0c+KAnSBpcyB0aGUgcmlnaHQgYXBwcm9hY2guIE5ldy91cGRhdGVkIGltcGxlbWVu dGF0aW9ucyBtYXkgZm9sbG93IHRoYXQgYWR2aWNlIGJ1dCB3aGF0IGFib3V0IGV4aXN0aW5nIFVB Q3M/IEkNCiB0aGluayB0aGVyZSBtYXkgYmUgYSBuZWVkIHRvIGRlZmluZSBhIG5ldyBvcHRpb24t dGFnIGluZGljYXRpbmcgc3VwcG9ydCBmb3IgU0hBKi4gSWYgdGhhdCBpcyBub3QgcHJlc2VudCwg b25seSBNRDUgc2hvdWxkIGJlIHVzZWQuIEFuZCBhY3R1YWxseSB0aGlzIGNvbW1lbnQgaXMgYXBw bGljYWJsZSBmb3IgYW55IHNjZW5hcmlvLCBub3QganVzdCBmb3IgZm9ya2luZy4gRm9yIGZvcmtp bmcsIGFnZ3JlZ2F0aW9uIHNob3VsZCBjb25zaWRlciB0aGUNCiBvcHRpb24tdGFnLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5paWktIFVBQyBzdXBwb3J0aW5nIFNIQSogYW5kIHJlY2VpdmluZyBjaGFsbGVuZ2Vz IGZvciBib3RoIE1ENS9TSEEqIHNob3VsZCByZXBseSBmb3IgYm90aCBvZiB0aGVtLiBBdXRob3Jp emF0aW9uIGhlYWRlcnMgc2hvdWxkIGJlIG9yZGVyZWQgYmFzZWQgb24gdGhlIG9yZGVyIG9mIHJl Y2VpdmVkIFdXVy9Qcm94eS1BdXRoZW50aWNhdGUNCiBoZWFkZXIgaWYgY2hhbGxlbmdlcyBmb3Ig Ym90aCBNRDUvU0hBKiBhcmUgcmVjZWl2ZWQgZm9yIHRoZSBzYW1lIHJlYWxtLiBUaGlzIHdvdWxk IGJlIG5lZWRlZCBpZiBmb3JraW5nIGhhcHBlbnMgYW5kIG9uZSBvZiB0aGUgZm9ya2VkIGNoYWxs ZW5nZXJzIHN1cHBvcnQgb25seSBNRDUuIEZvcmtpbmcgcHJveHkgc2hvdWxkIHNlbmQgb25seSBN RDUgQXV0aG9yaXphdGlvbiBoZWFkZXIgdG8gc3VjaCBhbiBlbnRpdHkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPml2LSBJ biBnZW5lcmFsLCBJIGRvbuKAmXQgdGhpbmsgdGhlcmUgaXMgYSBuZWVkIHRvIHJlcGVhdCDigJxV cGRhdGVzIHRvIEhUVFDigJ0gZXRj4oCmLCB3aGljaCBhcmUgYWxyZWFkeSBwcmVzZW50IGluIFJG QzMyNjEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvbGdhPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBzaXBjb3JlIFttYWlsdG86c2lwY29y ZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5SaWZhYXQgU2hla2gtWXVz ZWY8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDksIDIwMTcgOTowNCBBTTxicj4N CjxiPlRvOjwvYj4gc2lwY29yZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc2lwY29y ZV0gU0lQIERpZ2VzdCAtIE9wZW4gSXNzdWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZXJlIGlzIGFuIG9wZW4gaXNzdWUgYXJvdW5kIHRoZSBEaWdlc3QgZHJhZnQgYW5kIEkgd291 bGQgbGlrZSB0byBnZXQgc29tZSB0aG91Z2h0cyBmcm9tIHRoZSBXRyBhYm91dCBpdDo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXl1c2VmLXNpcGNvcmUtZGlnZXN0 LXNjaGVtZS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC15dXNlZi1zaXBjb3JlLWRpZ2VzdC1zY2hlbWUvPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaXNzdWUgaXMgcmVsYXRl ZCB0byBzZWN0aW9uIDIuNSBGb3JraW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhpcyBhIHJlYWwgdXNlIGNhc2U/IGlmIHNvLCB0aGUg Y3VycmVudCB0ZXh0IGNhbGxzIGZvciB0aGUgcHJveHkgdG8gYWdncmVnYXRlIHRoZSByZXNwb25z ZXMgYW5kIGZvciB0aGUgVUFDIHRvIHJlc3BvbmQgdG8gdGhlIHRoZSBvbmVzIGl0IHN1cHBvcnQ7 IGlzIHRoaXMgYSByZWFzb25hYmxlIGFwcHJvYWNoPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcHByZWNpYXRlIGFueSB0aG91Z2h0cyBhYm91 dCB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7UmlmYWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CO2PR03MB234275628ACD940D566E0103B2210CO2PR03MB2342namp_-- From nobody Thu Mar 9 21:33:36 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A91129552 for ; Thu, 9 Mar 2017 21:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAGkPX9yDnNp for ; Thu, 9 Mar 2017 21:33:34 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF13C1294DB for ; Thu, 9 Mar 2017 21:33:34 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id w189so37590915pfb.0 for ; Thu, 09 Mar 2017 21:33:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GIiNOFXr8ERoLClWQULSaLBWD011AdsnWx28XQXyw0A=; b=sv8T0sNu9PM578f4Pqs666A9o7t+IBbOXly6Gc1j6bOZunxg9QWFb5yzIm2UyPnL6l LszLh2hOnWk7g+1dSeiQ2ORJKBTzt6yhzEO6UnSULePwZBT52CU1gso7oM8msh8CESyA 13z/37HKc/WwrKRWy/ajnDo9lSidpjqlfifrGmUrOaL+sY0TSh54NTcGy5qh1meYH2E2 0HMR+OZpuKpu0FzbkLdjK1DTk01xMyx47g7/AKmRYKJrBPvFKJMpW0V4upVSZIgpHvgV 4UiT7sqWZPDZ1ajl2ZvpAx2OxbuBSZaespLU242ZeuVY7bUOZaLA7mampoEUoRBwwRv9 U1bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GIiNOFXr8ERoLClWQULSaLBWD011AdsnWx28XQXyw0A=; b=S/t7UzMeJiD9mxOgYpb5m35n6cZ29FmDmPV2Q4qHp7QG5Iq2KxPiiWikqzQB/N7kHc K8UuWuPnzuQQ5a5mO5N+kjPiN2S6OR8lFZF/zTal6Tq3XET5SDVuEh0o55NhuCSDLndD 7tGYaHIhtwPU9uyNvQEJ9ZHGt7hcsnnD1ru+tRmhxUvW+YZJM/TfZ90+r2OMh4rZElFK 6ORI91pFs74jImcy69kzyTo1cAVAAALr2IdaZEo1AlJ5I/sF7dNy0/UZPC3YRnZwhCqz 5CXnYDxJvL4Plo+il6dE1vR4IO5k0ik6p++YrJHMuuP0Wz6Ucs6+1QdSs8QXzWDbsk7q 2DTg== X-Gm-Message-State: AMke39kOHB75pXtz3F+xbjR6nfOlcCwDcsCv95tdITP2U7N9kVAAE5AE3JU7/6AcjG+zf+iYQMm1OvFfPcmcww== X-Received: by 10.84.129.3 with SMTP id 3mr23134350plb.150.1489124014187; Thu, 09 Mar 2017 21:33:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.166.166 with HTTP; Thu, 9 Mar 2017 21:33:33 -0800 (PST) From: Ranjit Avasarala Date: Thu, 9 Mar 2017 23:33:33 -0600 Message-ID: To: SIPCORE Content-Type: multipart/alternative; boundary=94eb2c11a694e46c19054a59b3a8 Archived-At: Subject: [sipcore] Question on Event: route-trigger X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 05:33:35 -0000 --94eb2c11a694e46c19054a59b3a8 Content-Type: text/plain; charset=UTF-8 Hi is the Event: route-trigger a standard event package - if yes which I-D or RFC defines it? or is it specific to particular vendor implementations? (proprietary header) I see this Event in the NOTIFY request sent by Standalone S-CSCF to the Serving CSCF Event: route-trigger Thank you Regards Ranjit --94eb2c11a694e46c19054a59b3a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

is the Event: route-trigger a standa= rd event package - if yes which I-D or RFC defines it? or is it specific to= particular vendor implementations? (proprietary header)

I see this Event in the NOTIFY request sent by Standalone S-CSCF to = the Serving CSCF

Event: route-trigger

Thank you
Regards
Ranjit
--94eb2c11a694e46c19054a59b3a8-- From nobody Fri Mar 10 06:01:27 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5438C129954 for ; Fri, 10 Mar 2017 06:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nyh-FzZBLkqF for ; Fri, 10 Mar 2017 06:01:23 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B32B1298D3 for ; Fri, 10 Mar 2017 06:01:23 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id 72so113835826uaf.3 for ; Fri, 10 Mar 2017 06:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rBF/UaHgaND6O7oUHpZe6VvkJszWB9GKe3h1o1TFFqQ=; b=RYo2ytxOZncNhMjT0qeaVsop6d051tK096uunoj6De51IehxFksoQFeBNtL50OW8j1 aAYwrm3bUBNgGQ2eM7Xse8bSeLKqTpv6p5w0UvD9L0NYlZ86PTWQjSNkXkld5CFpCpR6 Hen/pUA8ZTO7nVdfYof3BL1F0xdVMSLMsbcXWQ8XoOG+fi/Jlu0fgxEjHFJZ05WMRlSp hRcyKK7/hS4548/isf676xHfF9lnqM+prX31G9jY/nJPoXB0rCRuNowTOxVXpFm46kTQ 523DWldRNhI/A5voSxsb7JqPXLClRR04v7XA5njNf5ePTbIFLEQs2R2N1ySIweQhrtFJ K+iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rBF/UaHgaND6O7oUHpZe6VvkJszWB9GKe3h1o1TFFqQ=; b=iIyGijHUtfCTHawMrlIq1Zyt6E3BOMqMjKJp76PBwU38+09wN8aUFyYNxdBRS50Phy FxaXagKoYNOMvGmJd4BsLPPUzir+OhzCpxJzk7zGtNebUmRcjqxBJhZqmYDCw9CosRW9 G+/shdzJLqBMwKyQs6P5LQ9Pdydi+AYXgcDFxKhxWE2UJwSxAIOfoN9KTNwfteEdGd7i M6NM3rn3Z4BtyGFaoCwWDklrf4rNQwtKJovC4Tm5stAgloxNsAHHgLJFtq7E7cdDsavy h/CEuBTT973WKRNGGvgDypa+dxtcgEA+WDThP+XDvSoW/aZgloYnzk5dE/pu2jsmzhGy LK2Q== X-Gm-Message-State: AMke39mLZnCKa5scn6831lC/X03B22nktfqzaZwuVObBzBk9TZKtxfGUN6iF71uCUkLJcyRwR1QQ07KSpVbp0Q== X-Received: by 10.31.4.211 with SMTP id 202mr9699353vke.105.1489154482673; Fri, 10 Mar 2017 06:01:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.146 with HTTP; Fri, 10 Mar 2017 06:01:22 -0800 (PST) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Fri, 10 Mar 2017 09:01:22 -0500 Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a11429d6ef4a0c3054a60cbbf Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP Digest - Open Issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 14:01:26 -0000 --001a11429d6ef4a0c3054a60cbbf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 9, 2017 at 2:42 PM, Asveren, Tolga wrote: > i- I think it needs to be handled. It may have a cohort of anti-fans but > forking is part of RFC3261 and should be covered for any scenario/new > mechanism. > > Ok. > > > ii- I am not sure whether =E2=80=9CUAC responds with the ones it supports= =E2=80=9D is the > right approach. New/updated implementations may follow that advice but wh= at > about existing UACs? > Existing UAC will use MD5 if present in the challenge. If MD5 is not present, it means that the server decided not to support MD5 and requires new clients that support SHA2. > I think there may be a need to define a new option-tag indicating support > for SHA*. If that is not present, only MD5 should be used. And actually > this comment is applicable for any scenario, not just for forking. For > forking, aggregation should consider the option-tag. > > > I am not clear on why an option-tag is needed; can you please elaborate? > iii- UAC supporting SHA* and receiving challenges for both MD5/SHA* shoul= d > reply for both of them. > It depends, if the challenge is coming from one server that supports both, then the UAC should prefer SHA2; otherwise, you are right, the UAC will have to provide both. > Authorization headers should be ordered based on the order of received > WWW/Proxy-Authenticate header if challenges for both MD5/SHA* are receive= d > for the same realm. This would be needed if forking happens and one of th= e > forked challengers support only MD5. Forking proxy should send only MD5 > Authorization header to such an entity. > This is already covered by the existing text. > iv- In general, I don=E2=80=99t think there is a need to repeat =E2=80=9C= Updates to HTTP=E2=80=9D > etc=E2=80=A6, which are already present in RFC3261. > > > There are few differences between what is in RFC3261 and what is in the draft. Also, this is provided for completeness to cover the Digest mechanism in one document. Regards, Rifaat > Thanks, > > Tolga > > > > *From:* sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of *Rifaat > Shekh-Yusef > *Sent:* Thursday, March 9, 2017 9:04 AM > *To:* sipcore@ietf.org > *Subject:* [sipcore] SIP Digest - Open Issue > > > > Hi, > > > > There is an open issue around the Digest draft and I would like to get > some thoughts from the WG about it: > > https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ > > > > The issue is related to section 2.5 Forking: > > Is this a real use case? if so, the current text calls for the proxy to > aggregate the responses and for the UAC to respond to the the ones it > support; is this a reasonable approach? > > > > Appreciate any thoughts about this. > > > > Regards, > > Rifaat > > > --001a11429d6ef4a0c3054a60cbbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 9, 2017 at 2:42 PM, Asveren, Tolga <tasveren@sonusnet.= com> wrote:

i- I think it needs to be handled. It may have a co= hort of anti-fans but forking is part of RFC3261 and should be covered for = any scenario/new mechanism.

Ok.

=C2=A0

=C2=A0

ii- I am not sure whether =E2=80=9CUAC responds wit= h the ones it supports=E2=80=9D is the right approach. New/updated implemen= tations may follow that advice but what about existing UACs?


Existing UAC will use MD5 if pres= ent in the challenge. If MD5 is not present, it means that the server decid= ed not to support MD5 and requires new clients that support SHA2.

=C2=A0

I think there may be a need to define a new option-tag indicating support fo= r SHA*. If that is not present, only MD5 should be used. And actually this = comment is applicable for any scenario, not just for forking. For forking, = aggregation should consider the option-tag.

=C2=A0


I am not clear on why an option-tag is needed; can you pl= ease elaborate?

=C2=A0

iii- UAC supporting SHA* and receiving challenges f= or both MD5/SHA* should reply for both of them.


It depends, if the challenge is coming from on= e server that supports both, then the UAC should prefer SHA2; otherwise, yo= u are right, the UAC will have to provide both.

= =C2=A0

Authorization headers should be ordered based on the order= of received WWW/Proxy-Authenticate header if challenges for both MD5/SHA* are received for the same realm. Th= is would be needed if forking happens and one of the forked challengers sup= port only MD5. Forking proxy should send only MD5 Authorization header to s= uch an entity.

=C2=A0
Thi= s is already covered by the existing text.

=C2=A0<= /div>

iv- In general, I don=E2=80=99t think there is a ne= ed to repeat =E2=80=9CUpdates to HTTP=E2=80=9D etc=E2=80=A6, which are alre= ady present in RFC3261.

=C2=A0


There are few differences between what is in RFC3261 and = what is in the draft. Also, this is provided for completeness to cover the = Digest mechanism in one document.

Regards,
=C2=A0Rifaat


=C2=A0
=

Thanks,

Tolga

=C2=A0

From: sipcore [mailto:sipcore-bounces@ietf.o= rg] On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, March 9, 2017 9:04 AM
To: sipcore@ie= tf.org
Subject: [sipcore] SIP Digest - Open Issue

<= div>

=C2=A0

Hi,

=C2=A0

There is an open issue around the Digest draft and I= would like to get some thoughts from the WG about it:

=C2=A0

The issue is related to section 2.5 Forking:<= u>

Is this a real use case? if so, the current text cal= ls for the proxy to aggregate the responses and for the UAC to respond to t= he the ones it support; is this a reasonable approach?

=C2=A0

Appreciate any thoughts about this.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0


--001a11429d6ef4a0c3054a60cbbf-- From nobody Fri Mar 10 06:40:56 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7814C129610 for ; Fri, 10 Mar 2017 06:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Igaxtq59KOD for ; Fri, 10 Mar 2017 06:40:54 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D10712960C for ; Fri, 10 Mar 2017 06:40:54 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-05v.sys.comcast.net with SMTP id mLincXzul4CjQmLivcvnFn; Fri, 10 Mar 2017 14:40:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1489156853; bh=6oxMvzQs1Yn2ZKf6/rD948puzWt/IPBj42Iiz1OuqZY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=o5kIuHv7I6NxilO6SIfRK3zqNXZ/ERfkth1EDGOzq89qovfxIqRNTb3/KNjx4f3Hk +iJW3OE9CjculXhMiA0faQeg+sHz8Mc6osPJAkg4t+4qE8B7mLdGSAO1FXeRDVJLaY xZM8hXfYjYx8f8fHEhVqTut/oMXRtEgifrM1DXIlIeOekIOjTefUVAiVCSoADImkP6 1PG6CogPC++ncsqjs8C70Aw9OMzbMJf+v7fZLdKHs2eheBbQ6RcTchzb2JJEOZcgSc KVVAMKCSry1nQvET1E8eFKD/j4dRMtcxcIf9X/IVEibc32nySFizNTjvPBTwWc4KKr zvu0xVksPfa1A== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-01v.sys.comcast.net with SMTP id mLiuco9YKt7zrmLivcnxDP; Fri, 10 Mar 2017 14:40:53 +0000 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: <2fad0fec-4d2e-83c8-2283-923322b21ae3@comcast.net> Date: Fri, 10 Mar 2017 09:40:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfEO/Xx08ErY8NZmnzubhO1w5aBKLpuyNnW9uMfctA2OZBlY0roSu1IYfY7np+pm/ymsIeuOZGt1oRuUTrmcsMYJsmw4gnjpyYl4atXar/nDuvPiaddqR RgmPGWhokEjZzp1WKJe+kI0nWxUC1tmIA1Y0Mo8c+qO/vLzoVtfZKG6CmJ07o97kJ1I87AlGMzyQCg== Archived-At: Subject: Re: [sipcore] Question on Event: route-trigger X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 14:40:55 -0000 On 3/10/17 12:33 AM, Ranjit Avasarala wrote: > Hi > > is the Event: route-trigger a standard event package - if yes which I-D > or RFC defines it? or is it specific to particular vendor > implementations? (proprietary header) > > I see this Event in the NOTIFY request sent by Standalone S-CSCF to the > Serving CSCF > > Event: route-trigger I don't find it listed in the iana registry (https://www.iana.org/assignments/sip-events/sip-events.xhtml), so it would seem that it is not a valid event package. Paul From nobody Fri Mar 10 06:50:44 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF12129962 for ; Fri, 10 Mar 2017 06:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWYMcFVNU2kM for ; Fri, 10 Mar 2017 06:50:42 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F17129628 for ; Fri, 10 Mar 2017 06:50:42 -0800 (PST) X-AuditID: c1b4fb25-e49bd98000004cad-7c-58c2bd4066ca Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id C7.47.19629.04DB2C85; Fri, 10 Mar 2017 15:50:40 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0319.002; Fri, 10 Mar 2017 15:50:39 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Question on Event: route-trigger Thread-Index: AQHSmV/f8FBeACPYJ0W3RwwSPWoJPaGOFR4AgAAlE4A= Date: Fri, 10 Mar 2017 14:50:39 +0000 Message-ID: References: <2fad0fec-4d2e-83c8-2283-923322b21ae3@comcast.net> In-Reply-To: <2fad0fec-4d2e-83c8-2283-923322b21ae3@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <815DDE6D77E0CD4CB900F23C2CAC70C7@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7oq7D3kMRBkd+6lg8+NHLZvH1xyY2 ByaPyY/nMHosWfKTKYApissmJTUnsyy1SN8ugSvjw6x/rAVP2Sturr3B3sC4ia2LkZNDQsBE 4vnXRpYuRi4OIYF1jBLt0/vZIJzFjBILHzUwdjFycLAJWEh0/9MGaRARCJHY/vMoK4gtLGAu cWDDXSaIuIXEli1vmCFsK4ktZy6AxVkEVCVmrnvPDmLzClhL9O65xwoxv5VRYv3DqWAJTgF7 iTltu8CGMgqISXw/tQasmVlAXOLWk/lMEJcKSCzZc54ZwhaVePn4H1i9qICexPLna6DiihI7 z7YzQ/TqSdyYOoUNwraWOP+6H8rWlli28DUzxEGCEidnPmGZwCg2C8m6WUjaZyFpn4WkfRaS 9gWMrKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAiPr4JbfqjsYL79xPMQowMGoxMP7Ifdg hBBrYllxZe4hRgkOZiUR3ra6QxFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEec1W3g8XEkhPLEnN Tk0tSC2CyTJxcEo1MJo/m8XZ9eHx5Yn+LDWVZ9rf/b1w+oTTrD9NV11/y72pPPVRc94cbo0z y6a/E4r+9P7WsmJjy2eVPB5dgZJf7p1uaLH3d52/KFkracLlCvGN91tLilnY3C84JgocmB2z 8JTb2h1mi8WPekywVbry6c9Cbi6383d/lMfqWAg5FW9fWmrwveOpu7QSS3FGoqEWc1FxIgAB DrcOqAIAAA== Archived-At: Subject: Re: [sipcore] Question on Event: route-trigger X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 14:50:44 -0000 Hi, I have never heard about this event package, so I don=B9t think it's something 3GPP has defined. Most likely something product specific. Regards, Christer On 10/03/17 16:40, "sipcore on behalf of Paul Kyzivat" wrote: >On 3/10/17 12:33 AM, Ranjit Avasarala wrote: >> Hi >> >> is the Event: route-trigger a standard event package - if yes which I-D >> or RFC defines it? or is it specific to particular vendor >> implementations? (proprietary header) >> >> I see this Event in the NOTIFY request sent by Standalone S-CSCF to the >> Serving CSCF >> >> Event: route-trigger > >I don't find it listed in the iana registry >(https://www.iana.org/assignments/sip-events/sip-events.xhtml), so it >would seem that it is not a valid event package. > > Paul > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Sat Mar 11 11:33:56 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE9812957A for ; Sat, 11 Mar 2017 11:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQXt_kAOKfSD for ; Sat, 11 Mar 2017 11:33:53 -0800 (PST) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [216.205.24.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3819126FDC for ; Sat, 11 Mar 2017 11:33:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eAdgz7DDI8cCdY801aQ3k6U3RwuGFVmj2K1v/ckk62U=; b=W8DOCpJzBymM+yJMI4832ZEn5wytnnip3CXzQh1n0WbctALjmubn9fnLIJDhQNmvhDCWK3MKz9po/59HMdxMPeIS+HuPPrX0YTf3DmHjYS5EmQ/ShuYlfBC5jgq+NTcxla177vgOLZX4t1ljYcBwm+J4P+okMPjPPwWqT84OFOc= Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0054.outbound.protection.outlook.com [207.46.163.54]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-5-fRKraN4CMEqn1ESG0vKpFA-1; Sat, 11 Mar 2017 14:33:48 -0500 Received: from CY1PR03MB2348.namprd03.prod.outlook.com (10.166.207.147) by CY1PR03MB2345.namprd03.prod.outlook.com (10.166.207.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Sat, 11 Mar 2017 19:33:43 +0000 Received: from CY1PR03MB2348.namprd03.prod.outlook.com ([10.166.207.147]) by CY1PR03MB2348.namprd03.prod.outlook.com ([10.166.207.147]) with mapi id 15.01.0947.020; Sat, 11 Mar 2017 19:33:42 +0000 From: "Asveren, Tolga" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP Digest - Open Issue Thread-Index: AQHSmabd59F0Rrqp00+e754nGHfo7aGOeoHA Date: Sat, 11 Mar 2017 19:33:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 1af5f615-bcde-45c7-de61-08d468b58701 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR03MB2345; x-microsoft-exchange-diagnostics: 1; CY1PR03MB2345; 7:kQaqg/XVyQAeDFJfWTAAh5pTJgrRKLC8C8xX8r7FGxZvqXQfJFm1iEUP3OqkKdTlzf163s4n5SUr4wBM2v+gHYGRS72UW3pGlJEyIqb2TQK00KDSBXt7/WyYxngwjUhRJhXvD/hHnNFu2M951WOrR2+UPsxZ0v88aCehIrw4VtKCdwLWEsnfy+7vJ5r7Xo4KKBkc3kYpO0J+Qvwpc5nThcebSKineajAGXQQ5F2eNlsyjialhhmHRw3Op6CcS7pYFaNnlonwfZWcdWFLlRxb3v6Uwgo5aw8b/3k1E+5QY5OBD0EYvuEaGhOnhTmJWuJvR9osCiHN2Aq6C+D6ZlDFoA==; 20:fCorVLQFScreXzOwDnqNMb3yi5+8WuCniuggA4NcZh16WImpCElo43vlDIk1K6vgbleBw1POPyWC52kpmv2aYuOuGWnnKaaQ14vXWGdgz99o05SP2K3wBlyIwDK3fl9pyyct9InHuQm6kRakqGwykRCdOxEiblaVoPfAOAX4ssc= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123558025)(20161123555025)(20161123560025)(20161123562025)(6072148); SRVR:CY1PR03MB2345; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2345; x-forefront-prvs: 0243E5FD68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(377454003)(24454002)(18543002)(3280700002)(105586002)(229853002)(3660700001)(2906002)(99286003)(6306002)(77096006)(55016002)(8676002)(6436002)(53546006)(122556002)(106116001)(54896002)(9686003)(86362001)(606005)(6916009)(68736007)(7696004)(2950100002)(6506006)(25786008)(81166006)(6246003)(38730400002)(53936002)(110136004)(8936002)(236005)(33656002)(39060400002)(4326008)(3846002)(6116002)(102836003)(5660300001)(7906003)(790700001)(7736002)(2900100001)(189998001)(54356999)(74316002)(76176999)(50986999)(66066001)(19609705001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR03MB2345; H:CY1PR03MB2348.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2017 19:33:42.7116 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2345 X-MC-Unique: fRKraN4CMEqn1ESG0vKpFA-1 Content-Type: multipart/alternative; boundary="_000_CY1PR03MB234897E86244C5A1B3E243CAB2230CY1PR03MB2348namp_" Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP Digest - Open Issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 19:33:55 -0000 --_000_CY1PR03MB234897E86244C5A1B3E243CAB2230CY1PR03MB2348namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SXQgc2VlbXMgYW4gb3B0aW9uLXRhZyB3b3VsZG7igJl0IGJlIG5lZWRlZCBpZiBleGlzdGluZyBV QUNzIGZvbGxvdyByZWxldmFudCBzcGVjaWZpY2F0aW9ucyB0byB0aGUgbGV0dGVyOg0KLSBSRkMy NjE3IChJIHJlZmVyIHRvIHRoaXMgb25lIHJhdGhlciB0aGFuIFJGQzc2MTYgYXMgdGhlIGxhdHRl ciBvbmUgaXMg4oCcdG9vIG5ld+KAnSBmb3IgbW9zdCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMp IHRlbGxzIHRoYXQgYSBjaGFsbGVuZ2Ugd2l0aCBhbiB1bmtub3duIGFsZ29yaXRobSBzaG91bGQg YmUgaWdub3JlZC4NCiAgYWxnb3JpdGhtDQogICAgIEEgc3RyaW5nIGluZGljYXRpbmcgYSBwYWly IG9mIGFsZ29yaXRobXMgdXNlZCB0byBwcm9kdWNlIHRoZSBkaWdlc3QNCiAgICAgYW5kIGEgY2hl Y2tzdW0uIElmIHRoaXMgaXMgbm90IHByZXNlbnQgaXQgaXMgYXNzdW1lZCB0byBiZSAiTUQ1Ii4N CiAgICAgSWYgdGhlIGFsZ29yaXRobSBpcyBub3QgdW5kZXJzdG9vZCwgdGhlIGNoYWxsZW5nZSBz aG91bGQgYmUgaWdub3JlZA0KICAgICAoYW5kIGEgZGlmZmVyZW50IG9uZSB1c2VkLCBpZiB0aGVy ZSBpcyBtb3JlIHRoYW4gb25lKS4NCk5vIFJGQzIxMTkga2V5d29yZHMgaGVyZSBidXQgc3RpbGwg SSB3b3VsZCB0YWtlIGl0IGFzIGEgbWFuZGF0ZS4gT1RPSCwgSSB3b3VsZG7igJl0IGJlIHN1cnBy aXNlZCwgaWYgdGhlcmUgYXJlIHF1aXRlIHNvbWUgaW1wbGVtZW50YXRpb25zIG91dCB0aGVyZSwg d2hpY2ggd291bGQgaGF2ZSBpc3N1ZXMgaW4gcHJhY3RpY2U6DQoNCi0gICAgICAgICAgVUFDIGln bm9yaW5nIGFsbCBjaGFsbGVuZ2VzIGlmIG9uZSBvZiB0aGVtIC1lc3BlY2lhbGx5IHRoZSB0b3Bt b3N0IG9uZS0gaGFzIGFuIHVua25vd24gYWxnb3JpdGhtDQoNCi0gICAgICAgICAgVUFDIGFzc3Vt aW5nIE1ENSB3aXRob3V0IGNoZWNraW5nIGFsZ29yaXRobSBmaWVsZCBhbmQgcmVwbHlpbmcgZm9y IGFsbCBjaGFsbGVuZ2VzIGFzIHN1Y2gNCg0KQW4gb3B0aW9uIHRhZyBtYXkgYmVuZWZpdCBhbHNv IG5ldyBVQUNzIHdoaWNoIGFyZSByZXBseWluZyB0byBoaWdoIHZvbHVtZSBvZiBjaGFsbGVuZ2Vz LCBlLmcuIGEgY29yZSBuZXR3b3JrIGVsZW1lbnQgcmF0aGVyIHRoYW4gYSBVRS4gSWYgdGhleSBh cmUgYWJsZSB0byBpbmRpY2F0ZSBzdXBwb3J0IGZvciBTSEEqLCBhIG5ldyBjaGFsbGVuZ2VyIHdv dWxkIGFzayBvbmx5IGZvciBpdC4gT3RoZXJ3aXNlIFVBQyB3b3VsZCBiZSBjaGFsbGVuZ2VkIHdp dGggYm90aCBNRDUvU0hBKiBhbmQgbmVlZHMgdG8gcmVwbHkgZm9yIGJvdGguICBDYW7igJl0IHdl IGFsbG93IFVBQyB0byByZXBseSBvbmx5IHdpdGggU0hBKj8gSSB3b3VsZG7igJl0IHRoaW5rIHNv LCBhcyB0aGVyZSBtYXkgYmUgZm9ya2luZyBhbmQgb25lIG9mIHRoZSBmb3JrZWQgY2hhbGxlbmdl cnMgbWF5IGJlIHVzaW5nIG9ubHkgTUQ1Lg0KDQpPdmVyYWxsLCBhbiBvcHRpb24tdGFnIGlzIG5v dCBhIHNlbWFudGljYWwgTVVTVCBidXQgd291bGQgYWRkIHJlYWwgdmFsdWUgaW4gcHJhY3RpY2Ug QUZBSUNULg0KDQpPbiBhbm90aGVyIG5vdGUsIEkgdGhpbmsgb3JkZXJpbmcgb2YgQXV0aGVudGlj YXRpb24gaGVhZGVyIHNob3VsZCBub3QgbWF0dGVyIGFzIOKAnGFsZ+KAnSBoYXMgdG8gYmUgaW5j bHVkZWQgaWYgaXQgaXMgbm90IE1ENSAoYWdhaW4gcGVyIGFib3ZlIHF1b3RlZCB0ZXh0KS4gT1RP SCwgSSB0aGluayBpdCBjb3VsZCBiZSBnb29kIHRvIG1hbmRhdGUvbWVudGlvbiB0aGlzIGV4cGxp Y2l0bHkgaW4gdGhlIGRyYWZ0Lg0KQW5kIFJGQzMyNjEgaGFzIHRoZSBmb2xsb3dpbmc6DQoNCiAg IFdoZW4gcmVzdWJtaXR0aW5nIGl0cyByZXF1ZXN0IGluIHJlc3BvbnNlIHRvIGEgNDAxIChVbmF1 dGhvcml6ZWQpIG9yDQogICA0MDcgKFByb3h5IEF1dGhlbnRpY2F0aW9uIFJlcXVpcmVkKSB0aGF0 IGNvbnRhaW5zIG11bHRpcGxlDQogICBjaGFsbGVuZ2VzLCBhIFVBQyBNQVkgaW5jbHVkZSBhbiBB dXRob3JpemF0aW9uIHZhbHVlIGZvciBlYWNoIFdXVy0NCiAgIEF1dGhlbnRpY2F0ZSB2YWx1ZSBh bmQgYSBQcm94eS1BdXRob3JpemF0aW9uIHZhbHVlIGZvciBlYWNoIFByb3h5LQ0KICAgQXV0aGVu dGljYXRlIHZhbHVlIGZvciB3aGljaCB0aGUgVUFDIHdpc2hlcyB0byBzdXBwbHkgYSBjcmVkZW50 aWFsLg0KICAgQXMgbm90ZWQgYWJvdmUsIG11bHRpcGxlIGNyZWRlbnRpYWxzIGluIGEgcmVxdWVz dCBTSE9VTEQgYmUNCiAgIGRpZmZlcmVudGlhdGVkIGJ5IHRoZSAicmVhbG0iIHBhcmFtZXRlci4N Cg0KV2hpY2ggcHJvYmFibHkgbmVlZCB0byBiZSB1cGRhdGVkIHRvIHNheSDigJxyZXF1ZXN0IFNI T1VMRCBiZSBkaWZmZXJlbnRpYXRlZCBieSB0aGUg4oCccmVhbG3igJ0v4oCdYWxn4oCdIHBhcmFt ZXRlciBjb21iaW5hdGlvbi4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogUmlmYWF0IFNoZWto LVl1c2VmIFttYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tXQ0KU2VudDogRnJpZGF5LCBNYXJj aCAxMCwgMjAxNyA5OjAxIEFNDQpUbzogQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0 LmNvbT4NCkNjOiBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFNJUCBE aWdlc3QgLSBPcGVuIElzc3VlDQoNCg0KDQpPbiBUaHUsIE1hciA5LCAyMDE3IGF0IDI6NDIgUE0s IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb208bWFpbHRvOnRhc3ZlcmVuQHNv bnVzbmV0LmNvbT4+IHdyb3RlOg0KaS0gSSB0aGluayBpdCBuZWVkcyB0byBiZSBoYW5kbGVkLiBJ dCBtYXkgaGF2ZSBhIGNvaG9ydCBvZiBhbnRpLWZhbnMgYnV0IGZvcmtpbmcgaXMgcGFydCBvZiBS RkMzMjYxIGFuZCBzaG91bGQgYmUgY292ZXJlZCBmb3IgYW55IHNjZW5hcmlvL25ldyBtZWNoYW5p c20uDQoNCk9rLg0KDQoNCg0KaWktIEkgYW0gbm90IHN1cmUgd2hldGhlciDigJxVQUMgcmVzcG9u ZHMgd2l0aCB0aGUgb25lcyBpdCBzdXBwb3J0c+KAnSBpcyB0aGUgcmlnaHQgYXBwcm9hY2guIE5l dy91cGRhdGVkIGltcGxlbWVudGF0aW9ucyBtYXkgZm9sbG93IHRoYXQgYWR2aWNlIGJ1dCB3aGF0 IGFib3V0IGV4aXN0aW5nIFVBQ3M/DQoNCkV4aXN0aW5nIFVBQyB3aWxsIHVzZSBNRDUgaWYgcHJl c2VudCBpbiB0aGUgY2hhbGxlbmdlLiBJZiBNRDUgaXMgbm90IHByZXNlbnQsIGl0IG1lYW5zIHRo YXQgdGhlIHNlcnZlciBkZWNpZGVkIG5vdCB0byBzdXBwb3J0IE1ENSBhbmQgcmVxdWlyZXMgbmV3 IGNsaWVudHMgdGhhdCBzdXBwb3J0IFNIQTIuDQoNCg0KSSB0aGluayB0aGVyZSBtYXkgYmUgYSBu ZWVkIHRvIGRlZmluZSBhIG5ldyBvcHRpb24tdGFnIGluZGljYXRpbmcgc3VwcG9ydCBmb3IgU0hB Ki4gSWYgdGhhdCBpcyBub3QgcHJlc2VudCwgb25seSBNRDUgc2hvdWxkIGJlIHVzZWQuIEFuZCBh Y3R1YWxseSB0aGlzIGNvbW1lbnQgaXMgYXBwbGljYWJsZSBmb3IgYW55IHNjZW5hcmlvLCBub3Qg anVzdCBmb3IgZm9ya2luZy4gRm9yIGZvcmtpbmcsIGFnZ3JlZ2F0aW9uIHNob3VsZCBjb25zaWRl ciB0aGUgb3B0aW9uLXRhZy4NCg0KDQpJIGFtIG5vdCBjbGVhciBvbiB3aHkgYW4gb3B0aW9uLXRh ZyBpcyBuZWVkZWQ7IGNhbiB5b3UgcGxlYXNlIGVsYWJvcmF0ZT8NCg0KDQppaWktIFVBQyBzdXBw b3J0aW5nIFNIQSogYW5kIHJlY2VpdmluZyBjaGFsbGVuZ2VzIGZvciBib3RoIE1ENS9TSEEqIHNo b3VsZCByZXBseSBmb3IgYm90aCBvZiB0aGVtLg0KDQpJdCBkZXBlbmRzLCBpZiB0aGUgY2hhbGxl bmdlIGlzIGNvbWluZyBmcm9tIG9uZSBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyBib3RoLCB0aGVuIHRo ZSBVQUMgc2hvdWxkIHByZWZlciBTSEEyOyBvdGhlcndpc2UsIHlvdSBhcmUgcmlnaHQsIHRoZSBV QUMgd2lsbCBoYXZlIHRvIHByb3ZpZGUgYm90aC4NCg0KDQpBdXRob3JpemF0aW9uIGhlYWRlcnMg c2hvdWxkIGJlIG9yZGVyZWQgYmFzZWQgb24gdGhlIG9yZGVyIG9mIHJlY2VpdmVkIFdXVy9Qcm94 eS1BdXRoZW50aWNhdGUgaGVhZGVyIGlmIGNoYWxsZW5nZXMgZm9yIGJvdGggTUQ1L1NIQSogYXJl IHJlY2VpdmVkIGZvciB0aGUgc2FtZSByZWFsbS4gVGhpcyB3b3VsZCBiZSBuZWVkZWQgaWYgZm9y a2luZyBoYXBwZW5zIGFuZCBvbmUgb2YgdGhlIGZvcmtlZCBjaGFsbGVuZ2VycyBzdXBwb3J0IG9u bHkgTUQ1LiBGb3JraW5nIHByb3h5IHNob3VsZCBzZW5kIG9ubHkgTUQ1IEF1dGhvcml6YXRpb24g aGVhZGVyIHRvIHN1Y2ggYW4gZW50aXR5Lg0KDQpUaGlzIGlzIGFscmVhZHkgY292ZXJlZCBieSB0 aGUgZXhpc3RpbmcgdGV4dC4NCg0KDQppdi0gSW4gZ2VuZXJhbCwgSSBkb27igJl0IHRoaW5rIHRo ZXJlIGlzIGEgbmVlZCB0byByZXBlYXQg4oCcVXBkYXRlcyB0byBIVFRQ4oCdIGV0Y+KApiwgd2hp Y2ggYXJlIGFscmVhZHkgcHJlc2VudCBpbiBSRkMzMjYxLg0KDQoNClRoZXJlIGFyZSBmZXcgZGlm ZmVyZW5jZXMgYmV0d2VlbiB3aGF0IGlzIGluIFJGQzMyNjEgYW5kIHdoYXQgaXMgaW4gdGhlIGRy YWZ0LiBBbHNvLCB0aGlzIGlzIHByb3ZpZGVkIGZvciBjb21wbGV0ZW5lc3MgdG8gY292ZXIgdGhl IERpZ2VzdCBtZWNoYW5pc20gaW4gb25lIGRvY3VtZW50Lg0KDQpSZWdhcmRzLA0KIFJpZmFhdA0K DQoNCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxm IE9mIFJpZmFhdCBTaGVraC1ZdXNlZg0KU2VudDogVGh1cnNkYXksIE1hcmNoIDksIDIwMTcgOTow NCBBTQ0KVG86IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBbc2lwY29yZV0gU0lQIERpZ2VzdCAtIE9wZW4gSXNzdWUNCg0KSGksDQoNClRoZXJlIGlz IGFuIG9wZW4gaXNzdWUgYXJvdW5kIHRoZSBEaWdlc3QgZHJhZnQgYW5kIEkgd291bGQgbGlrZSB0 byBnZXQgc29tZSB0aG91Z2h0cyBmcm9tIHRoZSBXRyBhYm91dCBpdDoNCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXl1c2VmLXNpcGNvcmUtZGlnZXN0LXNjaGVtZS8NCg0K VGhlIGlzc3VlIGlzIHJlbGF0ZWQgdG8gc2VjdGlvbiAyLjUgRm9ya2luZzoNCklzIHRoaXMgYSBy ZWFsIHVzZSBjYXNlPyBpZiBzbywgdGhlIGN1cnJlbnQgdGV4dCBjYWxscyBmb3IgdGhlIHByb3h5 IHRvIGFnZ3JlZ2F0ZSB0aGUgcmVzcG9uc2VzIGFuZCBmb3IgdGhlIFVBQyB0byByZXNwb25kIHRv IHRoZSB0aGUgb25lcyBpdCBzdXBwb3J0OyBpcyB0aGlzIGEgcmVhc29uYWJsZSBhcHByb2FjaD8N Cg0KQXBwcmVjaWF0ZSBhbnkgdGhvdWdodHMgYWJvdXQgdGhpcy4NCg0KUmVnYXJkcywNCiBSaWZh YXQNCg0KDQo= --_000_CY1PR03MB234897E86244C5A1B3E243CAB2230CY1PR03MB2348namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJh Z3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1z dHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1z dHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE1MTU0NTc1NDk7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE2NDY3OTk1MzQgLTExMzQ2 MjY5NzggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFy dC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxp c3QtaWQ6MTU0MjEzMDQ2MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6MjU1NzMxNjEyIDk3MzkzMDAwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwx OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JdCBz ZWVtcyBhbiBvcHRpb24tdGFnIHdvdWxkbuKAmXQgYmUgbmVlZGVkIGlmIGV4aXN0aW5nIFVBQ3Mg Zm9sbG93IHJlbGV2YW50IHNwZWNpZmljYXRpb25zIHRvIHRoZSBsZXR0ZXI6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LSBSRkMyNjE3IChJIHJlZmVyIHRvIHRo aXMgb25lIHJhdGhlciB0aGFuIFJGQzc2MTYgYXMgdGhlIGxhdHRlciBvbmUgaXMg4oCcdG9vIG5l d+KAnSBmb3IgbW9zdCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMpIHRlbGxzIHRoYXQgYSBjaGFs bGVuZ2Ugd2l0aCBhbiB1bmtub3duIGFsZ29yaXRobSBzaG91bGQgYmUgaWdub3JlZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IGFs Z29yaXRobTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQSBzdHJpbmcgaW5kaWNhdGluZyBhIHBhaXIg b2YgYWxnb3JpdGhtcyB1c2VkIHRvIHByb2R1Y2UgdGhlIGRpZ2VzdDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgYW5kIGEgY2hlY2tzdW0uIElmIHRoaXMgaXMgbm90IHByZXNlbnQgaXQgaXMgYXNzdW1l ZCB0byBiZSAmcXVvdDtNRDUmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJZiB0aGUgYWxn b3JpdGhtIGlzIG5vdCB1bmRlcnN0b29kLCB0aGUgY2hhbGxlbmdlIHNob3VsZCBiZSBpZ25vcmVk PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoYW5kIGEgZGlmZmVyZW50IG9uZSB1c2VkLCBpZiB0aGVy ZSBpcyBtb3JlIHRoYW4gb25lKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5ObyBSRkMyMTE5IGtleXdvcmRzIGhlcmUgYnV0IHN0aWxsIEkgd291bGQgdGFrZSBp dCBhcyBhIG1hbmRhdGUuIE9UT0gsIEkgd291bGRu4oCZdCBiZSBzdXJwcmlzZWQsIGlmIHRoZXJl IGFyZSBxdWl0ZSBzb21lIGltcGxlbWVudGF0aW9ucyBvdXQgdGhlcmUsIHdoaWNoIHdvdWxkIGhh dmUgaXNzdWVzIGluIHByYWN0aWNlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxl dmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5VQUMgaWdub3JpbmcgYWxsIGNoYWxsZW5n ZXMgaWYgb25lIG9mIHRoZW0gLWVzcGVjaWFsbHkgdGhlIHRvcG1vc3Qgb25lLSBoYXMgYW4gdW5r bm93biBhbGdvcml0aG08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZv MiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VUFDIGFzc3VtaW5nIE1ENSB3aXRob3V0IGNoZWNraW5n IGFsZ29yaXRobSBmaWVsZCBhbmQgcmVwbHlpbmcgZm9yIGFsbCBjaGFsbGVuZ2VzIGFzIHN1Y2g8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbiBvcHRpb24gdGFnIG1heSBi ZW5lZml0IGFsc28gbmV3IFVBQ3Mgd2hpY2ggYXJlIHJlcGx5aW5nIHRvIGhpZ2ggdm9sdW1lIG9m IGNoYWxsZW5nZXMsIGUuZy4gYSBjb3JlIG5ldHdvcmsgZWxlbWVudCByYXRoZXIgdGhhbiBhIFVF LiBJZiB0aGV5IGFyZSBhYmxlIHRvIGluZGljYXRlIHN1cHBvcnQgZm9yIFNIQSosIGEgbmV3IGNo YWxsZW5nZXINCiB3b3VsZCBhc2sgb25seSBmb3IgaXQuIE90aGVyd2lzZSBVQUMgd291bGQgYmUg Y2hhbGxlbmdlZCB3aXRoIGJvdGggTUQ1L1NIQSogYW5kIG5lZWRzIHRvIHJlcGx5IGZvciBib3Ro LiZuYnNwOyBDYW7igJl0IHdlIGFsbG93IFVBQyB0byByZXBseSBvbmx5IHdpdGggU0hBKj8gSSB3 b3VsZG7igJl0IHRoaW5rIHNvLCBhcyB0aGVyZSBtYXkgYmUgZm9ya2luZyBhbmQgb25lIG9mIHRo ZSBmb3JrZWQgY2hhbGxlbmdlcnMgbWF5IGJlIHVzaW5nIG9ubHkgTUQ1LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk92ZXJhbGwsIGFuIG9wdGlvbi10YWcgaXMgbm90IGEg c2VtYW50aWNhbCBNVVNUIGJ1dCB3b3VsZCBhZGQgcmVhbCB2YWx1ZSBpbiBwcmFjdGljZSBBRkFJ Q1QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+T24gYW5vdGhlciBub3Rl LCBJIHRoaW5rIG9yZGVyaW5nIG9mIEF1dGhlbnRpY2F0aW9uIGhlYWRlciBzaG91bGQgbm90IG1h dHRlciBhcyDigJxhbGfigJ0gaGFzIHRvIGJlIGluY2x1ZGVkIGlmIGl0IGlzIG5vdCBNRDUgKGFn YWluIHBlciBhYm92ZSBxdW90ZWQgdGV4dCkuIE9UT0gsIEkgdGhpbmsgaXQgY291bGQgYmUgZ29v ZCB0byBtYW5kYXRlL21lbnRpb24NCiB0aGlzIGV4cGxpY2l0bHkgaW4gdGhlIGRyYWZ0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFuZCBSRkMzMjYxIGhhcyB0 aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFdoZW4gcmVzdWJtaXR0aW5nIGl0cyByZXF1ZXN0 IGluIHJlc3BvbnNlIHRvIGEgNDAxIChVbmF1dGhvcml6ZWQpIG9yPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyA0MDcgKFBy b3h5IEF1dGhlbnRpY2F0aW9uIFJlcXVpcmVkKSB0aGF0IGNvbnRhaW5zIG11bHRpcGxlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyBjaGFsbGVuZ2VzLCBhIFVBQyBNQVkgaW5jbHVkZSBhbiBBdXRob3JpemF0aW9uIHZhbHVl IGZvciBlYWNoIFdXVy08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEF1dGhlbnRpY2F0ZSB2YWx1ZSBhbmQgYSBQcm94eS1B dXRob3JpemF0aW9uIHZhbHVlIGZvciBlYWNoIFByb3h5LTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQXV0aGVudGljYXRl IHZhbHVlIGZvciB3aGljaCB0aGUgVUFDIHdpc2hlcyB0byBzdXBwbHkgYSBjcmVkZW50aWFsLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgQXMgbm90ZWQgYWJvdmUsIG11bHRpcGxlIGNyZWRlbnRpYWxzIGluIGEgcmVxdWVz dCBTSE9VTEQgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGRpZmZlcmVudGlhdGVkIGJ5IHRoZSAmcXVvdDtyZWFsbSZx dW90OyBwYXJhbWV0ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldoaWNoIHByb2JhYmx5IG5lZWQgdG8gYmUg dXBkYXRlZCB0byBzYXkg4oCccmVxdWVzdCBTSE9VTEQgYmUgZGlmZmVyZW50aWF0ZWQgYnkgdGhl IOKAnHJlYWxt4oCdL+KAnWFsZ+KAnSBwYXJhbWV0ZXIgY29tYmluYXRpb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPlRvbGdhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBSaWZhYXQgU2hla2gtWXVzZWYgW21haWx0bzpyaWZhYXQuaWV0ZkBn bWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAxMCwgMjAxNyA5OjAx IEFNPGJyPg0KPGI+VG86PC9iPiBBc3ZlcmVuLCBUb2xnYSAmbHQ7dGFzdmVyZW5Ac29udXNuZXQu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gc2lwY29yZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3NpcGNvcmVdIFNJUCBEaWdlc3QgLSBPcGVuIElzc3VlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIgOSwgMjAxNyBhdCAyOjQyIFBNLCBBc3ZlcmVuLCBUb2xn YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5pLSBJIHRoaW5r IGl0IG5lZWRzIHRvIGJlIGhhbmRsZWQuIEl0IG1heSBoYXZlIGEgY29ob3J0IG9mIGFudGktZmFu cyBidXQgZm9ya2luZyBpcyBwYXJ0IG9mIFJGQzMyNjEgYW5kIHNob3VsZCBiZQ0KIGNvdmVyZWQg Zm9yIGFueSBzY2VuYXJpby9uZXcgbWVjaGFuaXNtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Pay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmlpLSBJIGFtIG5vdCBzdXJlIHdo ZXRoZXIg4oCcVUFDIHJlc3BvbmRzIHdpdGggdGhlIG9uZXMgaXQgc3VwcG9ydHPigJ0gaXMgdGhl IHJpZ2h0IGFwcHJvYWNoLiBOZXcvdXBkYXRlZCBpbXBsZW1lbnRhdGlvbnMNCiBtYXkgZm9sbG93 IHRoYXQgYWR2aWNlIGJ1dCB3aGF0IGFib3V0IGV4aXN0aW5nIFVBQ3M/IDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5FeGlzdGluZyBVQUMgd2lsbCB1c2UgTUQ1IGlmIHByZXNlbnQgaW4gdGhl IGNoYWxsZW5nZS4gSWYgTUQ1IGlzIG5vdCBwcmVzZW50LCBpdCBtZWFucyB0aGF0IHRoZSBzZXJ2 ZXIgZGVjaWRlZCBub3QgdG8gc3VwcG9ydCBNRDUgYW5kIHJlcXVpcmVzIG5ldyBjbGllbnRzIHRo YXQgc3VwcG9ydCBTSEEyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIHRoaW5rIHRoZXJlIG1heSBiZSBh IG5lZWQgdG8gZGVmaW5lIGEgbmV3IG9wdGlvbi10YWcgaW5kaWNhdGluZyBzdXBwb3J0IGZvciBT SEEqLiBJZiB0aGF0IGlzIG5vdCBwcmVzZW50LCBvbmx5DQogTUQ1IHNob3VsZCBiZSB1c2VkLiBB bmQgYWN0dWFsbHkgdGhpcyBjb21tZW50IGlzIGFwcGxpY2FibGUgZm9yIGFueSBzY2VuYXJpbywg bm90IGp1c3QgZm9yIGZvcmtpbmcuIEZvciBmb3JraW5nLCBhZ2dyZWdhdGlvbiBzaG91bGQgY29u c2lkZXIgdGhlIG9wdGlvbi10YWcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGFtIG5vdCBjbGVhciBvbiB3aHkgYW4gb3B0aW9uLXRhZyBpcyBuZWVkZWQ7IGNhbiB5 b3UgcGxlYXNlIGVsYWJvcmF0ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aWlpLSBVQUMgc3VwcG9ydGlu ZyBTSEEqIGFuZCByZWNlaXZpbmcgY2hhbGxlbmdlcyBmb3IgYm90aCBNRDUvU0hBKiBzaG91bGQg cmVwbHkgZm9yIGJvdGggb2YgdGhlbS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBk ZXBlbmRzLCBpZiB0aGUgY2hhbGxlbmdlIGlzIGNvbWluZyBmcm9tIG9uZSBzZXJ2ZXIgdGhhdCBz dXBwb3J0cyBib3RoLCB0aGVuIHRoZSBVQUMgc2hvdWxkIHByZWZlciBTSEEyOyBvdGhlcndpc2Us IHlvdSBhcmUgcmlnaHQsIHRoZSBVQUMgd2lsbCBoYXZlIHRvIHByb3ZpZGUgYm90aC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+QXV0aG9yaXphdGlvbiBoZWFkZXJzIHNob3VsZCBiZSBvcmRlcmVkIGJhc2Vk IG9uIHRoZSBvcmRlciBvZiByZWNlaXZlZCBXV1cvUHJveHktQXV0aGVudGljYXRlIGhlYWRlciBp ZiBjaGFsbGVuZ2VzDQogZm9yIGJvdGggTUQ1L1NIQSogYXJlIHJlY2VpdmVkIGZvciB0aGUgc2Ft ZSByZWFsbS4gVGhpcyB3b3VsZCBiZSBuZWVkZWQgaWYgZm9ya2luZyBoYXBwZW5zIGFuZCBvbmUg b2YgdGhlIGZvcmtlZCBjaGFsbGVuZ2VycyBzdXBwb3J0IG9ubHkgTUQ1LiBGb3JraW5nIHByb3h5 IHNob3VsZCBzZW5kIG9ubHkgTUQ1IEF1dGhvcml6YXRpb24gaGVhZGVyIHRvIHN1Y2ggYW4gZW50 aXR5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGFscmVhZHkgY292ZXJlZCBi eSB0aGUgZXhpc3RpbmcgdGV4dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aXYtIEluIGdlbmVyYWwsIEkg ZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhIG5lZWQgdG8gcmVwZWF0IOKAnFVwZGF0ZXMgdG8gSFRU UOKAnSBldGPigKYsIHdoaWNoIGFyZSBhbHJlYWR5IHByZXNlbnQgaW4gUkZDMzI2MS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSBmZXcgZGlmZmVyZW5j ZXMgYmV0d2VlbiB3aGF0IGlzIGluIFJGQzMyNjEgYW5kIHdoYXQgaXMgaW4gdGhlIGRyYWZ0LiBB bHNvLCB0aGlzIGlzIHByb3ZpZGVkIGZvciBjb21wbGV0ZW5lc3MgdG8gY292ZXIgdGhlIERpZ2Vz dCBtZWNoYW5pc20gaW4gb25lIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7UmlmYWF0PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Ub2xnYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHNpcGNvcmUgW21haWx0bzo8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UmlmYWF0IFNoZWtoLVl1c2VmPGJyPg0KPGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBNYXJjaCA5LCAyMDE3IDk6MDQgQU08YnI+DQo8Yj5Ubzo8L2I+IDwv c3Bhbj48YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+c2lwY29yZUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3NpcGNvcmVdIFNJUCBEaWdlc3QgLSBPcGVuIElzc3Vl PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhl cmUgaXMgYW4gb3BlbiBpc3N1ZSBhcm91bmQgdGhlIERpZ2VzdCBkcmFmdCBhbmQgSSB3b3VsZCBs aWtlIHRvIGdldCBzb21lIHRob3VnaHRzIGZyb20gdGhlIFdHIGFib3V0IGl0OjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC15dXNlZi1zaXBjb3JlLWRpZ2VzdC1z Y2hlbWUvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQteXVzZWYtc2lwY29yZS1kaWdlc3Qtc2NoZW1lLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBpc3N1ZSBpcyByZWxh dGVkIHRvIHNlY3Rpb24gMi41IEZvcmtpbmc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklzIHRoaXMgYSByZWFsIHVzZSBjYXNlPyBpZiBzbywg dGhlIGN1cnJlbnQgdGV4dCBjYWxscyBmb3IgdGhlIHByb3h5IHRvIGFnZ3JlZ2F0ZSB0aGUgcmVz cG9uc2VzIGFuZCBmb3IgdGhlIFVBQyB0byByZXNwb25kIHRvIHRoZSB0aGUgb25lcyBpdCBzdXBw b3J0OyBpcyB0aGlzIGEgcmVhc29uYWJsZSBhcHByb2FjaD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFwcHJlY2lhdGUgYW55IHRob3Vn aHRzIGFib3V0IHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDtSaWZhYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR03MB234897E86244C5A1B3E243CAB2230CY1PR03MB2348namp_-- From nobody Sun Mar 12 14:22:14 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F89129415; Sun, 12 Mar 2017 14:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nrEjIoMPnnZ; Sun, 12 Mar 2017 14:22:12 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5748126DFB; Sun, 12 Mar 2017 14:22:12 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 0CDC340371; Sun, 12 Mar 2017 22:22:11 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id DA0201A006E; Sun, 12 Mar 2017 22:22:10 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0319.002; Sun, 12 Mar 2017 22:22:10 +0100 From: To: "sipcore@ietf.org" Thread-Topic: Draft new: draft-mohali-sipcore-originating-cdiv-parameter-00 Thread-Index: AdKZo/JkmsQfXo7zS4WNCzh487z4dw== Date: Sun, 12 Mar 2017 21:22:09 +0000 Message-ID: <25855_1489353730_58C5BC02_25855_10494_1_8B970F90C584EA4E97D5BAAC9172DBB81C935BDC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sipcore-chairs@ietf.org" Subject: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-parameter-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 21:22:14 -0000 Hi all, Please find hereafter a new version of I-D, draft-mohali-sipcore-originatin= g-cdiv-parameter-00 (was draft-mohali-dispatch-originating-cdiv-parameter-0= 3). https://www.ietf.org/internet-drafts/draft-mohali-sipcore-originating-cdiv-= parameter-00.txt Based on ADs and Chairs guidance, this draft is moved from DISPATCH to SIPC= ORE following the new charter of sipcore WG. Abstract: This specification defines a new parameter of the P-Served-User header field in the Session Initiation Protocol (SIP). This new "orig-cdiv" parameter defines the session case used by a proxy when handling an originating session after Call Diversion (CDIV) services has been invoked for the served user. The P-Served-User header field is defined in RFC5502 to convey the identity of the served user and the session case that applies to this particular communication session and application invocation. This document updates RFC5502 to add the "originating after CDIV" session case and to provide more guidance for using the P-Served-User header field in IP networks that were missing in RFC5502. >From the discussion in DISPATCH, in this version of the draft, the syntax o= f the header could be improved as shown below: sessioncase-param =3D ("sescase" EQUAL ("orig" / "term")) / "orig-c= div" registration-state-param =3D "regstate" EQUAL ("unreg" / "reg") This draft is not in the agenda for IETF 98 but comments are welcomed anywa= y. Best regards, Marianne ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Mar 15 11:55:59 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9814C1317BF for ; Wed, 15 Mar 2017 11:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-m8_TzAFxEH for ; Wed, 15 Mar 2017 11:55:56 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C54C1317B0 for ; Wed, 15 Mar 2017 11:55:56 -0700 (PDT) Received: from unescapeable.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v2FIttN4012432 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 15 Mar 2017 13:55:55 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be unescapeable.local To: sipcore@ietf.org References: <87varkbeky.fsf@hobgoblin.ariadne.com> From: Robert Sparks Message-ID: <8d7c905c-3c4f-7475-4e89-5cfd66a07602@nostrum.com> Date: Wed, 15 Mar 2017 13:55:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87varkbeky.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-name-addr-guidance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:55:58 -0000 On 3/7/17 10:02 PM, Dale R. Worley wrote: > Of course, I favor approval of draft-ietf-sipcore-name-addr-guidance. > > I do think there are some nits that need to be resolved. Though since I > haven't been following this draft closely, these points may already have > been discussed. > > Dale > ---------------------------------------------------------------------- > Abstract > > It > also updates those extension SIP header fields that use the > alternative to clarify that the constraint applies (RFCs 3325, 3515, > 3892, 4508, 5002, 5318, 5360, and 5502). > > This isn't parallel to the 1st sentence of the paragraph, where the > object of "updates" is "RFC3261". > > Perhaps > > It also updates the RFCs (3325, 3515, 3892, 4508, 5002, 5318, > 5360, and 5502) that define the extension SIP header fields that > use the alternative to clarify that the constraint applies. I'll use a variation of that. > > 1. Introduction > > It is important to note that a message formed without honoring the > constraint will still be syntactically valid, but would be > interpreted differently. > > This is a subtle point... If the <...> is omitted, the header will > necessarily still be syntactically valid according to the BNF, reading > the original URI as an addr-spec -- the BNF is ambiguous in that way. > What *might* happen is that the header becomes parsable according to > the BNF in a different way also, one that parses the URI as multiple > elements. E.g., > > From: sip:10.0.0.1,sip:x@10.0.0.0 > > can be either parsed as one URI with user "10.0.0.1,sip" and password > "x", or two URIs, one "sip"10.0.0.1" and one "sip:x@10.0.0.0. > > OTOH, > > From: sip:10.0.0.1,@10.0.0.0 > > can only be parsed with the BNF as a single URI, because "@10.0.0.0" > doesn't parse as a URI. > > So it's more accurate to say > > It is important to note that a header formed without honoring the > constraint will still be syntactically valid, but might be > syntactically ambiguous and interpreted differently than it was > formed. s/formed/intended/? But I don't think changing will to might is correct. Can you construct a case where the refined guidance says you have to use the <>, and if leave them out you get the same interpretation? > > 4. IANA Considerations > > This memo has no considerations for IANA. > > Shouldn't the new RFC be listed in the IANA table of SIP header fields > (http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2) > as a reference for these header fields: > > P-Asserted-Identity > P-Preferred-Identity > P-Profile-Key > P-Refused-URI-List > P-Served-User > Permission-Missing > Refer-To > Referred-By > Reply-To > > And while we're at it, shouldn't RFC 4508 be a reference for Refer-To? Good question, but not this document's problem, and I don't remember if using Updates for this doc was discussed at the time (it should have been at least discussed). In any case, I propose the answer is no, for the reasons below. > > (Perhaps I'm not understanding how the "Reference" column of that table > is to be used.) So this is hard. My opinion is that it would be a mistake to try to mark updates in the iana registry as you suggest. Rather, the registry should point to the main defining document, and only the main defining document. Readers can follow the Updates links from the RFC pages. (Note that we _have_ changed that registry to reflect Obsoletes, which is consistent with the above.) My rational for that opinion is that we already have the Updates metadata in two databases (the RFC Editor and the datatracker). We have had, an expect will continue to have, conversations about moving to one authoritative database for that. If we were to try to also track this in the IANA registries, that unification gets even harder. I also note that if we _were_ to update the IANA registry column as you suggest, it's unusually easy to figure out which ones to modify for this particular draft's case. It becomes much murkier for the general case. Why, for example, would you not list 6141 along with every row that says 3261 (at least for any header field involved in reINVITE and target-refresh request handling). That could lead, in the extreme to a lot of noise, with most of the rows in that table saying: [RFC3261][RFC6665][RFC4320][RFC3265][RFC5954][RFC5630][RFC5393][RFC7463][RFC5626][RFC6878][RFC3853][RFC7462][RFC6026][RFC5621][RFC5922][RFC4916][RFC6141] I really think the right way to approach this is to keep the table as it is now. > > 5. Security Considerations > > One pre-existing consideration is worth reiterating: > messages produced without honoring the constraint will be mis- > interpreted by the receiving element. > > This should say "may be mis-interpreted", as discussed in the item for > section 1. Again, I don't think the change from will to may is correct. > > [END] > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Mar 16 12:46:47 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34969129A3E for ; Thu, 16 Mar 2017 12:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4owFJymGMlH6 for ; Thu, 16 Mar 2017 12:46:44 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD911299E5 for ; Thu, 16 Mar 2017 12:46:43 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-02v.sys.comcast.net with SMTP id obLKcSrnJWRJ0obMAcn2qc; Thu, 16 Mar 2017 19:46:42 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-14v.sys.comcast.net with SMTP id obM7cI3zwgvEdobM9crnGd; Thu, 16 Mar 2017 19:46:42 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2GJkdCO004548; Thu, 16 Mar 2017 15:46:39 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2GJkcF2004545; Thu, 16 Mar 2017 15:46:38 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Robert Sparks Cc: sipcore@ietf.org In-Reply-To: <8d7c905c-3c4f-7475-4e89-5cfd66a07602@nostrum.com> (rjsparks@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 16 Mar 2017 15:46:38 -0400 Message-ID: <87lgs5ypgh.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfMine/RLTGSd8LgFnjJeJ7JtyoUg6ak5V7tSWfOI37sDGqbnc41drSzvJ/pfYkRHgEwhSoUzszuSAaKVTCsti6PehOPteg2CaAG5V/hJBRpV87qwMdwr 7w6FwO+xMa+wfLncniWI6jPAIeJ7xeOE22DMJ6DSBrvGLn5vCYjOQjZ4SfhTinvK/+4Bl4usHleb5QZr4DmPkygpSxJRBtDxEwM= Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-name-addr-guidance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 19:46:45 -0000 Robert Sparks writes: >> 1. Introduction >> >> It is important to note that a message formed without honoring the >> constraint will still be syntactically valid, but would be >> interpreted differently. >> >> This is a subtle point... If the <...> is omitted, the header will >> necessarily still be syntactically valid according to the BNF, reading >> the original URI as an addr-spec -- the BNF is ambiguous in that way. >> What *might* happen is that the header becomes parsable according to >> the BNF in a different way also, one that parses the URI as multiple >> elements. E.g., >> >> From: sip:10.0.0.1,sip:x@10.0.0.0 >> >> can be either parsed as one URI with user "10.0.0.1,sip" and password >> "x", or two URIs, one "sip"10.0.0.1" and one "sip:x@10.0.0.0. >> >> OTOH, >> >> From: sip:10.0.0.1,@10.0.0.0 >> >> can only be parsed with the BNF as a single URI, because "@10.0.0.0" >> doesn't parse as a URI. >> >> So it's more accurate to say >> >> It is important to note that a header formed without honoring the >> constraint will still be syntactically valid, but might be >> syntactically ambiguous and interpreted differently than it was >> formed. > s/formed/intended/? You could phrase it that way. > But I don't think changing will to might is correct. > > Can you construct a case where the refined guidance says you have to use > the <>, and if leave them out you get the same interpretation? Let me see if I made a mistake here... If you form the header and violate the guidance by not using <>, the header will necessarily be parsable *by the BNF alone* in the way it was constructed. It might also be parsable by the BNF alone in another way. What the guidance does is resolve the parsing ambiguity by favoring the interpretation of comma, etc. as separators in the header rather than as characters in the URI. So if you want a From header containing "sip:10.0.0.1,sip:x@10.0.0.0", which has user "10.0.0.1,sip" and password "x", you should write: From: and if you write From: sip:10.0.0.1,sip:x@10.0.0.0 it's interpreted as two URIs, "sip:10.0.0.1" and "sip:x@10.0.0.0", which is syntactically correct but not what was intended. (It's also semantically incorrect.) If you want a From header containing "sip:10.0.0.1,@10.0.0.0", which has user "10.0.0.1,", you should write From: but if you do it wrong and write From: sip:10.0.0.1,@10.0.0.0 there's only one way to parse it with the BNF, and that is as you intended it. There's sort of an open issue as to what to do with that last header. Since the guidance forbids its use, there's no requirement for implementations to successfully parse it. But since there's only one way to parse it with the BNF, it's likely that a considerable number of implementations parse it as it was intended. At this point, I think the discussion is getting into the weeds regarding exactly how you describe the bad things that might happen if one violates the guidance, and I'll leave it to you! >> (Perhaps I'm not understanding how the "Reference" column of that table >> is to be used.) > So this is hard. > > My opinion is that it would be a mistake to try to mark updates in the > iana registry as you suggest. > Rather, the registry should point to the main defining document, and > only the main defining document. > Readers can follow the Updates links from the RFC pages. > (Note that we _have_ changed that registry to reflect Obsoletes, which > is consistent with the above.) > > My rational for that opinion is that we already have the Updates > metadata in two databases (the RFC Editor and the datatracker). We have > had, an expect will continue to have, conversations about moving to one > authoritative database for that. If we were to try to also track this in > the IANA registries, that unification gets even harder. And putting the updates information in the registry would be an additional duplication, which is undesirable in general. The loss is that in following the "RFC X updates RFC Y" links, RFC X may not update RFC Y in regard to a particular registry item, and there's no recording of that. I'm OK with this as a policy. Dale From nobody Fri Mar 17 11:50:24 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811011273E2 for ; Fri, 17 Mar 2017 11:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwSVO7AtkwZR for ; Fri, 17 Mar 2017 11:50:21 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [216.205.24.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1723D12709D for ; Fri, 17 Mar 2017 11:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jpS2veFcx6IqvJZaRyZ+QqTqUXn1vRqIUUcACP6lhOA=; b=oAsbM+JYhe43jH+F1bGw5iIuscCFn3aJs0kaISxhyK+HqJvmuJFB0vWSb2wfMq7GcVBY5X6eHBqQpWMn29B3WCIOMSJKPCufTK/VRlIyv/GEWiTqEAtCOJWSOjnvu3Tn412fCf3xy5sI1SDfzX67i4eMvJp/NWK0I13uoaFBFRk= Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0087.outbound.protection.outlook.com [207.46.163.87]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-149-M4EX6NqgPIql3okkvAggWQ-1; Fri, 17 Mar 2017 14:50:18 -0400 Received: from CY1PR03MB2348.namprd03.prod.outlook.com (10.166.207.147) by CY1PR03MB2346.namprd03.prod.outlook.com (10.166.207.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Fri, 17 Mar 2017 18:50:13 +0000 Received: from CY1PR03MB2348.namprd03.prod.outlook.com ([10.166.207.147]) by CY1PR03MB2348.namprd03.prod.outlook.com ([10.166.207.147]) with mapi id 15.01.0947.020; Fri, 17 Mar 2017 18:50:13 +0000 From: "Asveren, Tolga" To: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt Thread-Index: AQHSl4Qa/oL33GNqxEOvgmT/KrWS8qGZa+Pw Date: Fri, 17 Mar 2017 18:50:13 +0000 Message-ID: References: <148891966899.17640.11013846875357780343@ietfa.amsl.com> In-Reply-To: <148891966899.17640.11013846875357780343@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: efcc490b-a652-4fc2-6f8c-08d46d667237 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR03MB2346; x-microsoft-exchange-diagnostics: 1; CY1PR03MB2346; 7:HhNG9QXkzoXfZsfqdfuxJjrDbWw6xhtDLNctRl23tWjKYp7brkshA+rDHY1QpuUxMC6FdaNR8GyXIMvtDs3ODnBLrfCNyt7xFOCFgQoz+OB7VAusRyjbQV4yohIwJR5WCqszc7yT1A7zkUGs5SIeeBFOMBf/pN4NZ8RuYVn22re47My9YVIqisieiDZEvjSVrCopA+uugkZ/oF5WHoeG+5XBYw7BPJDT5fVkwJ2SShdkSwcTdCszij6/eSX49rQxLOR7eopsOlrS4+j4Uf462JTJ1GZa5rbD5jE8hdPY2QoZ6YZUkbgblEth6eWIJwggLIX+noLcxl4ujhXSY8s3Ng==; 20:gAQZy/D4jm0MD6UFphtDjiBsb3R4/YbHLCJmRqSiqoMVR1lAheezSWw+7fzYYct4iEEzRzPrgzz4DPiaSsZHWojqhj081qFBi+/vj+UnaozP7fTroJRnaLHOw//TLevmFuUcFcwmDgXGHO8z2sF7z1F3jwglJUMJBVq0beBxZ4Q= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123558025)(20161123562025)(6072148); SRVR:CY1PR03MB2346; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2346; x-forefront-prvs: 0249EFCB0B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(377424004)(377454003)(13464003)(6306002)(6246003)(3280700002)(229853002)(66066001)(50986999)(7696004)(110136004)(9686003)(54356999)(99286003)(86362001)(122556002)(53546008)(3660700001)(230783001)(2501003)(2351001)(6506006)(189998001)(38730400002)(102836003)(77096006)(6116002)(7736002)(305945005)(25786008)(76176999)(74316002)(5640700003)(81166006)(5660300001)(55016002)(1730700003)(2950100002)(6916009)(6436002)(2900100001)(2906002)(8936002)(8676002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR03MB2346; H:CY1PR03MB2348.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2017 18:50:13.3387 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2346 X-MC-Unique: M4EX6NqgPIql3okkvAggWQ-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 18:50:23 -0000 A few initial comments: i- It may be useful to cover scenarios where the "spam nature" of the call = can be determined only a while after call starts, e.g. based on speech anal= ysis. This probably would require defining a new event package. Does this s= ound useful/needed? ii- "type" parameter values seem over-specified to me. Actually overall I w= ould think that what is needed as aggregate information is (indicated in co= rresponding parameters): spam score verified identity of the entity which decided the spam score (+ unverified = identity of the entity which decided the spam score with an indication that= it is not verified) I am not sure I understand the practical use case for "reason" parameter an= d what type of values could be used there, therefore seems unnecessary to m= e. Just trying to apply "Occam's Razor". I think it would be best to define wh= at is really needed in a "as simple as possible but not simpler" way. Thanks, Tolga -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Tuesday, March 7, 2017 3:48 PM To: i-d-announce@ietf.org Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core of the IE= TF. Title : SIP Call-Info Parameters for Labeling Calls Author : Henning Schulzrinne =09Filename : draft-ietf-sipcore-callinfo-spam-00.txt =09Pages : 9 =09Date : 2017-03-07 Abstract: Called parties often wish to decide whether to accept, reject or redirect calls based on the likely nature of the call. For example, they may want to reject unwanted telemarketing or fraudulent calls, but accept emergency alerts from numbers not in their address book. This document describes SIP Call-Info parameters and a feature tag that allow originating, intermediate and terminating SIP entities to label calls as to their type, spam probability and references to additional information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sipcore-callinfo-spam-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Mar 17 13:19:31 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B862212953B for ; Fri, 17 Mar 2017 13:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9NKgUwyNm-b for ; Fri, 17 Mar 2017 13:19:26 -0700 (PDT) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BA9129538 for ; Fri, 17 Mar 2017 13:19:26 -0700 (PDT) Received: from pps.filterd (m0102171.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2HKIpFG023366; Fri, 17 Mar 2017 20:19:25 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0053.outbound.protection.outlook.com [23.103.198.53]) by mx0b-0024ed01.pphosted.com with ESMTP id 294970w5ya-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 17 Mar 2017 20:19:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=g6LGUezlwFd9FG6tmxZquEw7pPNskx7nJ9Hq03fodH8=; b=CYRCDlECRtvkJnXUDDbX8kUa5C7/zSZTAsd0PrYH1O+2m5BQsTNbJ7N7maFK5OsSfqMXBixGscK27Rbxi3M5W2VCJX9s7hwnGzRzxENJ/pDlEJM9Di06cf5qJsInNfX263yJsW6XWPpDVAsBTHeojo6z7NCkmfORUC9jnqAlr+4= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Fri, 17 Mar 2017 20:19:24 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0977.017; Fri, 17 Mar 2017 20:19:23 +0000 From: Henning Schulzrinne To: "Asveren, Tolga" , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt Thread-Index: AQHSl4QYSlhvTAkodUauVHHmkkcv0KGZb5aAgAAOnnA= Date: Fri, 17 Mar 2017 20:19:23 +0000 Message-ID: References: <148891966899.17640.11013846875357780343@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sonusnet.com; dkim=none (message not signed) header.d=none;sonusnet.com; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [192.104.54.21] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 7:fNpTapL6mi75bhYrSY2saohO3iZ33DYI4PYFcQQBkhKjxtJ1OG/MjwcsCS7/sYwEkJV717LpZ5n0l5YRJ+51GGWX1NqNjdSboc3wG5GqimbvAvRrWNEtJWz6J+NutBgQ+FHCv0X5TOSK/6upMvYtg52ahq7OcYDFYZW37xds20bO73pVl4V3LGGjIxTuEk3QCD9BwLLJ0LJQwbOZVRrYKgaUkHjmAxt+bokmjZu6rlmPxi4LO8LDLndJUwtQqLRXsFqBCp2rq8IZUu4JgLmztleWwsMkd03kQAtniGhRGx7JxFoHUn2aGqNgwXUywUl0wveBce7uYP+jorgrF7T9sQ== x-ms-office365-filtering-correlation-id: 96735e85-aac6-4496-35e9-08d46d72e745 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0634; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(20161123558025)(6072148); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 0249EFCB0B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(377454003)(377424004)(13464003)(6436002)(74316002)(102836003)(122556002)(5660300001)(53546008)(7736002)(305945005)(6116002)(33656002)(66066001)(6306002)(9686003)(99286003)(6506006)(55016002)(25786008)(77096006)(3660700001)(575784001)(86362001)(3280700002)(561944003)(7696004)(38730400002)(6246003)(229853002)(2906002)(2950100002)(8936002)(54356999)(76176999)(50986999)(2900100001)(81166006)(8676002)(230783001)(2501003)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2017 20:19:23.8448 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-17_15:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 20:19:30 -0000 (i) The notification is an interesting idea, but I wonder how much this wou= ld be used in practice. If the called party has already picked up, when wou= ld this add value? (Also, in many cases, mobile users won't see the screen = at that point, given that they are talking on the phone.) I suspect for tru= e scam calls, mid-call termination (BYE), e.g., for vulnerable populations,= may be more effective. (ii) The list was compiled by a group of industry participants, including l= awyers. I actually don't think the spam score alone helps, given that some = calls are likely ambiguous, such as surveys, charities (not-for-profit) and= debt-collection - they may be spammy to you, but acceptable to others. I s= till would like to know if a charity is calling since I can probably defer = answering when I'm at dinner or can auto-answer such calls when I'm traveli= ng in a different time zone. (I may have given permission to be called, but= not at 2 am local time.) Also, in general, I don't think spam scores have proven all that useful in = email, except very locally. There just isn't a good way to tell why somethi= ng is a "6" vs. a "7". I think it works ok as a confidence indicator within= a category - "I'm 70% certain that this is a charity call." If you have a specific proposal of types that are not needed or that should= be merged, please explain. The reason parameter is motivated by email experience - it's really importa= nt for developers to be able to tell how the decision was reached. I don't = think this will typically be made visible to users. As far as I know, all e= mail filter indicators include some version of a "reason" field. In those c= ases, it's often a collection of filters that (say) SpamAssassin used. (If = you look at their X-Spam-Score header, you'll see something like 0.01 HTML = or T_REMOTE_IMAGE LOW_PRICE indicating why the email was rated that way.) O= ften, the SIP request will be routed through some external "oracle" (analyt= ics) and you don't want this to be a complete black box, particularly if ca= lls are getting mislabeled. (I suspect we'll see this more in enterprise de= ployments than in consumer usage.) Henning -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, Tolga Sent: Friday, March 17, 2017 2:50 PM To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt A few initial comments: i- It may be useful to cover scenarios where the "spam nature" of the call = can be determined only a while after call starts, e.g. based on speech anal= ysis. This probably would require defining a new event package. Does this s= ound useful/needed? ii- "type" parameter values seem over-specified to me. Actually overall I w= ould think that what is needed as aggregate information is (indicated in co= rresponding parameters): spam score verified identity of the entity which decided the spam score (+ unverified = identity of the entity which decided the spam score with an indication that= it is not verified) I am not sure I understand the practical use case for "reason" parameter an= d what type of values could be used there, therefore seems unnecessary to m= e. Just trying to apply "Occam's Razor". I think it would be best to define wh= at is really needed in a "as simple as possible but not simpler" way. Thanks, Tolga -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Tuesday, March 7, 2017 3:48 PM To: i-d-announce@ietf.org Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core of the IE= TF. Title : SIP Call-Info Parameters for Labeling Calls Author : Henning Schulzrinne Filename : draft-ietf-sipcore-callinfo-spam-00.txt Pages : 9 Date : 2017-03-07 Abstract: Called parties often wish to decide whether to accept, reject or redirect calls based on the likely nature of the call. For example, they may want to reject unwanted telemarketing or fraudulent calls, but accept emergency alerts from numbers not in their address book. This document describes SIP Call-Info parameters and a feature tag that allow originating, intermediate and terminating SIP entities to label calls as to their type, spam probability and references to additional information. The IETF datatracker status page for this draft is: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _doc_draft-2Dietf-2Dsipcore-2Dcallinfo-2Dspam_&d=3DDwICAg&c=3Dy0h0omCe0jAUG= r4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DUmUs8Pe84oynK= 8LiSf2oV9iU9HfmKM-O2ORnd4HtaBM&s=3DT8v-YMJaYwTA2kYcBVnUaz-V6cXbwsOiGhCZEBl5= LzE&e=3D=20 There's also a htmlized version available at: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_= draft-2Dietf-2Dsipcore-2Dcallinfo-2Dspam-2D00&d=3DDwICAg&c=3Dy0h0omCe0jAUGr= 4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DUmUs8Pe84oynK8= LiSf2oV9iU9HfmKM-O2ORnd4HtaBM&s=3DpzEuOg9xKBqwbhaMniL2l1kSXZj8lnanrEYEI_6kJ= 4I&e=3D=20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_internet-= 2Ddrafts_&d=3DDwICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU= 1XeHIYRHfarpk4MK59RE&m=3DUmUs8Pe84oynK8LiSf2oV9iU9HfmKM-O2ORnd4HtaBM&s=3DAZ= fM7O8SbaBLtGuyW9Yqk-NSKY5Hdq13ap1hbsqQeHo&e=3D=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DUmUs8Pe84oynK8LiSf2oV9iU9HfmKM-O2ORnd4HtaB= M&s=3DEUOdVVVvCojGrq2IMjpYIyDza1cYIobUD2K_dYJYQVs&e=3D=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DUmUs8Pe84oynK8LiSf2oV9iU9HfmKM-O2ORnd4HtaB= M&s=3DEUOdVVVvCojGrq2IMjpYIyDza1cYIobUD2K_dYJYQVs&e=3D=20 From nobody Sat Mar 18 01:58:36 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC5A126557 for ; Sat, 18 Mar 2017 01:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lz7p6LTAWhZ for ; Sat, 18 Mar 2017 01:58:31 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [216.205.24.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753D0127011 for ; Sat, 18 Mar 2017 01:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JrZjerY8ulN7zhAzFucIFWK0C5DpksX5bW5QKJvXn5o=; b=gR3NL9THT3Yq4x7BQIMB11hQtJApMf4N5fLNPnnn9MYD+fifL4JoxCMg5uIKviVaApYuqC6dUUjZ4pLzNib3eGrsCbtaKsz0uv9wiyu7XLXK/e3okEtUsigrJCBOVOLFjs5AhDrcN4Dj8CtQvWsbGmJR8W/ov999BY1eJ8aTe+4= Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03lp0047.outbound.protection.outlook.com [216.32.180.47]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-59-IEIM8Y17PI68TeGQ8hk67Q-1; Sat, 18 Mar 2017 04:58:15 -0400 Received: from CY1PR03MB2348.namprd03.prod.outlook.com (10.166.207.147) by CY1PR03MB2347.namprd03.prod.outlook.com (10.166.207.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Sat, 18 Mar 2017 08:58:09 +0000 Received: from CY1PR03MB2348.namprd03.prod.outlook.com ([10.166.207.147]) by CY1PR03MB2348.namprd03.prod.outlook.com ([10.166.207.147]) with mapi id 15.01.0947.020; Sat, 18 Mar 2017 08:58:09 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt Thread-Index: AQHSl4Qa/oL33GNqxEOvgmT/KrWS8qGZa+PwgAAcnYCAAHvewA== Date: Sat, 18 Mar 2017 08:58:08 +0000 Message-ID: References: <148891966899.17640.11013846875357780343@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 09371ba3-7c7d-4c3b-d967-08d46ddce675 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254061); SRVR:CY1PR03MB2347; x-microsoft-exchange-diagnostics: 1; CY1PR03MB2347; 7:oYWOsGQV+xZEA8b/6PMIUtj/7Sj5X2xTQDzanT28aI9wXo4b1oHQS1oXFCIlscT2jmK9V2VtqeD/zkB04Kg3GVtSPd39kr/TvSYGQGJHnGkIDUva9axZlFa9jmFw8JLZ9sPi5BASLd/V4PHSz6sYcwETDZY6uw0n17crqPQRLeJsuxq4Rom3GLQuMefDMpHzX3LLuZDQinwqu4vbrm2Uww1416fshaWdrDq2w/wJDsQ1za0lJbQOndfJPXpnOqjJaoN5DkLcZ0h2cOCWaQNzWGbJOsWG7cnj8wJKti6psgh4TJPRIttfF9pcC5bxbTXjvSqh2VGs2hWwfutN5LWLVw==; 20:+hCJp+q7BlPM9D7A4NM5BjgKT6k8DbMQoqQq7HjJ/82EnJsx126mLR0G/Tgz3C0+7jFV3ON94hiu7jLZ/O9tRcvM+k9LWIufKiE+nuHWy0ofom6OJD18WS3A0kxzJ1A7vtduBQ6kt1FNEaIoRPME4WZQsgr4HO8QWrhwpVLaUJ4= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123558025)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:CY1PR03MB2347; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2347; x-forefront-prvs: 0250B840C1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(13464003)(377454003)(377424004)(122556002)(6306002)(2900100001)(99286003)(102836003)(77096006)(76176999)(25786008)(5660300001)(6116002)(3846002)(2906002)(6246003)(53546008)(575784001)(38730400002)(6436002)(6506006)(189998001)(33656002)(53936002)(3660700001)(55016002)(74316002)(305945005)(8936002)(3280700002)(2501003)(230783001)(229853002)(86362001)(8676002)(50986999)(561944003)(7736002)(54356999)(66066001)(7696004)(81166006)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR03MB2347; H:CY1PR03MB2348.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2017 08:58:08.8274 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2347 X-MC-Unique: IEIM8Y17PI68TeGQ8hk67Q-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 08:58:34 -0000 I agree that "spam-score" does not have much value from end-user perspectiv= e. When I check the weather report, what I care is whether I should get my = umbrella not the precise probability of rain. OTOH, I don't think the "natu= re of call" type of information would serve any practical purpose for end-u= ser. Stepping back and taking a somewhat more systematical approach: What are the main use cases? 1) Communicating spam related information between network elements for a pa= rticular call Various network elements may have a prediction whether a call is spam. It c= ould be useful to send all that info in a chain and then the ultimate decis= ion what needs to be sent to UE would be on the last-hop authorative entity= . A "0-100 spam score" indicator may be useful in this context, or at least= something more than just "likely to be spam" indicator. The identity of the entity providing spam score needs to be part of the pro= vided information. More than one spam score/identity pair needs to be supported. Support for signed identity should be there. I am not sure whether "type" would be useful here, I tend to think not. How= /Why would it be used?=20 2) Communicating spam related information between network and end-user I think here what is needed is just a "likely to be spam" indicator as far = as network prediction is concerned. End-user would see a visual indicator i= f the indicator is present. Anything more than that is just "information ov= erdose" IMHO and wouldn't have much practical value for an average user. An= other indicator stating "calling identity can't be verified" could be usefu= l but this IMHO is something different. An indicator for asking the end-user to provide information about whether h= e considers the call as spam would be useful and should be covered IMHO. Th= is would help Network Logic to learn/be more precise about heuristics appli= ed for spam detection. I can see a few different scenarios here: - Network decides to ask for feedback during initial INVITE, indicator can = a be a parameter in Call-Info - Network decides to ask for feedback after the call is setup, e.g. because= it detects that the call could be spam by speech analysis. Indicator can b= e sent in BYE, if the call is terminated by the calling party. Otherwise -i= f BYE is sent by called party-, network can still send BYE with the indicat= or toward calling party before 200 for the BYE received from it. I think th= is should work. In either case, end-user could see a visual indicator askin= g whether the call was spam. If he honors the request, 200(BYE) would have = the 666-unwanted. I am not sure what would be the best way to handle the si= tuation that the end-user hangs-up and then notices the indicator and decid= es to send feedback. UE can cache the Call-Id but conveying Call-Id/this wa= s(n't) a spam information to the network probably would require a new event= package. Alternatively, UE can buffer 200(BYE) for a while after user hang= s up -to give the user the opportunity to notice the indicator and act- but= that may have issues from billing perspective (maybe a "delayed =3D x sec"= parameter added to 200(BYE) could help). Thanks, Tolga -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Friday, March 17, 2017 4:19 PM To: Asveren, Tolga ; sipcore@ietf.org Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt (i) The notification is an interesting idea, but I wonder how much this wou= ld be used in practice. If the called party has already picked up, when wou= ld this add value? (Also, in many cases, mobile users won't see the screen = at that point, given that they are talking on the phone.) I suspect for tru= e scam calls, mid-call termination (BYE), e.g., for vulnerable populations,= may be more effective. (ii) The list was compiled by a group of industry participants, including l= awyers. I actually don't think the spam score alone helps, given that some = calls are likely ambiguous, such as surveys, charities (not-for-profit) and= debt-collection - they may be spammy to you, but acceptable to others. I s= till would like to know if a charity is calling since I can probably defer = answering when I'm at dinner or can auto-answer such calls when I'm traveli= ng in a different time zone. (I may have given permission to be called, but= not at 2 am local time.) Also, in general, I don't think spam scores have proven all that useful in = email, except very locally. There just isn't a good way to tell why somethi= ng is a "6" vs. a "7". I think it works ok as a confidence indicator within= a category - "I'm 70% certain that this is a charity call." If you have a specific proposal of types that are not needed or that should= be merged, please explain. The reason parameter is motivated by email experience - it's really importa= nt for developers to be able to tell how the decision was reached. I don't = think this will typically be made visible to users. As far as I know, all e= mail filter indicators include some version of a "reason" field. In those c= ases, it's often a collection of filters that (say) SpamAssassin used. (If = you look at their X-Spam-Score header, you'll see something like 0.01 HTML = or T_REMOTE_IMAGE LOW_PRICE indicating why the email was rated that way.) O= ften, the SIP request will be routed through some external "oracle" (analyt= ics) and you don't want this to be a complete black box, particularly if ca= lls are getting mislabeled. (I suspect we'll see this more in enterprise de= ployments than in consumer usage.) Henning -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, Tolga Sent: Friday, March 17, 2017 2:50 PM To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt A few initial comments: i- It may be useful to cover scenarios where the "spam nature" of the call = can be determined only a while after call starts, e.g. based on speech anal= ysis. This probably would require defining a new event package. Does this s= ound useful/needed? ii- "type" parameter values seem over-specified to me. Actually overall I w= ould think that what is needed as aggregate information is (indicated in co= rresponding parameters): spam score verified identity of the entity which decided the spam score (+ unverified = identity of the entity which decided the spam score with an indication that= it is not verified) I am not sure I understand the practical use case for "reason" parameter an= d what type of values could be used there, therefore seems unnecessary to m= e. Just trying to apply "Occam's Razor". I think it would be best to define wh= at is really needed in a "as simple as possible but not simpler" way. Thanks, Tolga -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Tuesday, March 7, 2017 3:48 PM To: i-d-announce@ietf.org Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core of the IE= TF. Title : SIP Call-Info Parameters for Labeling Calls Author : Henning Schulzrinne =09Filename : draft-ietf-sipcore-callinfo-spam-00.txt =09Pages : 9 =09Date : 2017-03-07 Abstract: Called parties often wish to decide whether to accept, reject or redirect calls based on the likely nature of the call. For example, they may want to reject unwanted telemarketing or fraudulent calls, but accept emergency alerts from numbers not in their address book. This document describes SIP Call-Info parameters and a feature tag that allow originating, intermediate and terminating SIP entities to label calls as to their type, spam probability and references to additional information. The IETF datatracker status page for this draft is: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _doc_draft-2Dietf-2Dsipcore-2Dcallinfo-2Dspam_&d=3DDwICAg&c=3Dy0h0omCe0jAUG= r4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DUmUs8Pe84oynK= 8LiSf2oV9iU9HfmKM-O2ORnd4HtaBM&s=3DT8v-YMJaYwTA2kYcBVnUaz-V6cXbwsOiGhCZEBl5= LzE&e=3D=20 There's also a htmlized version available at: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_= draft-2Dietf-2Dsipcore-2Dcallinfo-2Dspam-2D00&d=3DDwICAg&c=3Dy0h0omCe0jAUGr= 4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DUmUs8Pe84oynK8= LiSf2oV9iU9HfmKM-O2ORnd4HtaBM&s=3DpzEuOg9xKBqwbhaMniL2l1kSXZj8lnanrEYEI_6kJ= 4I&e=3D=20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_internet-= 2Ddrafts_&d=3DDwICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU= 1XeHIYRHfarpk4MK59RE&m=3DUmUs8Pe84oynK8LiSf2oV9iU9HfmKM-O2ORnd4HtaBM&s=3DAZ= fM7O8SbaBLtGuyW9Yqk-NSKY5Hdq13ap1hbsqQeHo&e=3D=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DUmUs8Pe84oynK8LiSf2oV9iU9HfmKM-O2ORnd4HtaB= M&s=3DEUOdVVVvCojGrq2IMjpYIyDza1cYIobUD2K_dYJYQVs&e=3D=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DUmUs8Pe84oynK8LiSf2oV9iU9HfmKM-O2ORnd4HtaB= M&s=3DEUOdVVVvCojGrq2IMjpYIyDza1cYIobUD2K_dYJYQVs&e=3D=20 From nobody Mon Mar 20 02:46:47 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774C9129A20; Mon, 20 Mar 2017 02:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTwlWGqBNnHN; Mon, 20 Mar 2017 02:46:37 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BF85129A04; Mon, 20 Mar 2017 02:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1490003158; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=6118; bh=MBxEWAU50LNMCUVW0hcH+LJb9Wd/fYfPHskJZHDxim0=; b=cGpHH2Bjb7ZjbGJGur7sV8JvU3A/7R0+okL6/8ObNz3iHHVWgsLxayPgKmyMBbf0 3+A0DM1s98LC2aoljYKMClAjjEZZ+FCnE9HvwwMWEfhFdR98fU1OkZkNnq7ZDo7aDqN H6FNFEO1vTxO7DIivdQgjbKRNNaxe40xVwV/AIJI= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 14900031585801.5719841635071816; Mon, 20 Mar 2017 02:45:58 -0700 (PDT) Date: Mon, 20 Mar 2017 09:45:58 +0000 From: Denis Ovsienko To: Cc: "IETF-Announce" , , , , "Adam Roach" , Message-ID: <15aeb1be62a.11b35bf8267637.2121189919710903185@ovsienko.info> In-Reply-To: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> References: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 09:46:39 -0000 Dear IETF members, if you can stop the publication below, please stop it now. If you cannot but know someone who can stop it, please ask them now to stop it. There is little time left because the last call for it ends tomorrow. The goal of IETF is to make Internet better but this document is about to make it worse. A principle of IETF is rough consensus but this document and the implementations arising from it will be toxic for consensus. This situation is effectively a test of how much sense we have. ============ Forwarded message ============ >From : To : Date : Fri, 17 Mar 2017 16:21:13 +0000 Subject : Re: Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard ============ Forwarded message ============ > ---- On Wed, 08 Mar 2017 00:23:06 +0000 The IESG wrote ---- > > > >The IESG has received a request from the Session Initiation Protocol Core > >WG (sipcore) to consider the following document: > >- 'A SIP Response Code for Unwanted Calls' > > as Proposed Standard > > > >The IESG plans to make a decision in the next few weeks, and solicits > >final comments on this action. Please send substantive comments to the > >ietf@ietf.org mailing lists by 2017-03-21. Exceptionally, comments may be > >sent to iesg@ietf.org instead. In either case, please retain the > >beginning of the Subject line to allow automated sorting. > > > >Abstract > > > > > > This document defines the 666 (Unwanted) SIP response code, allowing > > called parties to indicate that the call or message was unwanted. > > SIP entities may use this information to adjust how future calls from > > this calling party are handled for the called party or more broadly. > > > > Dear fellow IETF contributors, > > Though draft-ietf-sipcore-status-unwanted is as far in its development as in a last call, there is a point that I believe to be important enough to be raised now. The matter is, it would be very wrong to publish this document with the SIP message code assigned as the number of the beast. > > First of all, this would be wrong because of the end users. The proposed status code will be exposed to the end user base of SIP, which is so large that even a fraction of it is still a large number of real people, so specific consequences must be considered. > > If you mind people that take the Bible and its teachings seriously, it will be easy for them to see it as a personal insult if their phone receives and displays the message as it is proposed, as well as if their phone sends such a message on their behalf. This is not specific to SIP, the same conflict may be caused by a snail mail post, except in real-time communications people have less time to think and step back from the situation. > > As an additional consideration, the document implies that the user receiving the "unwanted" call has a good reason and the user placing the call does not have it, as in spam calls. In the real everyday world it may also be the different way around, for instance, someone may be avoiding calls due to problems with debt, job, alcohol, drugs, whatever, and that someone will just use the biggest "blacklist" button their phone can offer, just because they fail to think. There are other situations where this message code will be used as a handy tool for insulting genuine callers. > > It would be best here not to pour any more gas into this flame, moreover that professional spammers and phishers don't really care how exactly the call was terminated. Whatever status code was returned, they will continue calling numbers from the list until the end of the shift. So this feature as it is proposed may make more damage to normal people rather than to those who seem to be originally targeted. > > Then, if the document gets published and implemented as it is and starts causing grief, eventually people will want to know how the number of the beast got assigned to the message, they will look the document up and see: > > "The particular response code number was chosen to reflect the distaste felt by many upon receiving such calls." > > Which reads "We just needed some number, so we had chosen the number of the beast to make this new feature look cool. We acknowledge this number conveys some particular concept to many people but we deliberately disregard any future side effects." > > This is the only way I can read it, and the only way many other people will be able to read it. This is a fact, please deal with it while you can. > > Hopefully this helps to explain another important aspect. > > Besides the end users, there is the technical audience, both inside and outside of IETF. This audience expects a certain level of professionalism from IETF Standard Track publications. By not meeting those expectations this publication would disappoint the engineers too and lower their motivation to contribute. Simply put, the number of people that think "IETF has less respect to its intended audience than I used to think. They don't make Internet better, they are whim-driven, now that I know it, I better stay away." will increase. And they will actually stay away regardless if things improve afterwards. > > It may seem excess, but let me remind that the world is full of people who are mentally unwell and are on the verge of losing control, to the bad luck of poor strangers that happen to be around at the time. Often it is a tiny thing that finally tips their mind over. You cannot do much about this fact. But you can avoid introducing another potential last straw with an IETF label on it. > > To sum it up, the current revision of the I-D is going to increase the long-term risk of damage to IETF if it is published. I am asking you to change the codepoint to an ordinary nondescript number or to cancel the publication soonest possible. > > Thank you. > > -- > Denis Ovsienko -- Denis Ovsienko From nobody Mon Mar 20 07:23:12 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C376131499 for ; Mon, 20 Mar 2017 07:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxZNwSgsSNmg for ; Mon, 20 Mar 2017 07:23:09 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A806131497 for ; Mon, 20 Mar 2017 07:23:07 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-05v.sys.comcast.net with SMTP id py9ucmfAc4CjQpyDCcPUgm; Mon, 20 Mar 2017 14:23:06 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-19v.sys.comcast.net with SMTP id pyDAcHsmya1xFpyDBcXvG4; Mon, 20 Mar 2017 14:23:06 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2KEN2Vn022969; Mon, 20 Mar 2017 10:23:02 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2KEN1ZU022955; Mon, 20 Mar 2017 10:23:01 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Denis Ovsienko Cc: ietf@ietf.org, sipcore@ietf.org In-Reply-To: <15aeb1be62a.11b35bf8267637.2121189919710903185@ovsienko.info> (denis@ovsienko.info) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 20 Mar 2017 10:23:00 -0400 Message-ID: <87o9ww2fjv.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfKSCUUSaD+JbirTCA7mY+3vOrGqk/ncosy0rt+0sn/YZ0BqMLtTRKYCXIPBlAC2YYB0V9lb/SxANfrJsP7pacpYuSayzcBZobPcg84FV4grij8PHDFpQ UkGUxQvF8JWK9PRKZGI0MyG2uNVCP7hZvwX//liwQOMXzLnJFnOtqww1o/Sq+vA9/agWOvyzzixJc3R/toeiFRZ9EOwifXNS3fU= Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 14:23:10 -0000 Denis Ovsienko writes: > If you mind people that take the Bible and its teachings seriously, it > will be easy for them to see it as a personal insult if their phone > receives and displays the message as it is proposed, as well as if > their phone sends such a message on their behalf. This is not specific > to SIP, the same conflict may be caused by a snail mail post, except > in real-time communications people have less time to think and step > back from the situation. That seems to be a valid consideration to me: Embedding culturally/religiously/politically symbolic identifiers in a protocol in a way that end users will at least occasionally see is probably not a good idea. It's clear even to me that a flippant reference to the Prophet is asking for trouble, and it seems like we should take references to the Number of the Beast seriously, given its long history as a politically powerful symbol. > As an additional consideration, the document implies that the user > receiving the "unwanted" call has a good reason and the user placing > the call does not have it, as in spam calls. I'm not current on the document, but my understanding is that it makes clear that the response code is *in the opinion of the recipient* and must be interpreted as such. And indeed, that the recipient may have triggered the response accidentally. > Besides the end users, there is the technical audience, both inside > and outside of IETF. This audience expects a certain level of > professionalism from IETF Standard Track publications. By not meeting > those expectations this publication would disappoint the engineers too > and lower their motivation to contribute. Simply put, the number of > people that think "IETF has less respect to its intended audience than > I used to think. They don't make Internet better, they are > whim-driven, now that I know it, I better stay away." will > increase. And they will actually stay away regardless if things > improve afterwards. I think the evidence is that seriousness is not required to attract technical talent to the IETF. (See RFCs 439, 527, 748, 968, 1097, 1149, 1216, 1217, 1313, 1437, 1438, 1605, 1606, 1607, 1776, 1882, 1924, 1925, 1926, 1927, 2100, 2321, 2322, 2323, 2324, 2325, 2410, 2549, 2550, 2551, 2795, 3091, 3092, 3093, 3251, 3252, 3514, 3751, 4041, 4042, 4824, 5241, 5242, 5513, 5514, 5841, 5984, 6214, 6217, 6592, 6593, 6919, 6921, 7168, 7169, 7511, and 7514.) However, there might be a public relations problem concerning management, politicians, etc. Dale From nobody Mon Mar 20 08:29:57 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69E0127449 for ; Mon, 20 Mar 2017 08:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38WoqHgjQiPN for ; Mon, 20 Mar 2017 08:29:51 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2531279E5 for ; Mon, 20 Mar 2017 08:29:50 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-05v.sys.comcast.net with SMTP id pzDCcmlH34CjQpzFlcPolI; Mon, 20 Mar 2017 15:29:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1490023789; bh=MxqibTenyuHiQ0uk3r1y5gFi6npOctFvNi44Dc947n0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Qbg/yY4RtrUsuTB/vXeiEeVqf1dvKBBme5cjZ7r41h+5aisaNt8o273of0ZiMguF4 vIDT9hhVvHQpF6dizsRVW0hGetFSTXmTu5zYIjN0jEwPiPVErcJ/86lM/kdr7P1Okq Kxmt62MM/kcCFQ5IGJAMxdRtKzrojnefgsn5KJ0YwAm6S9u3aOy+pPVWa7/9KPiksJ ttlPJtI9lONfOGPxUbF/2Dydub5e2kzQYHoBS9X1c3XjqivIEytso/Y0EGr3w4+zHC a3bghFm2ONVkhsfKsqyhi6rl/vy/KZk544MPIGYts7JXQMZQbl6iL4JJIFB0qZ7/qH v/TLYPXKm9ztw== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-08v.sys.comcast.net with SMTP id pzFkc9S2r4ebhpzFkccaNY; Mon, 20 Mar 2017 15:29:49 +0000 To: sipcore@ietf.org References: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> <15aeb1be62a.11b35bf8267637.2121189919710903185@ovsienko.info> From: Paul Kyzivat Message-ID: <61afa707-5a0f-2ae2-b862-f373a84e6e76@comcast.net> Date: Mon, 20 Mar 2017 11:29:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <15aeb1be62a.11b35bf8267637.2121189919710903185@ovsienko.info> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfHyNeohFbv+KdsLdDd0hDRoYpiJ1jcxQi8dMVahWZ7hBqUcjDcadnfXdtzvAXbt5x07whr3mDceMOCfGwd7AcC4hES5qEsq+UD0UkbUC2j4dd3VIijgT Eobae9wt/YwhQJoOjAXI48OBWw7kxRWQpx7pGMAKTTtPNCMgC8942qWcXCvJqUIVWK+myCJJQq9VMQ== Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 15:29:55 -0000 [Trimming the distribution to sipcore to minimize the disruption.] Denis, Do you have any expertise with SIP? I don't recall ever seeing your name before. Your comments exhibit a profound misunderstanding of it. SIP response codes are almost never displayed to end users. For that matter they aren't even typically exposed to *operators* of SIP-based systems. Only when people are diagnosing signaling problems within the network are they visible. So the basic premise of your objection is ill-founded. Sincerely, Paul Kyzivat On 3/20/17 5:45 AM, Denis Ovsienko wrote: > Dear IETF members, > > if you can stop the publication below, please stop it now. If you cannot but know someone who can stop it, please ask them now to stop it. There is little time left because the last call for it ends tomorrow. > > The goal of IETF is to make Internet better but this document is about to make it worse. A principle of IETF is rough consensus but this document and the implementations arising from it will be toxic for consensus. > > This situation is effectively a test of how much sense we have. > > ============ Forwarded message ============ >>From : > To : > Date : Fri, 17 Mar 2017 16:21:13 +0000 > Subject : Re: Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard > ============ Forwarded message ============ > > ---- On Wed, 08 Mar 2017 00:23:06 +0000 The IESG wrote ---- > > > > > >The IESG has received a request from the Session Initiation Protocol Core > > >WG (sipcore) to consider the following document: > > >- 'A SIP Response Code for Unwanted Calls' > > > as Proposed Standard > > > > > >The IESG plans to make a decision in the next few weeks, and solicits > > >final comments on this action. Please send substantive comments to the > > >ietf@ietf.org mailing lists by 2017-03-21. Exceptionally, comments may be > > >sent to iesg@ietf.org instead. In either case, please retain the > > >beginning of the Subject line to allow automated sorting. > > > > > >Abstract > > > > > > > > > This document defines the 666 (Unwanted) SIP response code, allowing > > > called parties to indicate that the call or message was unwanted. > > > SIP entities may use this information to adjust how future calls from > > > this calling party are handled for the called party or more broadly. > > > > > > > Dear fellow IETF contributors, > > > > Though draft-ietf-sipcore-status-unwanted is as far in its development as in a last call, there is a point that I believe to be important enough to be raised now. The matter is, it would be very wrong to publish this document with the SIP message code assigned as the number of the beast. > > > > First of all, this would be wrong because of the end users. The proposed status code will be exposed to the end user base of SIP, which is so large that even a fraction of it is still a large number of real people, so specific consequences must be considered. > > > > If you mind people that take the Bible and its teachings seriously, it will be easy for them to see it as a personal insult if their phone receives and displays the message as it is proposed, as well as if their phone sends such a message on their behalf. This is not specific to SIP, the same conflict may be caused by a snail mail post, except in real-time communications people have less time to think and step back from the situation. > > > > As an additional consideration, the document implies that the user receiving the "unwanted" call has a good reason and the user placing the call does not have it, as in spam calls. In the real everyday world it may also be the different way around, for instance, someone may be avoiding calls due to problems with debt, job, alcohol, drugs, whatever, and that someone will just use the biggest "blacklist" button their phone can offer, just because they fail to think. There are other situations where this message code will be used as a handy tool for insulting genuine callers. > > > > It would be best here not to pour any more gas into this flame, moreover that professional spammers and phishers don't really care how exactly the call was terminated. Whatever status code was returned, they will continue calling numbers from the list until the end of the shift. So this feature as it is proposed may make more damage to normal people rather than to those who seem to be originally targeted. > > > > Then, if the document gets published and implemented as it is and starts causing grief, eventually people will want to know how the number of the beast got assigned to the message, they will look the document up and see: > > > > "The particular response code number was chosen to reflect the distaste felt by many upon receiving such calls." > > > > Which reads "We just needed some number, so we had chosen the number of the beast to make this new feature look cool. We acknowledge this number conveys some particular concept to many people but we deliberately disregard any future side effects." > > > > This is the only way I can read it, and the only way many other people will be able to read it. This is a fact, please deal with it while you can. > > > > Hopefully this helps to explain another important aspect. > > > > Besides the end users, there is the technical audience, both inside and outside of IETF. This audience expects a certain level of professionalism from IETF Standard Track publications. By not meeting those expectations this publication would disappoint the engineers too and lower their motivation to contribute. Simply put, the number of people that think "IETF has less respect to its intended audience than I used to think. They don't make Internet better, they are whim-driven, now that I know it, I better stay away." will increase. And they will actually stay away regardless if things improve afterwards. > > > > It may seem excess, but let me remind that the world is full of people who are mentally unwell and are on the verge of losing control, to the bad luck of poor strangers that happen to be around at the time. Often it is a tiny thing that finally tips their mind over. You cannot do much about this fact. But you can avoid introducing another potential last straw with an IETF label on it. > > > > To sum it up, the current revision of the I-D is going to increase the long-term risk of damage to IETF if it is published. I am asking you to change the codepoint to an ordinary nondescript number or to cancel the publication soonest possible. > > > > Thank you. > > > > -- > > Denis Ovsienko > From nobody Mon Mar 20 09:04:30 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075AC127A91 for ; Mon, 20 Mar 2017 09:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWsHy6r0lt21 for ; Mon, 20 Mar 2017 09:04:27 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20709127B57 for ; Mon, 20 Mar 2017 09:04:27 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-04v.sys.comcast.net with SMTP id pzlUcOzGWE5a6pznGcCfsu; Mon, 20 Mar 2017 16:04:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1490025866; bh=HLq9wq0phAbr3uFPIrwHns0k9gaQleS6WXzLvLqtBh4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ganz9or9gRNNngSaxbx5RYCRyAKJqPQ6Kh7yrDGabB8f4MMR/IT/xgkATUNoiFIl9 zFPHOZR2h5YZMlbtadz0qk1Z7Gxhc7Wh3YZMq9hoiXqilhllOKeSRdts8kXIRN958Y lQ/20mFE+ue1Dv0yrOrfw4ZyccWajs4oqCoSE+W8C8m1YQ/BVj/pF6ebamF2QJKt2T Bh5Q6WvlBDRj4PjbclJ91RNslb2vM8WosIjj8GsdFyGNgq6KsKXFMGcrMUVZ6GFxbP ElqHzpUwH7vN34OhIn0Ph3Do7RVWbVGeJHM35Y6BBPrGncFT94jWNu/cTFJ0eZ6VKG n083CPZ499FhQ== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-14v.sys.comcast.net with SMTP id pznFcbSU5gvEdpznGc1vFW; Mon, 20 Mar 2017 16:04:26 +0000 To: sipcore@ietf.org References: <87o9ww2fjv.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <4bab8383-07c9-7f9a-be8f-e75934b9adfd@comcast.net> Date: Mon, 20 Mar 2017 12:04:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87o9ww2fjv.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfIkxZAmbJbyl6QravBRXw+2JZll/7x4pWYRNW67CENAvPOwPg7cHDD9yi6stXJm2fyFILUEtFGahKWw5Wb96m0djjd7u53E3wEZlbUt9j06RBcYyY7i5 QxD8ERVoD2akgxr+9JwbgwEgqz0op5scqad9EWPHCyzDH9JFbPUgL6go9rZaYM2SXWJTdirayI327Q== Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 16:04:29 -0000 On 3/20/17 10:23 AM, Dale R. Worley wrote: > Denis Ovsienko writes: >> If you mind people that take the Bible and its teachings seriously, it >> will be easy for them to see it as a personal insult if their phone >> receives and displays the message as it is proposed, as well as if >> their phone sends such a message on their behalf. This is not specific >> to SIP, the same conflict may be caused by a snail mail post, except >> in real-time communications people have less time to think and step >> back from the situation. > > That seems to be a valid consideration to me: Embedding > culturally/religiously/politically symbolic identifiers in a protocol in > a way that end users will at least occasionally see is probably not a > good idea. It's clear even to me that a flippant reference to the > Prophet is asking for trouble, and it seems like we should take > references to the Number of the Beast seriously, given its long history > as a politically powerful symbol. I don't find it reasonable to cater to superstitious beliefs. (E.g. omitting the 13th floor from a building.) OTOH, I will agree that the choice of 666 as the response code here was not incidental - it clearly was chosen with that "Number of the Beast" connotation in mind. In that sense the choice was gratuitous. The requirement is that the number be of the form 6nn, and that it be one that has not already been assigned a meaning within the protocol. The process for assigning specific values for new response codes is ad hoc: - sometimes the next unassigned value is assigned, - sometimes sub-ranges are reserved for related values, - sometimes a value is assigned based on a similar value in another category. (E.g. 406 and 606). None of these would lead to 666 being an obvious choice in this case. Hence, I would not object to choosing a different value based on such criteria. BUT, should there ever be a need to assign another value in the 6nn range, and there is some rational reason (other than to explicitly reference the Number of the Beast), then I would strenuously object to objections based on this connotation of that particular value. Sincerely, Paul Kyzivat From nobody Mon Mar 20 12:57:41 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241971293D8; Mon, 20 Mar 2017 12:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5bvRG-9lvax; Mon, 20 Mar 2017 12:57:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBE6126C0F; Mon, 20 Mar 2017 12:57:29 -0700 (PDT) Received: from mutabilis-2.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v2KJvOWe044840 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 20 Mar 2017 14:57:24 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be mutabilis-2.local To: "Dale R. Worley" , Denis Ovsienko References: <87o9ww2fjv.fsf@hobgoblin.ariadne.com> Cc: sipcore@ietf.org, ietf@ietf.org, draft-ietf-sipcore-status-unwanted.all@ietf.org From: "A. Jean Mahoney" Message-ID: <7a26ee02-acb8-b6d3-6b9c-83232dd9bf47@nostrum.com> Date: Mon, 20 Mar 2017 14:57:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87o9ww2fjv.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 19:57:32 -0000 For some background - there was quite a bit of DISPATCH WG discussion on the use of the 666 response code to indicate that a call is unwanted, but it revolved around the use of a 6xx type of response vs. a 4xx response code. How the choice might be presented to the end user was also discussed, although SIPCORE and DISPATCH WGs don't focus on GUI stuff. When the end user receives a call, they could select a "Block Caller" button on their cell phone just like they can select "Send to Voice Mail". The application on the phone would then generate the 666 response code, but the app would be very unlikely to show this code to the end user. On the caller's end, their app may not show them anything more than their call failed. Realistically, the response code would be seen only in diagnostics. I took a look through the IETF archives for other uses of 666. 666 comes up occasionally in mailing list discussions as a foo/bar-type placeholder. RFC 7999 specifies the BGP community BLACKHOLE and its value, where "the low-order two octets in decimal are 666, a value commonly associated with BGP blackholing among network operators." That said, there's plenty of space in the SIP 6xx response code range for an alternate response code to be selected if we think this will likely make end users uncomfortable. Regards, Jean On 3/20/17 9:23 AM, Dale R. Worley wrote: > Denis Ovsienko writes: >> If you mind people that take the Bible and its teachings seriously, it >> will be easy for them to see it as a personal insult if their phone >> receives and displays the message as it is proposed, as well as if >> their phone sends such a message on their behalf. This is not specific >> to SIP, the same conflict may be caused by a snail mail post, except >> in real-time communications people have less time to think and step >> back from the situation. > > That seems to be a valid consideration to me: Embedding > culturally/religiously/politically symbolic identifiers in a protocol in > a way that end users will at least occasionally see is probably not a > good idea. It's clear even to me that a flippant reference to the > Prophet is asking for trouble, and it seems like we should take > references to the Number of the Beast seriously, given its long history > as a politically powerful symbol. > >> As an additional consideration, the document implies that the user >> receiving the "unwanted" call has a good reason and the user placing >> the call does not have it, as in spam calls. > > I'm not current on the document, but my understanding is that it makes > clear that the response code is *in the opinion of the recipient* and > must be interpreted as such. And indeed, that the recipient may have > triggered the response accidentally. > >> Besides the end users, there is the technical audience, both inside >> and outside of IETF. This audience expects a certain level of >> professionalism from IETF Standard Track publications. By not meeting >> those expectations this publication would disappoint the engineers too >> and lower their motivation to contribute. Simply put, the number of >> people that think "IETF has less respect to its intended audience than >> I used to think. They don't make Internet better, they are >> whim-driven, now that I know it, I better stay away." will >> increase. And they will actually stay away regardless if things >> improve afterwards. > > I think the evidence is that seriousness is not required to attract > technical talent to the IETF. (See RFCs 439, 527, 748, 968, 1097, 1149, > 1216, 1217, 1313, 1437, 1438, 1605, 1606, 1607, 1776, 1882, 1924, 1925, > 1926, 1927, 2100, 2321, 2322, 2323, 2324, 2325, 2410, 2549, 2550, 2551, > 2795, 3091, 3092, 3093, 3251, 3252, 3514, 3751, 4041, 4042, 4824, 5241, > 5242, 5513, 5514, 5841, 5984, 6214, 6217, 6592, 6593, 6919, 6921, 7168, > 7169, 7511, and 7514.) However, there might be a public relations > problem concerning management, politicians, etc. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Mar 20 16:26:42 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3EF12EE45 for ; Mon, 20 Mar 2017 16:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQLmST3XOMI3 for ; Mon, 20 Mar 2017 16:26:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D37B4129412 for ; Mon, 20 Mar 2017 16:26:39 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v2KNQZ2T064837 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 20 Mar 2017 18:26:36 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Paul Kyzivat , sipcore@ietf.org References: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> <15aeb1be62a.11b35bf8267637.2121189919710903185@ovsienko.info> <61afa707-5a0f-2ae2-b862-f373a84e6e76@comcast.net> From: Adam Roach Message-ID: Date: Mon, 20 Mar 2017 18:26:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <61afa707-5a0f-2ae2-b862-f373a84e6e76@comcast.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 23:26:41 -0000 [as chair] On 3/20/17 10:29, Paul Kyzivat wrote: > [Trimming the distribution to sipcore to minimize the disruption.] To be clear, this is an IETF LC comment. For better or worse (in practice, it's a mix of both), such conversations take place on the ietf@ietf.org mailing list to ensure that the document has the consensus of the IETF as a whole, rather than just the consensus of their originating working group. I understand the desire to be less disruptive, but we also don't want to restrict the discussion to a smaller venue than is appropriate. Please direct future comments in this thread to the ietf@ietf.org mailing list. Thanks! /a From nobody Mon Mar 20 17:08:12 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7846F13161E for ; Mon, 20 Mar 2017 17:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyG9d7W3SQJH for ; Mon, 20 Mar 2017 17:08:05 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B14712940F for ; Mon, 20 Mar 2017 17:08:03 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-03v.sys.comcast.net with SMTP id q7LGc8tITfuM3q7LGcxN65; Tue, 21 Mar 2017 00:08:02 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-06v.sys.comcast.net with SMTP id q7LEc8QwbeyvGq7LFcoObV; Tue, 21 Mar 2017 00:08:02 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2L080o0020143; Mon, 20 Mar 2017 20:08:00 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2L07xvl020140; Mon, 20 Mar 2017 20:07:59 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "A. Jean Mahoney" Cc: denis@ovsienko.info, sipcore@ietf.org, ietf@ietf.org, draft-ietf-sipcore-status-unwanted.all@ietf.org In-Reply-To: <7a26ee02-acb8-b6d3-6b9c-83232dd9bf47@nostrum.com> (mahoney@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 20 Mar 2017 20:07:59 -0400 Message-ID: <878tnz331c.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfEdKgm6BZvS+7a8y/t0gZPj6WzgBhkkgUXoA8KYqU/KYKVw/wLdTxur/m8hwN5e+JhjIZ2B651p/zi4fQnKK82YApwvq+mSnLpCv2uGl8SZzSZ+nhaIQ ZKHi5apXwpe7uJxy+5dz1/vq8sy+vlKzjt3Unfw6gK0PxV+TEpnriavQ2VLEizVJrNbHAQgPoVU8hnTa33yYodQd4+r3RTwYH+tZECBOZeeWawxGCRkEtzr6 SbNrKndWd05ElDDdTzcR+lDUAku47FkfoTrJuzd70cjVKhLooZp6Zb1El+LSXD9meKvxwd3zU0XrwzRUpKRQ7w== Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 00:08:06 -0000 "A. Jean Mahoney" writes: > That said, there's plenty of space in the SIP 6xx response code range > for an alternate response code to be selected if we think this will > likely make end users uncomfortable. I must say that the alternative that comes immediately to my mind is "668: The Neighbor of the Beast". Dale From nobody Tue Mar 21 08:50:46 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57054129AB6; Tue, 21 Mar 2017 08:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.02 X-Spam-Level: X-Spam-Status: No, score=-7.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-4Gaw8-XuXm; Tue, 21 Mar 2017 08:50:28 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CBE41294AF; Tue, 21 Mar 2017 08:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1490111421; x=1521647421; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=tsRl5NYOvjEn2/FzpJOd34ru5uPfLszQrij2J1p4QPM=; b=qOd2jimYokLF129ETcV2LmXYo26aF856VzF85tkFqEwDYrNIC92r/LaM Ss3ocgcWK2WzzPU8i4UQtpuJKy4I29XZIqH7NkjyDw9DMVu/iHoBi4urM JV6Y+KzDHP9vFuMxH/Y9LDNA0wyk7FTcymu+Rylc1JcCtrtViqUb/rA0v g=; X-IronPort-AV: E=Sophos;i="5.36,198,1486454400"; d="scan'208,217";a="367202202" Received: from unknown (HELO ironmsg02-L.qualcomm.com) ([10.53.140.109]) by wolverine02.qualcomm.com with ESMTP; 21 Mar 2017 08:50:19 -0700 X-IronPort-AV: E=McAfee;i="5800,7501,8474"; a="889593651" X-MGA-submission: =?us-ascii?q?MDEoF+InG7h0SkbWffbqB85amB+WZZbWsfszXI?= =?us-ascii?q?DMlZfrfU7PoRwzShRNMplvtNZd/BlbDfjJ9dZrLzxxM+IyaggVwy+JGZ?= =?us-ascii?q?HUZkK6NW+IcNfeCZuAJDzIW7KP++KSDCZxgJdu+BdhLzLfsr9VI3ZNBg?= =?us-ascii?q?Xp?= Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Mar 2017 08:50:18 -0700 Received: from [10.64.124.243] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 21 Mar 2017 08:49:56 -0700 From: Pete Resnick To: CC: , , , Adam Roach , Date: Tue, 21 Mar 2017 10:49:54 -0500 Message-ID: In-Reply-To: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> References: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_248277D9-D4E8-447F-B38B-F126A560CB0A_=" X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 15:50:32 -0000 --=_MailMate_248277D9-D4E8-447F-B38B-F126A560CB0A_= Content-Type: text/plain; format=flowed; markup=markdown I'm sorry to say that I do not think this mechanism is well thought out, I think it actually causes active harm to interoperability, and I think this document should be abandoned for a better (and simpler) solution to the problem, which I describe below. I will note that I have not been following the discussion of this document except for it's introduction at the last plenary meeting, but I (and others) did give comments at that time that as far as I can tell were not taken into account. I did review the thread on the sipcore list regarding the difference between the new code and the 603 code. That thread does not address my concerns, and in fact in some way reinforces it. I have not reviewed other discussion on the list. The purported purpose of this 666 mechanism is to allow additional semantics to be expressed beyond a simple 603 (Decline). That is a fine desire. However, instead of adding decent semantics to declining a call, 666 adds only one additional bit of information to 603, and that one bit ends up causing more semantic ambiguity: The user has still declined the call (just as 603 would have), and has added that the call is *somehow* unwanted (so a provider *could* act to prevent such calls in the future), but the user has not indicated the *reason* they indicate the call is unwanted. Is it because they want to add this calling party to a call block list? Is it that they want to reject all calls of this particular class (cf. draft-ietf-sipcore-callinfo-spam)? Is there some other handling that would be appropriate given the particular reason the user has rejected the call? The best a provider is going to be able to do is guess. The document admits the ambiguity in the semantics, saying that the provider will have to use heuristics to guess at what the user really wants. We should not be introducing a new mechanism that only adds to the semantic ambiguity and might end up with results that the user might specifically not want in a particular case. What I think was really intended all along was to have un-upgraded implementations treat these rejections just like 603, but add some semantics that upgraded implementations can use to determine what ought to be done in the future. The right solution, IMO, is to simply add a header to the 603 response that indicates what the user means by their declining, and gives a real indication of how handle such calls in the future. Call it "Decline-Type" for argument sake. Just like the Retry-After header adds semantics to indicate when the caller might want to try an identical call again, this new header will indicate that the user never wants a call from this particular caller again (e.g., "Decline-Type: block-caller", which the service provider can definitively use to add the caller to a block list), or that this caller and every caller with a similar type should be rejected (e.g. "Decline-Type: block-caller-type; type=political", which the provider could definitively use to reject similar calls in the future), etc.. With this, there's no need for a bunch of MAYs such that appear in section 4, you get an extensible mechanism that could be used by any 603 response. You also get the added bonus that un-upgraded entities will continue to treat this just like every other 603 without a Retry-After header, which is exactly what you want. To be clear, the three things I am concerned about are: 1. The 666 mechanism leaves the decision of what is meant by "unwanted" to the provider, which will inevitably cause data loss through the use of heuristics. Adding a header to the 603 response is an extensible mechanism that could capture the single semantic bit of 666 *and any future semantics that one wishes to add*, without requiring the provider to guess. The provider gets definitive information that it can act on. 2. The 666 mechanism limits the implementation of the mechanism to a 1-button choice and requires additional standardization work to use a different UI. Clearly 666 was designed around something akin to a "SPAM" button in the UI. But what if I want a field in my address book that says, "Permanently block this particular caller" (say, my ex-boyfriend or my annoying neighbor)? I don't want to indicate that these are spam calls because I don't want my provider applying heuristics to them. I want to send back a 603 with a header that says, "Block these whenever you see them, but only for me." I can think of all sorts of other-than-one-button UIs that someone might want to implement. 666 is tied to a particular UI. 603 with a header is extensible. 3. The 666 mechanism will be treated as a 600 "Busy" error by un-upgraded callers and/or providers. That might imply to some implementations that they should try to re-dial (e.g., the provider using the auto-redial feature) or to engage in other poor behavior. 603 with no Retry-After header already has a semantic of "The call was rejected and I'm not telling you when a good time to call back is", so there is some hope that an un-upgraded caller is more likely to do the right thing. Given the admittedly restricted review of the WG archive that I did, I didn't see anything to indicate that the WG fully considered the implications of 666 that I have outlined above. This is not simply a design preference; I believe the design of the proposed mechanism doesn't accomplish the goal and actually does some harm. Overall, 666 damages interoperability by introducing an ambiguous piece of information, which will lead to potential data loss (i.e., improperly applied heuristics), and will require adding a header in the future in order to accomplish the real goal. Adding a header is a simple mechanism, accomplishes the desired task, has extensibility, and doesn't cause the problems that 666 does. Please reconsider this, drop this document, and replace it by adding real semantics to the 603 response with an extensible header. It's a quick document to write (a bunch of the text in the current document can be reused) and it will not suffer the problems that 666 introduces. Otherwise, we're going to be right back where were when we started, needing to add a mechanism so that the user can really indicate what they mean. This is the wrong solution. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 On 7 Mar 2017, at 18:23, The IESG wrote: > The IESG has received a request from the Session Initiation Protocol > Core > WG (sipcore) to consider the following document: > - 'A SIP Response Code for Unwanted Calls' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2017-03-21. Exceptionally, comments may > be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document defines the 666 (Unwanted) SIP response code, > allowing > called parties to indicate that the call or message was unwanted. > SIP entities may use this information to adjust how future calls > from > this calling party are handled for the called party or more > broadly. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ballot/ > > > No IPR declarations have been submitted directly on this I-D. --=_MailMate_248277D9-D4E8-447F-B38B-F126A560CB0A_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

I'm sorry to say that I do not think this mechanism is we= ll thought out, I think it actually causes active harm to interoperabilit= y, and I think this document should be abandoned for a better (and simple= r) solution to the problem, which I describe below.

I will note that I have not been following the discussion= of this document except for it's introduction at the last plenary meetin= g, but I (and others) did give comments at that time that as far as I can= tell were not taken into account. I did review the thread on the sipcore= list regarding the difference between the new code and the 603 code. Tha= t thread does not address my concerns, and in fact in some way reinforces= it. I have not reviewed other discussion on the list.

The purported purpose of this 666 mechanism is to allow a= dditional semantics to be expressed beyond a simple 603 (Decline). That i= s a fine desire. However, instead of adding decent semantics to declining= a call, 666 adds only one additional bit of information to 603, and that= one bit ends up causing more semantic ambiguity: The user has still decl= ined the call (just as 603 would have), and has added that the call is somehow unwanted (so a provider could act to prevent such= calls in the future), but the user has not indicated the reason= they indicate the call is unwanted. Is it because they want to add this = calling party to a call block list? Is it that they want to reject all ca= lls of this particular class (cf. draft-ietf-sipcore-callinfo-spam)? Is t= here some other handling that would be appropriate given the particular r= eason the user has rejected the call? The best a provider is going to be = able to do is guess. The document admits the ambiguity in the semantics, = saying that the provider will have to use heuristics to guess at what the= user really wants. We should not be introducing a new mechanism that onl= y adds to the semantic ambiguity and might end up with results that the u= ser might specifically not want in a particular case. What I think was re= ally intended all along was to have un-upgraded implementations treat the= se rejections just like 603, but add some semantics that upgraded impleme= ntations can use to determine what ought to be done in the future.

The right solution, IMO, is to simply add a header to the= 603 response that indicates what the user means by their declining, and = gives a real indication of how handle such calls in the future. Call it "= Decline-Type" for argument sake. Just like the Retry-After header adds se= mantics to indicate when the caller might want to try an identical call a= gain, this new header will indicate that the user never wants a call from= this particular caller again (e.g., "Decline-Type: block-caller", which = the service provider can definitively use to add the caller to a block li= st), or that this caller and every caller with a similar type should be r= ejected (e.g. "Decline-Type: block-caller-type; type=3Dpolitical", which = the provider could definitively use to reject similar calls in the future= ), etc.. With this, there's no need for a bunch of MAYs such that appear = in section 4, you get an extensible mechanism that could be used by any 6= 03 response. You also get the added bonus that un-upgraded entities will = continue to treat this just like every other 603 without a Retry-After he= ader, which is exactly what you want.

To be clear, the three things I am concerned about are:

  1. The 666 mechanism leaves the decision of = what is meant by "unwanted" to the provider, which will inevitably cause = data loss through the use of heuristics. Adding a header to the 603 respo= nse is an extensible mechanism that could capture the single semantic bit= of 666 and any future semantics that one wishes to add, without= requiring the provider to guess. The provider gets definitive informatio= n that it can act on.

  2. The 666 mechanism limits the implementati= on of the mechanism to a 1-button choice and requires additional standard= ization work to use a different UI. Clearly 666 was designed around somet= hing akin to a "SPAM" button in the UI. But what if I want a field in my = address book that says, "Permanently block this particular caller" (say, = my ex-boyfriend or my annoying neighbor)? I don't want to indicate that t= hese are spam calls because I don't want my provider applying heuristics = to them. I want to send back a 603 with a header that says, "Block these = whenever you see them, but only for me." I can think of all sorts of othe= r-than-one-button UIs that someone might want to implement. 666 is tied t= o a particular UI. 603 with a header is extensible.

  3. The 666 mechanism will be treated as a 60= 0 "Busy" error by un-upgraded callers and/or providers. That might imply = to some implementations that they should try to re-dial (e.g., the provid= er using the auto-redial feature) or to engage in other poor behavior. 60= 3 with no Retry-After header already has a semantic of "The call was reje= cted and I'm not telling you when a good time to call back is", so there = is some hope that an un-upgraded caller is more likely to do the right th= ing.

Given the admittedly restricted review of the WG archive = that I did, I didn't see anything to indicate that the WG fully considere= d the implications of 666 that I have outlined above. This is not simply = a design preference; I believe the design of the proposed mechanism doesn= 't accomplish the goal and actually does some harm. Overall, 666 damages = interoperability by introducing an ambiguous piece of information, which = will lead to potential data loss (i.e., improperly applied heuristics), a= nd will require adding a header in the future in order to accomplish the = real goal. Adding a header is a simple mechanism, accomplishes the desire= d task, has extensibility, and doesn't cause the problems that 666 does. = Please reconsider this, drop this document, and replace it by adding real= semantics to the 603 response with an extensible header. It's a quick do= cument to write (a bunch of the text in the current document can be reuse= d) and it will not suffer the problems that 666 introduces. Otherwise, we= 're going to be right back where were when we started, needing to add a m= echanism so that the user can really indicate what they mean. This is the= wrong solution.

pr
--
Pete Resnick http://www.qualcomm.com/~presnick/
Qualcomm Technologies, Inc. - +1 (858)651-4478

On 7 Mar 2017, at 18:23, The IESG wrote:

The IESG has received a request from the Session Initiati= on Protocol Core
WG (sipcore) to consider the following document:
- 'A SIP Response Code for Unwanted Calls'
<draft-ietf-sipcore-status-unwanted-04.txt> as Proposed Standard<= /p>

The IESG plans to make a decision in the next few weeks, = and solicits
final comments on this action. Please send substantive comments to the ietf@ietf.org m= ailing lists by 2017-03-21. Exceptionally, comments may be
sent to iesg@ietf.o= rg instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

This document defines the 666 (Unwanted) SIP response cod= e, allowing
called parties to indicate that the call or message was unwanted.
SIP entities may use this information to adjust how future calls from<= br> this calling party are handled for the called party or more broadly.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-= sipcore-status-unwanted/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draf= t-ietf-sipcore-status-unwanted/ballot/

No IPR declarations have been submitted directly on this = I-D.

--=_MailMate_248277D9-D4E8-447F-B38B-F126A560CB0A_=-- From nobody Tue Mar 21 09:17:57 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCBC129B38; Tue, 21 Mar 2017 09:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxBERvS4Ui7v; Tue, 21 Mar 2017 09:17:46 -0700 (PDT) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCF212995F; Tue, 21 Mar 2017 09:17:18 -0700 (PDT) Received: from pps.filterd (m0102174.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2LGDpqp029524; Tue, 21 Mar 2017 16:17:15 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0050.outbound.protection.outlook.com [23.103.198.50]) by mx0b-0024ed01.pphosted.com with ESMTP id 298x2etch5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 21 Mar 2017 16:17:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=40HLLg4mGSBGniO73cPEMaDO3w+jgB3RLb/b90ymTpc=; b=jWPXpf7V/Wxj00QaYsqYW7XU/VLJNJnO86JOJjOV43+xSddmW9YbYkBvEWjKj5HfaSnOOXjGQc+aWW12TfC2Xds67dRr0lFucuRRin5HlwacguYOrs9cXMOv5pe9ddmJVCRn2+EoX4Xl45YRTrerHGUQ5oxdTmTAeLsi8L08baU= Received: from BY1PR09MB0631.namprd09.prod.outlook.com (10.160.110.19) by BY1PR09MB0632.namprd09.prod.outlook.com (10.160.110.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Tue, 21 Mar 2017 16:17:05 +0000 Received: from BY1PR09MB0631.namprd09.prod.outlook.com ([10.160.110.19]) by BY1PR09MB0631.namprd09.prod.outlook.com ([10.160.110.19]) with mapi id 15.01.0977.020; Tue, 21 Mar 2017 16:17:06 +0000 From: Henning Schulzrinne To: Pete Resnick , "ietf@ietf.org" CC: "draft-ietf-sipcore-status-unwanted@ietf.org" , "sipcore@ietf.org" Thread-Topic: Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard Thread-Index: AQHSl6Iq2il9S89Skk6DXPjEXEA7BqGfhkwAgAACiiA= Date: Tue, 21 Mar 2017 16:17:05 +0000 Message-ID: References: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: qti.qualcomm.com; dkim=none (message not signed) header.d=none;qti.qualcomm.com; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [192.104.54.21] x-microsoft-exchange-diagnostics: 1; BY1PR09MB0632; 7:5Clsj+FykMgrlJ6G1oQYX1tAltxUVsCWgyyV0cDPfm6C/wd3WzeTFzWWJeyCSLipJzZZGvz9WPG1bG8F6eYmwu16D894D1jZObsoLVFzHaGcODTZCCZ9A9XYhZuHYznGLUGbvIskuucdBn6nv1dSQf17LS2NUC96I7LItikGKCJDMzVo7b62kSgr1TKOzZJGuvZs34kfKmtYP0jHh5gWKlH21jC4Uvc4oV7fkJClOj+HyYiPGhTrH2pRbduqmK3hEzeJwQkO4E/LfcgeQufEypnpzLiXlqxOTyiPLlcRr7LhEB0BxT8m0m7A1Vs2u4CHkllPwlYZAJIq6rNltfGfjA== x-ms-office365-filtering-correlation-id: 4c08bd21-9c69-46c7-e4ca-08d47075b7aa x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:BY1PR09MB0632; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(120809045254105)(788757137089)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:BY1PR09MB0632; BCL:0; PCL:0; RULEID:; SRVR:BY1PR09MB0632; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(24454002)(377454003)(33656002)(54356999)(50986999)(76176999)(230783001)(102836003)(790700001)(3846002)(6116002)(66066001)(25786009)(8676002)(966004)(2900100001)(86362001)(38730400002)(7696004)(6306002)(6246003)(53936002)(606005)(19609705001)(74316002)(3280700002)(7736002)(5660300001)(5890100001)(2501003)(7906003)(122556002)(4326008)(6436002)(2906002)(8936002)(81166006)(53546009)(2950100002)(54906002)(99286003)(55016002)(3660700001)(77096006)(6506006)(236005)(9686003)(54896002)(229853002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR09MB0632; H:BY1PR09MB0631.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY1PR09MB0631F94D0B74E498ECCF3A4DEA3D0BY1PR09MB0631namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 16:17:05.8465 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR09MB0632 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-21_12:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 16:17:50 -0000 --_000_BY1PR09MB0631F94D0B74E498ECCF3A4DEA3D0BY1PR09MB0631namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pete, I believe we discussed several of these issues in the meeting and the early= in-person discussion, but the discussion was never quite focused, so it's = probably easy to miss in the archives. My take of the discussion was that a= simple mechanism that reflects plausible and likely UI approaches was pref= erable to a more complex mechanism. Nothing prevents adding information to = the 'unwanted' status code in the future, should there be a need. As you in= dicate, the Call-Info labeling may well inform such an effort. Yes, the idea was to model the (apparently near-universal) notions of the e= mail spam button. Indeed, early phone UIs that are emerging do seem to take= the same approach, such as the Google Android dialer UI. It offers exactly= one option - swipe up to accept and a red (X) button to block calls like t= hat. The goal was never to create a full-fledged API for rejecting classes of ca= lls or otherwise controlling the behavior of voice spam filters. I don't th= ink that's appropriate for a call response as that would seem to be better = done via a web interface or other API-based configuration option. For examp= le, such web UIs may offer more in-depth options such as "no charities, exc= ept X" or "no surveys except those labeled as high-quality by trusted organ= ization Y". I don't think we are anywhere close to knowing what this should= be. My sense is that, given UI and user patience limitations, no deployed syste= m actually uses the Retry-After header, so all 603's seen in the wild are d= evoid of this indicator. In practice, users will only be willing to spend a limited amount of time o= n feedback for unwanted calls. Analytics will be much better in sorting out= the "annoying ex" from "annoying time share seller" than asking users to f= ill out a survey after the call - the former will be indicated by exactly o= ne person only, the latter by hundreds or thousands. For what it's worth, t= he same potential problems exists in email, but doesn't seem to have caused= any actual problems for spam filters since the statistical signature looks= quite different. Adding parameters to existing status codes can be done, but that seems more= a matter of design taste. After all, we could then dispense with all speci= fic codes and just use 100, 200, 400, 500 and 600, each with headers attach= ed. This has not been the SIP design approach in the past. I don't see the = problem with a new status code - we routinely add them and the mechanism of= handling unknown ones are quite clear. Henning From: Pete Resnick [mailto:presnick@qti.qualcomm.com] Sent: Tuesday, March 21, 2017 11:50 AM To: ietf@ietf.org Cc: draft-ietf-sipcore-status-unwanted@ietf.org; ben@nostrum.com; sipcore@i= etf.org; Adam Roach ; sipcore-chairs@ietf.org Subject: Re: Last Call: (A SIP = Response Code for Unwanted Calls) to Proposed Standard I'm sorry to say that I do not think this mechanism is well thought out, I = think it actually causes active harm to interoperability, and I think this = document should be abandoned for a better (and simpler) solution to the pro= blem, which I describe below. I will note that I have not been following the discussion of this document = except for it's introduction at the last plenary meeting, but I (and others= ) did give comments at that time that as far as I can tell were not taken i= nto account. I did review the thread on the sipcore list regarding the diff= erence between the new code and the 603 code. That thread does not address = my concerns, and in fact in some way reinforces it. I have not reviewed oth= er discussion on the list. The purported purpose of this 666 mechanism is to allow additional semantic= s to be expressed beyond a simple 603 (Decline). That is a fine desire. How= ever, instead of adding decent semantics to declining a call, 666 adds only= one additional bit of information to 603, and that one bit ends up causing= more semantic ambiguity: The user has still declined the call (just as 603= would have), and has added that the call is somehow unwanted (so a provide= r could act to prevent such calls in the future), but the user has not indi= cated the reason they indicate the call is unwanted. Is it because they wan= t to add this calling party to a call block list? Is it that they want to r= eject all calls of this particular class (cf. draft-ietf-sipcore-callinfo-s= pam)? Is there some other handling that would be appropriate given the part= icular reason the user has rejected the call? The best a provider is going = to be able to do is guess. The document admits the ambiguity in the semanti= cs, saying that the provider will have to use heuristics to guess at what t= he user really wants. We should not be introducing a new mechanism that onl= y adds to the semantic ambiguity and might end up with results that the use= r might specifically not want in a particular case. What I think was really= intended all along was to have un-upgraded implementations treat these rej= ections just like 603, but add some semantics that upgraded implementations= can use to determine what ought to be done in the future. The right solution, IMO, is to simply add a header to the 603 response that= indicates what the user means by their declining, and gives a real indicat= ion of how handle such calls in the future. Call it "Decline-Type" for argu= ment sake. Just like the Retry-After header adds semantics to indicate when= the caller might want to try an identical call again, this new header will= indicate that the user never wants a call from this particular caller agai= n (e.g., "Decline-Type: block-caller", which the service provider can defin= itively use to add the caller to a block list), or that this caller and eve= ry caller with a similar type should be rejected (e.g. "Decline-Type: block= -caller-type; type=3Dpolitical", which the provider could definitively use = to reject similar calls in the future), etc.. With this, there's no need fo= r a bunch of MAYs such that appear in section 4, you get an extensible mech= anism that could be used by any 603 response. You also get the added bonus = that un-upgraded entities will continue to treat this just like every other= 603 without a Retry-After header, which is exactly what you want. To be clear, the three things I am concerned about are: 1. The 666 mechanism leaves the decision of what is meant by "unwanted" = to the provider, which will inevitably cause data loss through the use of h= euristics. Adding a header to the 603 response is an extensible mechanism t= hat could capture the single semantic bit of 666 and any future semantics t= hat one wishes to add, without requiring the provider to guess. The provide= r gets definitive information that it can act on. 2. The 666 mechanism limits the implementation of the mechanism to a 1-b= utton choice and requires additional standardization work to use a differen= t UI. Clearly 666 was designed around something akin to a "SPAM" button in = the UI. But what if I want a field in my address book that says, "Permanent= ly block this particular caller" (say, my ex-boyfriend or my annoying neigh= bor)? I don't want to indicate that these are spam calls because I don't wa= nt my provider applying heuristics to them. I want to send back a 603 with = a header that says, "Block these whenever you see them, but only for me." I= can think of all sorts of other-than-one-button UIs that someone might wan= t to implement. 666 is tied to a particular UI. 603 with a header is extens= ible. 3. The 666 mechanism will be treated as a 600 "Busy" error by un-upgrade= d callers and/or providers. That might imply to some implementations that t= hey should try to re-dial (e.g., the provider using the auto-redial feature= ) or to engage in other poor behavior. 603 with no Retry-After header alrea= dy has a semantic of "The call was rejected and I'm not telling you when a = good time to call back is", so there is some hope that an un-upgraded calle= r is more likely to do the right thing. Given the admittedly restricted review of the WG archive that I did, I didn= 't see anything to indicate that the WG fully considered the implications o= f 666 that I have outlined above. This is not simply a design preference; I= believe the design of the proposed mechanism doesn't accomplish the goal a= nd actually does some harm. Overall, 666 damages interoperability by introd= ucing an ambiguous piece of information, which will lead to potential data = loss (i.e., improperly applied heuristics), and will require adding a heade= r in the future in order to accomplish the real goal. Adding a header is a = simple mechanism, accomplishes the desired task, has extensibility, and doe= sn't cause the problems that 666 does. Please reconsider this, drop this do= cument, and replace it by adding real semantics to the 603 response with an= extensible header. It's a quick document to write (a bunch of the text in = the current document can be reused) and it will not suffer the problems tha= t 666 introduces. Otherwise, we're going to be right back where were when w= e started, needing to add a mechanism so that the user can really indicate = what they mean. This is the wrong solution. pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 On 7 Mar 2017, at 18:23, The IESG wrote: The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'A SIP Response Code for Unwanted Calls' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-03-21. Exceptiona= lly, comments may be sent to iesg@ietf.org instead. In either case, please= retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the 666 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ballot/= No IPR declarations have been submitted directly on this I-D. --_000_BY1PR09MB0631F94D0B74E498ECCF3A4DEA3D0BY1PR09MB0631namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pete,

 

I believe we discussed several of the= se issues in the meeting and the early in-person discussion, but the discus= sion was never quite focused, so it’s probably easy to miss in the archives. My take of the discussion was that a simple = mechanism that reflects plausible and likely UI approaches was preferable t= o a more complex mechanism. Nothing prevents adding information to the R= 16;unwanted’ status code in the future, should there be a need. As you indicate, the Call-Info labeling may well i= nform such an effort.

 

Yes, the idea was to model the (appar= ently near-universal) notions of the email spam button. Indeed, early phone= UIs that are emerging do seem to take the same approach, such as the Google Android dialer UI. It offers exactly one opti= on – swipe up to accept and a red (X) button to block calls like that= .

 

The goal was never to create a full-f= ledged API for rejecting classes of calls or otherwise controlling the beha= vior of voice spam filters. I don’t think that’s appropriate for a call response as that would seem to be better done via a= web interface or other API-based configuration option. For example, such w= eb UIs may offer more in-depth options such as “no charities, except = X” or “no surveys except those labeled as high-quality by trusted organization Y”. I don’t think we a= re anywhere close to knowing what this should be.

 

My sense is that, given UI and user p= atience limitations, no deployed system actually uses the Retry-After heade= r, so all 603’s seen in the wild are devoid of this indicator.

 

In practice, users will only be willi= ng to spend a limited amount of time on feedback for unwanted calls. Analyt= ics will be much better in sorting out the “annoying ex” from “annoying time share seller” than asking users = to fill out a survey after the call – the former will be indicated by= exactly one person only, the latter by hundreds or thousands. For what it&= #8217;s worth, the same potential problems exists in email, but doesn’t seem to have caused any actual problems for spam filters sin= ce the statistical signature looks quite different.

 

Adding parameters to existing status = codes can be done, but that seems more a matter of design taste. After all,= we could then dispense with all specific codes and just use 100, 200, 400, 500 and 600, each with headers attached. This = has not been the SIP design approach in the past. I don’t see the pro= blem with a new status code – we routinely add them and the mechanism= of handling unknown ones are quite clear.

 

Henning

 

From: Pete Resnick [mailto:presnick@= qti.qualcomm.com]
Sent: Tuesday, March 21, 2017 11:50 AM
To: ietf@ietf.org
Cc: draft-ietf-sipcore-status-unwanted@ietf.org; ben@nostrum.com; si= pcore@ietf.org; Adam Roach <adam@nostrum.com>; sipcore-chairs@ietf.or= g
Subject: Re: Last Call: <draft-ietf-sipcore-status-unwanted-04.tx= t> (A SIP Response Code for Unwanted Calls) to Proposed Standard

 

I'm sorry to sa= y that I do not think this mechanism is well thought out, I think it actual= ly causes active harm to interoperability, and I think this document should= be abandoned for a better (and simpler) solution to the problem, which I describe below.

I will note tha= t I have not been following the discussion of this document except for it's= introduction at the last plenary meeting, but I (and others) did give comm= ents at that time that as far as I can tell were not taken into account. I did review the thread on the sipcore list r= egarding the difference between the new code and the 603 code. That thread = does not address my concerns, and in fact in some way reinforces it. I have= not reviewed other discussion on the list.

The purported p= urpose of this 666 mechanism is to allow additional semantics to be express= ed beyond a simple 603 (Decline). That is a fine desire. However, instead o= f adding decent semantics to declining a call, 666 adds only one additional bit of information to 603, and that one bit e= nds up causing more semantic ambiguity: The user has still declined the cal= l (just as 603 would have), and has added that the call is somehow= unwanted (so a provider could act to prevent such calls in the future), but the user has not indicate= d the reason<= /em> they indicate the call is unwanted. Is it because they want to add thi= s calling party to a call block list? Is it that they want to reject all ca= lls of this particular class (cf. draft-ietf-sipcore-callinfo-spam)? Is there some other handling that would be appropriate given the particula= r reason the user has rejected the call? The best a provider is going to be= able to do is guess. The document admits the ambiguity in the semantics, s= aying that the provider will have to use heuristics to guess at what the user really wants. We should not be= introducing a new mechanism that only adds to the semantic ambiguity and m= ight end up with results that the user might specifically not want in a par= ticular case. What I think was really intended all along was to have un-upgraded implementations treat these rej= ections just like 603, but add some semantics that upgraded implementations= can use to determine what ought to be done in the future.

The right solut= ion, IMO, is to simply add a header to the 603 response that indicates what= the user means by their declining, and gives a real indication of how hand= le such calls in the future. Call it "Decline-Type" for argument sake. Just like the Retry-After header adds semantics to indi= cate when the caller might want to try an identical call again, this new he= ader will indicate that the user never wants a call from this particular ca= ller again (e.g., "Decline-Type: block-caller", which the service provider can definitively use to add= the caller to a block list), or that this caller and every caller with a s= imilar type should be rejected (e.g. "Decline-Type: block-caller-type;= type=3Dpolitical", which the provider could definitively use to reject similar calls in the future), etc.. With this, = there's no need for a bunch of MAYs such that appear in section 4, you get = an extensible mechanism that could be used by any 603 response. You also ge= t the added bonus that un-upgraded entities will continue to treat this just like every other 603 without a R= etry-After header, which is exactly what you want.

To be clear, th= e three things I am concerned about are:

1.    The 666 mechanism leaves the decision of what is meant by &quo= t;unwanted" to the provider, which will inevitably cause data loss thr= ough the use of heuristics. Adding a header to the 603 response is an extensible mechanism that could capture the single semantic= bit of 666 and any future= semantics that one wishes to add, without requiring the provid= er to guess. The provider gets definitive information that it can act on.

2.    The 666 mechanism limits the implementation of the mechanism t= o a 1-button choice and requires additional standardization work to use a d= ifferent UI. Clearly 666 was designed around something akin to a "SPAM" button in the UI. But what if I want = a field in my address book that says, "Permanently block this particul= ar caller" (say, my ex-boyfriend or my annoying neighbor)? I don't wan= t to indicate that these are spam calls because I don't want my provider applying heuristics to them. I want to send back a 603 wi= th a header that says, "Block these whenever you see them, but only fo= r me." I can think of all sorts of other-than-one-button UIs that some= one might want to implement. 666 is tied to a particular UI. 603 with a header is extensible.

3.    The 666 mechanism will be treated as a 600 "Busy" er= ror by un-upgraded callers and/or providers. That might imply to some imple= mentations that they should try to re-dial (e.g., the provider using the auto-redial feature) or to engage in other poor behavio= r. 603 with no Retry-After header already has a semantic of "The call = was rejected and I'm not telling you when a good time to call back is"= , so there is some hope that an un-upgraded caller is more likely to do the right thing.

Given the admit= tedly restricted review of the WG archive that I did, I didn't see anything= to indicate that the WG fully considered the implications of 666 that I ha= ve outlined above. This is not simply a design preference; I believe the design of the proposed mechanism doesn't accompl= ish the goal and actually does some harm. Overall, 666 damages interoperabi= lity by introducing an ambiguous piece of information, which will lead to p= otential data loss (i.e., improperly applied heuristics), and will require adding a header in the future in ord= er to accomplish the real goal. Adding a header is a simple mechanism, acco= mplishes the desired task, has extensibility, and doesn't cause the problem= s that 666 does. Please reconsider this, drop this document, and replace it by adding real semantics to the 6= 03 response with an extensible header. It's a quick document to write (a bu= nch of the text in the current document can be reused) and it will not suff= er the problems that 666 introduces. Otherwise, we're going to be right back where were when we started, needin= g to add a mechanism so that the user can really indicate what they mean. T= his is the wrong solution.

pr
--
Pete Resnick http://www.qualcomm.com/~presnick/=
Qualcomm Technologies, Inc. - +1 (858)651-4478

On 7 Mar 2017, = at 18:23, The IESG wrote:

T= he IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document:
- 'A SIP Response Code for Unwanted Calls'
<draft-ietf-sipcore-status-unwanted-04.txt> as Proposed Standard=

T= he IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.or= g mailing lists by 2017-03-21. Exceptionally, comments may be sent to iesg= @ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.=

A= bstract

T= his document defines the 666 (Unwanted) SIP response code, allowing
called parties to indicate that the call or message was unwanted.
SIP entities may use this information to adjust how future calls from
this calling party are handled for the called party or more broadly.

T= he file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/

I= ESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwante= d/ballot/

N= o IPR declarations have been submitted directly on this I-D.

--_000_BY1PR09MB0631F94D0B74E498ECCF3A4DEA3D0BY1PR09MB0631namp_-- From nobody Tue Mar 21 09:24:37 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A655129B44; Tue, 21 Mar 2017 09:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SXScKkQScPN; Tue, 21 Mar 2017 09:24:33 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C38129AEE; Tue, 21 Mar 2017 09:24:33 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id n190so96145139pga.0; Tue, 21 Mar 2017 09:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MPg2VpPwONNfp5aXVphyuIc6FqBpUbwA/irI1/OWpVI=; b=kROf5eYipkycsVTIahUCOkEQNI8hKYCJ20MsByJbEHaty56zzoTsrT4IPPoldMVxvW /u/VxqM/Itz6ZvH4utFVOdCpBJKFw5nFXTJWFY5igeRFWvnt46K05OdW9hsm0ZKVUZgR Qrwmy9AWegW68Bl2+wP5gDa9wmuqPkf9zL6D2J/u7RTal4618xQLe0yKDRNqxu72Lfkb dHxI6m6ImHyHzsGnFBefeQja7zjd3aczCdikE0LGp1HyjMD5hPIS4Txh6xuq3XpR1yjZ 914Oc3dFFvxpT35JGRjCgD0lW/Snn5B9ceyqgf0h0skqF4jRiE19ttZzvOX3bLDsmPGm mRUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MPg2VpPwONNfp5aXVphyuIc6FqBpUbwA/irI1/OWpVI=; b=kMDbviHRtizCWrRqaf6ICLvUByprom5EKE044VvAZKo497ACYUfnLCzUWCnp85rNKx bdKRWsVJbpXNrODcxl+u9O5Onbc/H/uRsLOHf3ynTuftbyh5xI7ykXNjTK6HsLt05BB6 xzOkAh5IG9dPGJz6vllN4NT8T5vqlkgKw8qVSNQOaDrae5Ru/mq1vrOHeg1p0Z+HhMnX MenVcVINWK6hgY/1ZHmnH10D5h6pI3asvUNWP6z27z+aD47nMlIqBP0lmQA+i4utkDsF YFxeWMXstWInHRjTyZQRP7pZ4t4JywYd2he3dQMQ76XFBqolhMC7pZpw7OU1NkusY2dy 42UQ== X-Gm-Message-State: AFeK/H1U5qNWL8pLwIR/MMZAT9rzxhWPjaKihnESwt2DmtIVc1Ik3c5WKTlVXg88ehdGZC7PbN1UJGhuFPazvw== X-Received: by 10.98.65.211 with SMTP id g80mr40742763pfd.187.1490113472646; Tue, 21 Mar 2017 09:24:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.166.166 with HTTP; Tue, 21 Mar 2017 09:24:32 -0700 (PDT) In-Reply-To: References: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> From: Ranjit Avasarala Date: Tue, 21 Mar 2017 11:24:32 -0500 Message-ID: To: Pete Resnick Cc: ietf@ietf.org, ben@nostrum.com, sipcore-chairs@ietf.org, SIPCORE , draft-ietf-sipcore-status-unwanted@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0babe0366644054b40142f Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 16:24:36 -0000 --94eb2c0babe0366644054b40142f Content-Type: text/plain; charset=UTF-8 Hi Pete y I quite agree with you. Instead of proposing a new response code like 666, it would be better to add or rather propose a new header and add it to 603 response. Regards Ranjit On Tue, Mar 21, 2017 at 10:49 AM, Pete Resnick wrote: > I'm sorry to say that I do not think this mechanism is well thought out, I > think it actually causes active harm to interoperability, and I think this > document should be abandoned for a better (and simpler) solution to the > problem, which I describe below. > > I will note that I have not been following the discussion of this document > except for it's introduction at the last plenary meeting, but I (and > others) did give comments at that time that as far as I can tell were not > taken into account. I did review the thread on the sipcore list regarding > the difference between the new code and the 603 code. That thread does not > address my concerns, and in fact in some way reinforces it. I have not > reviewed other discussion on the list. > > The purported purpose of this 666 mechanism is to allow additional > semantics to be expressed beyond a simple 603 (Decline). That is a fine > desire. However, instead of adding decent semantics to declining a call, > 666 adds only one additional bit of information to 603, and that one bit > ends up causing more semantic ambiguity: The user has still declined the > call (just as 603 would have), and has added that the call is *somehow* > unwanted (so a provider *could* act to prevent such calls in the future), > but the user has not indicated the *reason* they indicate the call is > unwanted. Is it because they want to add this calling party to a call block > list? Is it that they want to reject all calls of this particular class > (cf. draft-ietf-sipcore-callinfo-spam)? Is there some other handling that > would be appropriate given the particular reason the user has rejected the > call? The best a provider is going to be able to do is guess. The document > admits the ambiguity in the semantics, saying that the provider will have > to use heuristics to guess at what the user really wants. We should not be > introducing a new mechanism that only adds to the semantic ambiguity and > might end up with results that the user might specifically not want in a > particular case. What I think was really intended all along was to have > un-upgraded implementations treat these rejections just like 603, but add > some semantics that upgraded implementations can use to determine what > ought to be done in the future. > > The right solution, IMO, is to simply add a header to the 603 response > that indicates what the user means by their declining, and gives a real > indication of how handle such calls in the future. Call it "Decline-Type" > for argument sake. Just like the Retry-After header adds semantics to > indicate when the caller might want to try an identical call again, this > new header will indicate that the user never wants a call from this > particular caller again (e.g., "Decline-Type: block-caller", which the > service provider can definitively use to add the caller to a block list), > or that this caller and every caller with a similar type should be rejected > (e.g. "Decline-Type: block-caller-type; type=political", which the provider > could definitively use to reject similar calls in the future), etc.. With > this, there's no need for a bunch of MAYs such that appear in section 4, > you get an extensible mechanism that could be used by any 603 response. You > also get the added bonus that un-upgraded entities will continue to treat > this just like every other 603 without a Retry-After header, which is > exactly what you want. > > To be clear, the three things I am concerned about are: > > 1. > > The 666 mechanism leaves the decision of what is meant by "unwanted" > to the provider, which will inevitably cause data loss through the use of > heuristics. Adding a header to the 603 response is an extensible mechanism > that could capture the single semantic bit of 666 *and any future > semantics that one wishes to add*, without requiring the provider to > guess. The provider gets definitive information that it can act on. > 2. > > The 666 mechanism limits the implementation of the mechanism to a > 1-button choice and requires additional standardization work to use a > different UI. Clearly 666 was designed around something akin to a "SPAM" > button in the UI. But what if I want a field in my address book that says, > "Permanently block this particular caller" (say, my ex-boyfriend or my > annoying neighbor)? I don't want to indicate that these are spam calls > because I don't want my provider applying heuristics to them. I want to > send back a 603 with a header that says, "Block these whenever you see > them, but only for me." I can think of all sorts of other-than-one-button > UIs that someone might want to implement. 666 is tied to a particular UI. > 603 with a header is extensible. > 3. > > The 666 mechanism will be treated as a 600 "Busy" error by un-upgraded > callers and/or providers. That might imply to some implementations that > they should try to re-dial (e.g., the provider using the auto-redial > feature) or to engage in other poor behavior. 603 with no Retry-After > header already has a semantic of "The call was rejected and I'm not telling > you when a good time to call back is", so there is some hope that an > un-upgraded caller is more likely to do the right thing. > > Given the admittedly restricted review of the WG archive that I did, I > didn't see anything to indicate that the WG fully considered the > implications of 666 that I have outlined above. This is not simply a design > preference; I believe the design of the proposed mechanism doesn't > accomplish the goal and actually does some harm. Overall, 666 damages > interoperability by introducing an ambiguous piece of information, which > will lead to potential data loss (i.e., improperly applied heuristics), and > will require adding a header in the future in order to accomplish the real > goal. Adding a header is a simple mechanism, accomplishes the desired task, > has extensibility, and doesn't cause the problems that 666 does. Please > reconsider this, drop this document, and replace it by adding real > semantics to the 603 response with an extensible header. It's a quick > document to write (a bunch of the text in the current document can be > reused) and it will not suffer the problems that 666 introduces. Otherwise, > we're going to be right back where were when we started, needing to add a > mechanism so that the user can really indicate what they mean. This is the > wrong solution. > > pr > -- > Pete Resnick http://www.qualcomm.com/~presnick/ > Qualcomm Technologies, Inc. - +1 (858)651-4478 <(858)%20651-4478> > > On 7 Mar 2017, at 18:23, The IESG wrote: > > The IESG has received a request from the Session Initiation Protocol Core > WG (sipcore) to consider the following document: > - 'A SIP Response Code for Unwanted Calls' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2017-03-21. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > This document defines the 666 (Unwanted) SIP response code, allowing > called parties to indicate that the call or message was unwanted. > SIP entities may use this information to adjust how future calls from > this calling party are handled for the called party or more broadly. > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-sipcore-status- > unwanted/ballot/ > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --94eb2c0babe0366644054b40142f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Pete
y
I quite agree with you.=C2=A0 Inst= ead of proposing a new response code like 666, it would be better to add or= rather propose a new header and add it to 603 response. =C2=A0
<= br>
Regards
Ranjit


On Tue, Mar 21, 2017 at 10:= 49 AM, Pete Resnick <presnick@qti.qualcomm.com> wrot= e:

I'm sorry to say that I do not think this mechanism is = well thought out, I think it actually causes active harm to interoperabilit= y, and I think this document should be abandoned for a better (and simpler)= solution to the problem, which I describe below.

I will note that I have not been following the discussion o= f this document except for it's introduction at the last plenary meetin= g, but I (and others) did give comments at that time that as far as I can t= ell were not taken into account. I did review the thread on the sipcore lis= t regarding the difference between the new code and the 603 code. That thre= ad does not address my concerns, and in fact in some way reinforces it. I h= ave not reviewed other discussion on the list.

The purported purpose of this 666 mechanism is to allow add= itional semantics to be expressed beyond a simple 603 (Decline). That is a = fine desire. However, instead of adding decent semantics to declining a cal= l, 666 adds only one additional bit of information to 603, and that one bit= ends up causing more semantic ambiguity: The user has still declined the c= all (just as 603 would have), and has added that the call is somehow unwanted (so a provider could act to prevent such calls in the = future), but the user has not indicated the reason they indicate t= he call is unwanted. Is it because they want to add this calling party to a= call block list? Is it that they want to reject all calls of this particul= ar class (cf. draft-ietf-sipcore-callinfo-spam)? Is there some other h= andling that would be appropriate given the particular reason the user has = rejected the call? The best a provider is going to be able to do is guess. = The document admits the ambiguity in the semantics, saying that the provide= r will have to use heuristics to guess at what the user really wants. We sh= ould not be introducing a new mechanism that only adds to the semantic ambi= guity and might end up with results that the user might specifically not wa= nt in a particular case. What I think was really intended all along was to = have un-upgraded implementations treat these rejections just like 603, but = add some semantics that upgraded implementations can use to determine what = ought to be done in the future.

The right solution, IMO, is to simply add a header to the 6= 03 response that indicates what the user means by their declining, and give= s a real indication of how handle such calls in the future. Call it "D= ecline-Type" for argument sake. Just like the Retry-After header adds = semantics to indicate when the caller might want to try an identical call a= gain, this new header will indicate that the user never wants a call from t= his particular caller again (e.g., "Decline-Type: block-caller", = which the service provider can definitively use to add the caller to a bloc= k list), or that this caller and every caller with a similar type should be= rejected (e.g. "Decline-Type: block-caller-type; type=3Dpolitical&quo= t;, which the provider could definitively use to reject similar calls in th= e future), etc.. With this, there's no need for a bunch of MAYs such th= at appear in section 4, you get an extensible mechanism that could be used = by any 603 response. You also get the added bonus that un-upgraded entities= will continue to treat this just like every other 603 without a Retry-Afte= r header, which is exactly what you want.

To be clear, the three things I am concerned about are:

  1. The 666 mechanism leaves the decision of wh= at is meant by "unwanted" to the provider, which will inevitably = cause data loss through the use of heuristics. Adding a header to the 603 r= esponse is an extensible mechanism that could capture the single semantic b= it of 666 and any future semantics that one wishes to add, without= requiring the provider to guess. The provider gets definitive information = that it can act on.

  2. The 666 mechanism limits the implementation= of the mechanism to a 1-button choice and requires additional standardizat= ion work to use a different UI. Clearly 666 was designed around something a= kin to a "SPAM" button in the UI. But what if I want a field in m= y address book that says, "Permanently block this particular caller&qu= ot; (say, my ex-boyfriend or my annoying neighbor)? I don't want to ind= icate that these are spam calls because I don't want my provider applyi= ng heuristics to them. I want to send back a 603 with a header that says, &= quot;Block these whenever you see them, but only for me." I can think = of all sorts of other-than-one-button UIs that someone might want to implem= ent. 666 is tied to a particular UI. 603 with a header is extensible.

  3. The 666 mechanism will be treated as a 600 = "Busy" error by un-upgraded callers and/or providers. That might = imply to some implementations that they should try to re-dial (e.g., the pr= ovider using the auto-redial feature) or to engage in other poor behavior. = 603 with no Retry-After header already has a semantic of "The call was= rejected and I'm not telling you when a good time to call back is"= ;, so there is some hope that an un-upgraded caller is more likely to do th= e right thing.

Given the admittedly restricted review of the WG archive th= at I did, I didn't see anything to indicate that the WG fully considere= d the implications of 666 that I have outlined above. This is not simply a = design preference; I believe the design of the proposed mechanism doesn'= ;t accomplish the goal and actually does some harm. Overall, 666 damages in= teroperability by introducing an ambiguous piece of information, which will= lead to potential data loss (i.e., improperly applied heuristics), and wil= l require adding a header in the future in order to accomplish the real goa= l. Adding a header is a simple mechanism, accomplishes the desired task, ha= s extensibility, and doesn't cause the problems that 666 does. Please r= econsider this, drop this document, and replace it by adding real semantics= to the 603 response with an extensible header. It's a quick document t= o write (a bunch of the text in the current document can be reused) and it = will not suffer the problems that 666 introduces. Otherwise, we're goin= g to be right back where were when we started, needing to add a mechanism s= o that the user can really indicate what they mean. This is the wrong solut= ion.

pr
--
Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478

On 7 Mar 2017, at 18:23, The IESG wrote:

The IESG has received a request from the Session Initiation= Protocol Core
WG (sipcore) to consider the following document:
- 'A SIP Response Code for Unwanted Calls'
<draft-ietf-sipcore-status-unwanted-04.txt> as Proposed Standa= rd

The IESG plans to make a decision in the next few weeks, an= d solicits
final comments on this action. Please send substantive comments to the
iet= f@ietf.org mailing lists by 2017-03-21. Exceptionally, comments may be<= br> sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

This document defines the 666 (Unwanted) SIP response code,= allowing
called parties to indicate that the call or message was unwanted.
SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.

The file can be obtained via
https://datatracker.ietf.org/<= wbr>doc/draft-ietf-sipcore-status-unwanted/

IESG discussion can be tracked via
https://datatracker.iet= f.org/doc/draft-ietf-sipcore-status-unwanted/ballot/

No IPR declarations have been submitted directly on this I-= D.


_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore<= br>

--94eb2c0babe0366644054b40142f-- From nobody Tue Mar 21 09:52:12 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F93129C04; Tue, 21 Mar 2017 09:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.021 X-Spam-Level: X-Spam-Status: No, score=-7.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65RoKLSLE9Nd; Tue, 21 Mar 2017 09:52:07 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AAE8129C06; Tue, 21 Mar 2017 09:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1490115106; x=1521651106; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=60YZ6R8AXRqUNtD1v8/K/pk4ClW+mDESFp+CYUyptS0=; b=DuEBxut/13X0qt0jXUUzGwvSiHbseULyu4tkvb/I9HkF6utFMoiqyJkb e4nXloOXkph8wvOgTwNOximRLj2e4Mbjw/cmT9xNGfORC948s5Z4rUEOx 77SkEzsLdwAUqeI7gTTruYhdRfxWPaQj8Bh6jqIROICJhcJf6Oa3aIBd7 w=; X-IronPort-AV: E=Sophos;i="5.36,200,1486454400"; d="scan'208";a="271792141" Received: from unknown (HELO Ironmsg04-L.qualcomm.com) ([10.53.140.111]) by wolverine01.qualcomm.com with ESMTP; 21 Mar 2017 09:51:45 -0700 X-IronPort-AV: E=McAfee;i="5800,7501,8474"; a="1313103308" X-MGA-submission: =?us-ascii?q?MDHb44LJFXKNOubnsvcd/dTKGwNS1+NITaeTwi?= =?us-ascii?q?XIQo9TtH6TWVaFs9YDkY2TM5eodFtr51//hw7VsM5wMlaGAniKUI3EmE?= =?us-ascii?q?mI8TPilNHUX6Gvigo/6JQHvfZdsCLKpzQ68nZ0RlqwHaRzbcSb78J3jZ?= =?us-ascii?q?R5?= Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Mar 2017 09:51:45 -0700 Received: from [10.64.124.243] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 21 Mar 2017 09:51:44 -0700 From: Pete Resnick To: Henning Schulzrinne CC: "ietf@ietf.org" , "draft-ietf-sipcore-status-unwanted@ietf.org" , "sipcore@ietf.org" Date: Tue, 21 Mar 2017 11:51:42 -0500 Message-ID: <8443007A-60F0-4AB6-80EC-DD20368D61EA@qti.qualcomm.com> In-Reply-To: References: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 16:52:10 -0000 Just replying to the points in your message (trimming as I go along): On 21 Mar 2017, at 11:17, Henning Schulzrinne wrote: > My take of the discussion was that a simple mechanism that reflects > plausible and likely UI approaches was preferable to a more complex > mechanism. First, there is nothing complex about adding a header that says, "Decline-Type: spam" to 603. It is extremely simple, accomplishes exactly the same result, reflects the one envisioned plausible and likely UI, and has the added advantage of extensibility. > Nothing prevents adding information to the 'unwanted' status code in > the future, should there be a need. As you indicate, the Call-Info > labeling may well inform such an effort. The problem there is that you then will have two different ways of expressing "spam", adding yet more ambiguity. It means that the implementer has to know whether they're talking to a 666 implementation that does or does not know about the additional parameter to understand what the behavior will be. We've constantly faced this problem in IMAP over the years and it's made for horrible implementations. Better to do the simple thing first and not end up with two incompatible ways to do the same thing in the future. > Yes, the idea was to model the (apparently near-universal) notions of > the email spam button. Simply achievable with 603 and "Decline-Type: spam". The only additional complexity is to create the IANA registry for future decline types. I'm only suggesting this document defining the one right now. > The goal was never to create a full-fledged API for rejecting classes > of calls or otherwise controlling the behavior of voice spam filters. Nor am I proposing such an API. Sure, pieces of this (and Call-Info labeling) might be useful for such a thing later, but I have no interest in such a thing now. > In practice, users will only be willing to spend a limited amount of > time on feedback for unwanted calls. Again, the mechanism I propose does not add to that limited time. It functions, in that scenario, exactly like 666. The difference is only in extensibility (and avoids the potential pitfalls I mentioned earlier). > Adding parameters to existing status codes can be done, but that seems > more a matter of design taste. As I said quite clearly, it's not a design matter. Using a separate status code to mean "decline, with additional semantics" has side effects, because you already have a status code for decline. Please re-read my explanation. > After all, we could then dispense with all specific codes and just use > 100, 200, 400, 500 and 600, each with headers attached. No, that absolutely does not follow. A layered approach of status codes for broader semantic values and headers for specialized processing works incredibly well. The problem arises when you introduce a status code that does not give the basic processing engine enough information to go on. What you want in this case is to have the default behavior be "decline", as per the status code, and then have some side processing to figure out whether to deposit information into a spam analysis engine, or hand it off to some other process that does different sorts of things, based on the additional semantic information in the header. That's a good division of labor. > I don't see the problem with a new status code - we routinely add them > and the mechanism of handling unknown ones are quite clear. Please see my earlier comments on this particular status code: It increases semantic ambiguity, it increases the possibility for data loss, and it limits future extensibility. Again, it's not clear that you've fully understood and considered what I wrote. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Mar 21 09:59:41 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C957D127201; Tue, 21 Mar 2017 09:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTL0lAzEhr68; Tue, 21 Mar 2017 09:59:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09BB312708C; Tue, 21 Mar 2017 09:59:30 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v2LGxTTL063091 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 21 Mar 2017 11:59:30 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Pete Resnick , ietf@ietf.org References: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> Cc: draft-ietf-sipcore-status-unwanted@ietf.org, ben@nostrum.com, sipcore@ietf.org, sipcore-chairs@ietf.org From: Adam Roach Message-ID: <534047ad-8971-88ec-3d16-254c766bbfa3@nostrum.com> Date: Tue, 21 Mar 2017 11:59:23 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D0FB48B24F913B613ECBEA3B" Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 16:59:34 -0000 This is a multi-part message in MIME format. --------------D0FB48B24F913B613ECBEA3B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 3/21/17 10:49, Pete Resnick wrote: > > 1. > > The 666 mechanism leaves the decision of what is meant by > "unwanted" to the provider, which will inevitably cause data loss > through the use of heuristics. Adding a header to the 603 response > is an extensible mechanism that could capture the single semantic > bit of 666 /and any future semantics that one wishes to add/, > without requiring the provider to guess. The provider gets > definitive information that it can act on. > The problem is that the semantics of 666 are backwards from the semantics of 603. 603 means "there is an issue with the disposition of the *called* party that prevents completing the call." 666 means "there is an issue with the disposition of the *calling* party that prevents completing the call." You're proposing conflating the two semantics, which necessarily introduces more ambiguity, not less. Carrier determination of how to handle these codes is, as with any nuisance communication mitigation, going to necessarily be based on heuristics to avoid accidental blacklisting, intentional blowback, and the inevitable gaming of the system by bad actors. You imply that the application of heuristics is an unwanted side effect of the system, when it in fact the primary goal. In terms of being able to provide gradation between types of unwanted calls, the application of a header -- as you propose -- to provide such indication seems like a fine idea. I will point out one caveat and make one observation. The caveat is that it would be harmful to add this header in a way that reverses the sense of a response code, such as making 603 bear on the calling party rather than the called party; so such an indication would need to be on a new response code, such as the one currently proposed in draft-ietf-sipcore-status-unwanted. The observation is that this mechanism can be added to this new status at a later date, in a modular fashion and in a backwards compatible way. In other words: your proposed enhancement is *nice*, but it does not preclude publishing the mechanism currently described. > 2. > > The 666 mechanism limits the implementation of the mechanism to a > 1-button choice and requires additional standardization work to > use a different UI. Clearly 666 was designed around something akin > to a "SPAM" button in the UI. But what if I want a field in my > address book that says, "Permanently block this particular caller" > (say, my ex-boyfriend or my annoying neighbor)? I don't want to > indicate that these are spam calls because I don't want my > provider applying heuristics to them. I want to send back a 603 > with a header that says, "Block these whenever you see them, but > only for me." I can think of all sorts of other-than-one-button > UIs that someone might want to implement. 666 is tied to a > particular UI. 603 with a header is extensible. > That kind of persistent, hard-state user account configuration *really* isn't a reasonable kind of thing to do with a SIP status code (not least of all because you would need some mechanism for reviewing and managing such a list; and whatever that mechanism is could just as readily be used for adding entries). If you feel the need to pursue the somewhat related problem space of a network-assisted blocklist, we have a variety of tools we could bring to bear, such as XCAP. That's a separable problem, though, and I think that tangling it up with spam mitigation is a huge mistake. I'll also point out that devices are perfectly capable of handling this feature locally without any assistance from the network, so I'm not sure how much value would be added by defining a network-hosted version of the service. The overarching point, though, is that a SIP response code is absolutely the wrong approach for doing so. > 3. > > The 666 mechanism will be treated as a 600 "Busy" error by > un-upgraded callers and/or providers. That might imply to some > implementations that they should try to re-dial (e.g., the > provider using the auto-redial feature) or to engage in other poor > behavior. 603 with no Retry-After header already has a semantic of > "The call was rejected and I'm not telling you when a good time to > call back is", so there is some hope that an un-upgraded caller is > more likely to do the right thing. > This is really reaching, and I think is based on a misperception of how SIP clients actually work when they receive 6xx responses. Taken to its logical conclusion, if we accept your assertion then we can't ever define a new 6xx-class SIP response code for fear that such codes "might imply to some implementations that they should try to re-dial (e.g., the provider using the auto-redial feature) or to engage in other poor behavior." /a --------------D0FB48B24F913B613ECBEA3B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 3/21/17 10:49, Pete Resnick wrote:

  1. The 666 mechanism leaves the decision of what is meant by "unwanted" to the provider, which will inevitably cause data loss through the use of heuristics. Adding a header to the 603 response is an extensible mechanism that could capture the single semantic bit of 666 and any future semantics that one wishes to add, without requiring the provider to guess. The provider gets definitive information that it can act on.


The problem is that the semantics of 666 are backwards from the semantics of 603.

603 means "there is an issue with the disposition of the *called* party that prevents completing the call."

666 means "there is an issue with the disposition of the *calling* party that prevents completing the call."

You're proposing conflating the two semantics, which necessarily introduces more ambiguity, not less.

Carrier determination of how to handle these codes is, as with any nuisance communication mitigation, going to necessarily be based on heuristics to avoid accidental blacklisting, intentional blowback, and the inevitable gaming of the system by bad actors. You imply that the application of heuristics is an unwanted side effect of the system, when it in fact the primary goal.

In terms of being able to provide gradation between types of unwanted calls, the application of a header -- as you propose -- to provide such indication seems like a fine idea. I will point out one caveat and make one observation. The caveat is that it would be harmful to add this header in a way that reverses the sense of a response code, such as making 603 bear on the calling party rather than the called party; so such an indication would need to be on a new response code, such as the one currently proposed in draft-ietf-sipcore-status-unwanted. The observation is that this mechanism can be added to this new status at a later date, in a modular fashion and in a backwards compatible way. In other words: your proposed enhancement is *nice*, but it does not preclude publishing the mechanism currently described.

  1. The 666 mechanism limits the implementation of the mechanism to a 1-button choice and requires additional standardization work to use a different UI. Clearly 666 was designed around something akin to a "SPAM" button in the UI. But what if I want a field in my address book that says, "Permanently block this particular caller" (say, my ex-boyfriend or my annoying neighbor)? I don't want to indicate that these are spam calls because I don't want my provider applying heuristics to them. I want to send back a 603 with a header that says, "Block these whenever you see them, but only for me." I can think of all sorts of other-than-one-button UIs that someone might want to implement. 666 is tied to a particular UI. 603 with a header is extensible.


That kind of persistent, hard-state user account configuration *really* isn't a reasonable kind of thing to do with a SIP status code (not least of all because you would need some mechanism for reviewing and managing such a list; and whatever that mechanism is could just as readily be used for adding entries). If you feel the need to pursue the somewhat related problem space of a network-assisted blocklist, we have a variety of tools we could bring to bear, such as XCAP. That's a separable problem, though, and I think that tangling it up with spam mitigation is a huge mistake.

I'll also point out that devices are perfectly capable of handling this feature locally without any assistance from the network, so I'm not sure how much value would be added by defining a network-hosted version of the service. The overarching point, though, is that a SIP response code is absolutely the wrong approach for doing so.

  1. The 666 mechanism will be treated as a 600 "Busy" error by un-upgraded callers and/or providers. That might imply to some implementations that they should try to re-dial (e.g., the provider using the auto-redial feature) or to engage in other poor behavior. 603 with no Retry-After header already has a semantic of "The call was rejected and I'm not telling you when a good time to call back is", so there is some hope that an un-upgraded caller is more likely to do the right thing.


This is really reaching, and I think is based on a misperception of how SIP clients actually work when they receive 6xx responses. Taken to its logical conclusion, if we accept your assertion then we can't ever define a new 6xx-class SIP response code for fear that such codes "might imply to some implementations that they should try to re-dial (e.g., the provider using the auto-redial feature) or to engage in other poor behavior."


/a

--------------D0FB48B24F913B613ECBEA3B-- From nobody Tue Mar 21 10:06:03 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589CF129BE8; Tue, 21 Mar 2017 10:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7BVY5XW_2hY; Tue, 21 Mar 2017 10:05:53 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35009129BEE; Tue, 21 Mar 2017 10:05:52 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id l37so116142083wrc.1; Tue, 21 Mar 2017 10:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ub7QC53Wt5L8CoDE2nbSKHCRs/uUl26anHfKfRX2dd4=; b=dyj10meKR/92v7Lgi9w/NnlzkoftL0bhfXyfpoGGuCTbLN8Lh1io7cZ3HlL3vwhDvO JquOoRRFsFSa6OYPut1UwNXp3tHsCKKWjZ2lWDk2hEt5s0T7Tt6wokeRWhffUj13tdv2 SCYk0FOGnfJjd7IpEBX/pcmdQ2Ca6PSBIfj0lgr1QJlCqDKC+Gt5Z/4EX6IqgkkeYNJA jm3S0YvbzQgwOhzps1w3AJmPAKHlgbKBrEEWpYALRJUM2gzUc/7PnTqcYUl0KCm9cxPc IxsmSIhY4SDQRF51n1p0nk5S3cBNaAJROlPA/T3JSKUbSz6FynOU2MePFDj40fHMbe2X taZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ub7QC53Wt5L8CoDE2nbSKHCRs/uUl26anHfKfRX2dd4=; b=B4lqHxg2imYFWHXmaIL7t1W3nsxx8oJx/gKD02g06pP8fbC5qqSiwF8IjxitM0Rn9/ DF8cLQBnMdFWWBh9HN7sUEEj9N9UJTNmLcUzJQniT4XznqHoz/cxEIc0hcXBVIVAlGZW LJ9sUOmtrA7VNIJrMT5BkMsAdbwkyHfeSMJY9U/toFWBSIhtrxNppyuEOJFKOHspMIA/ McFDuEIftpHvpjFFF65QzjMhOYDt97mIPZguwSUJlaq4APwtsNr3XgWVvDxgbNXCyynh lcd+jBAm/79zB0LGBklLsykt4EQPQi2QootW8TpLcl8TlQHqMhlayqLbcOYvSB5nKtY5 W4iA== X-Gm-Message-State: AFeK/H2dvkr43rHqbdwlGQ1C/5z2Kq8cQ8+9Br+SlwvqcikGeRaK+I/XdeW0iPHbKlCz7ClN1PtO4YyWtZbNZg== X-Received: by 10.223.153.168 with SMTP id y37mr30756346wrb.193.1490115950608; Tue, 21 Mar 2017 10:05:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.177.146 with HTTP; Tue, 21 Mar 2017 10:05:49 -0700 (PDT) In-Reply-To: <8443007A-60F0-4AB6-80EC-DD20368D61EA@qti.qualcomm.com> References: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> <8443007A-60F0-4AB6-80EC-DD20368D61EA@qti.qualcomm.com> From: Alan Johnston Date: Tue, 21 Mar 2017 10:05:49 -0700 Message-ID: To: Pete Resnick Cc: Henning Schulzrinne , "sipcore@ietf.org" , "ietf@ietf.org" , "draft-ietf-sipcore-status-unwanted@ietf.org" Content-Type: multipart/alternative; boundary=f403045f546ee907b2054b40a767 Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 17:05:56 -0000 --f403045f546ee907b2054b40a767 Content-Type: text/plain; charset=UTF-8 Pete, Joining this conversation late - apologies if it has already been discussed. If you are proposing using a SIP response code 603 and with a header field Decline-Type: spam, the problem with this is that in SIP, failure responses (non-2xx) are delivered hop-by-hop and not end-to-end. This means that although the first hop (proxy) will get the Decline-Type:spam header field, any future hops will not. Instead, they will just get the 603. A different response code such as 666 will be conveyed end-to-end, so every proxy and the calling UA will get the semantics. - Alan - On Tue, Mar 21, 2017 at 9:51 AM, Pete Resnick wrote: > Just replying to the points in your message (trimming as I go along): > > On 21 Mar 2017, at 11:17, Henning Schulzrinne wrote: > > My take of the discussion was that a simple mechanism that reflects >> plausible and likely UI approaches was preferable to a more complex >> mechanism. >> > > First, there is nothing complex about adding a header that says, > "Decline-Type: spam" to 603. It is extremely simple, accomplishes exactly > the same result, reflects the one envisioned plausible and likely UI, and > has the added advantage of extensibility. > > Nothing prevents adding information to the 'unwanted' status code in the >> future, should there be a need. As you indicate, the Call-Info labeling may >> well inform such an effort. >> > > The problem there is that you then will have two different ways of > expressing "spam", adding yet more ambiguity. It means that the implementer > has to know whether they're talking to a 666 implementation that does or > does not know about the additional parameter to understand what the > behavior will be. We've constantly faced this problem in IMAP over the > years and it's made for horrible implementations. > > Better to do the simple thing first and not end up with two incompatible > ways to do the same thing in the future. > > Yes, the idea was to model the (apparently near-universal) notions of the >> email spam button. >> > > Simply achievable with 603 and "Decline-Type: spam". The only additional > complexity is to create the IANA registry for future decline types. I'm > only suggesting this document defining the one right now. > > The goal was never to create a full-fledged API for rejecting classes of >> calls or otherwise controlling the behavior of voice spam filters. >> > > Nor am I proposing such an API. Sure, pieces of this (and Call-Info > labeling) might be useful for such a thing later, but I have no interest in > such a thing now. > > In practice, users will only be willing to spend a limited amount of time >> on feedback for unwanted calls. >> > > Again, the mechanism I propose does not add to that limited time. It > functions, in that scenario, exactly like 666. The difference is only in > extensibility (and avoids the potential pitfalls I mentioned earlier). > > Adding parameters to existing status codes can be done, but that seems >> more a matter of design taste. >> > > As I said quite clearly, it's not a design matter. Using a separate status > code to mean "decline, with additional semantics" has side effects, because > you already have a status code for decline. Please re-read my explanation. > > After all, we could then dispense with all specific codes and just use >> 100, 200, 400, 500 and 600, each with headers attached. >> > > No, that absolutely does not follow. A layered approach of status codes > for broader semantic values and headers for specialized processing works > incredibly well. The problem arises when you introduce a status code that > does not give the basic processing engine enough information to go on. > > What you want in this case is to have the default behavior be "decline", > as per the status code, and then have some side processing to figure out > whether to deposit information into a spam analysis engine, or hand it off > to some other process that does different sorts of things, based on the > additional semantic information in the header. That's a good division of > labor. > > I don't see the problem with a new status code - we routinely add them and >> the mechanism of handling unknown ones are quite clear. >> > > Please see my earlier comments on this particular status code: It > increases semantic ambiguity, it increases the possibility for data loss, > and it limits future extensibility. > > Again, it's not clear that you've fully understood and considered what I > wrote. > > pr > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --f403045f546ee907b2054b40a767 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pete,

Joining this conversation late - = apologies if it has already been discussed.

If you= are proposing using a SIP response code=C2=A0=C2=A0603 and with a header fie= ld Decline-Type: spam, the problem with this is that in SIP, failure respon= ses (non-2xx) are delivered hop-by-hop and not end-to-end.=C2=A0 This means= that although the first hop (proxy) will get the Decline-Type:spam header = field, any future hops will not.=C2=A0 Instead, they will just get the 603.=

A different response code such as 666 will b= e conveyed end-to-end, so every proxy and the calling UA will get the seman= tics.

- Alan -

On Tue, Mar 21, 2017 at 9:5= 1 AM, Pete Resnick <presnick@qti.qualcomm.com> wrote= :
Just replying to the points in your mes= sage (trimming as I go along):

On 21 Mar 2017, at 11:17, Henning Schulzrinne wrote:

My take of the discussion was that a simple mechanism that reflects plausib= le and likely UI approaches was preferable to a more complex mechanism.

First, there is nothing complex about adding a header that says, "Decl= ine-Type: spam" to 603. It is extremely simple, accomplishes exactly t= he same result, reflects the one envisioned plausible and likely UI, and ha= s the added advantage of extensibility.

Nothing prevents adding information to the 'unwanted' status code i= n the future, should there be a need. As you indicate, the Call-Info labeli= ng may well inform such an effort.

The problem there is that you then will have two different ways of expressi= ng "spam", adding yet more ambiguity. It means that the implement= er has to know whether they're talking to a 666 implementation that doe= s or does not know about the additional parameter to understand what the be= havior will be. We've constantly faced this problem in IMAP over the ye= ars and it's made for horrible implementations.

Better to do the simple thing first and not end up with two incompatible wa= ys to do the same thing in the future.

Yes, the idea was to model the (apparently near-universal) notions of the e= mail spam button.

Simply achievable with 603 and "Decline-Type: spam". The only add= itional complexity is to create the IANA registry for future decline types.= I'm only suggesting this document defining the one right now.

The goal was never to create a full-fledged API for rejecting classes of ca= lls or otherwise controlling the behavior of voice spam filters.

Nor am I proposing such an API. Sure, pieces of this (and Call-Info labelin= g) might be useful for such a thing later, but I have no interest in such a= thing now.

In practice, users will only be willing to spend a limited amount of time o= n feedback for unwanted calls.

Again, the mechanism I propose does not add to that limited time. It functi= ons, in that scenario, exactly like 666. The difference is only in extensib= ility (and avoids the potential pitfalls I mentioned earlier).

Adding parameters to existing status codes can be done, but that seems more= a matter of design taste.

As I said quite clearly, it's not a design matter. Using a separate sta= tus code to mean "decline, with additional semantics" has side ef= fects, because you already have a status code for decline. Please re-read m= y explanation.

After all, we could then dispense with all specific codes and just use 100,= 200, 400, 500 and 600, each with headers attached.

No, that absolutely does not follow. A layered approach of status codes for= broader semantic values and headers for specialized processing works incre= dibly well. The problem arises when you introduce a status code that does n= ot give the basic processing engine enough information to go on.

What you want in this case is to have the default behavior be "decline= ", as per the status code, and then have some side processing to figur= e out whether to deposit information into a spam analysis engine, or hand i= t off to some other process that does different sorts of things, based on t= he additional semantic information in the header. That's a good divisio= n of labor.

I don't see the problem with a new status code - we routinely add them = and the mechanism of handling unknown ones are quite clear.

Please see my earlier comments on this particular status code: It increases= semantic ambiguity, it increases the possibility for data loss, and it lim= its future extensibility.

Again, it's not clear that you've fully understood and considered w= hat I wrote.

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore<= br>

--f403045f546ee907b2054b40a767-- From nobody Tue Mar 21 10:14:17 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F99129B77; Tue, 21 Mar 2017 10:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.021 X-Spam-Level: X-Spam-Status: No, score=-7.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRz5tiLLfDu6; Tue, 21 Mar 2017 10:14:13 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3963E127A91; Tue, 21 Mar 2017 10:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1490116453; x=1521652453; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=VkTHXixnoPd0BsX4WO0cK84qBGMN3fNK0KDGUFbicPY=; b=ugCODPSTJVAekgVA2uJE25RPYdgMnlpfSdZbtzQXbB/v+pEQbVuDCHQr S5Q93kQXb0KzTsxnRna35EKu2nppbbeG+zeEMq06XCvgi+mceFb3Ocr8R 80Tr+DBQtHA1W5fBw+oiC2SOVsPj8KY7ssLl1liHAsgRdTtnfblf7fbf3 Y=; X-IronPort-AV: E=Sophos;i="5.36,200,1486454400"; d="scan'208";a="271794905" Received: from unknown (HELO Ironmsg03-R.qualcomm.com) ([10.53.140.107]) by wolverine01.qualcomm.com with ESMTP; 21 Mar 2017 10:14:12 -0700 X-IronPort-AV: E=McAfee;i="5800,7501,8474"; a="1331864765" X-MGA-submission: =?us-ascii?q?MDH8TuiKXuK3ojrZjclgI+0ag5l4C+ltcldzol?= =?us-ascii?q?2ICO/Tq2i+f/a7OUfktp/OB7WzdSjIhE+cYBfK35gyr4vxNuHl3jKSaE?= =?us-ascii?q?KWhben1C5D4E5JCfa4ydj6UDuThpzD5+3AMrwYNNzmKZRURlX90rLfsm?= =?us-ascii?q?70?= Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Mar 2017 10:14:12 -0700 Received: from [10.64.124.243] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 21 Mar 2017 10:14:11 -0700 From: Pete Resnick To: Adam Roach CC: , , , , Date: Tue, 21 Mar 2017 12:14:10 -0500 Message-ID: <13DC441F-FFC0-4E00-8CB4-4DBBF8423420@qti.qualcomm.com> In-Reply-To: <534047ad-8971-88ec-3d16-254c766bbfa3@nostrum.com> References: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> <534047ad-8971-88ec-3d16-254c766bbfa3@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.85.0.33) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 17:14:15 -0000 Just on a couple of small points: On 21 Mar 2017, at 11:59, Adam Roach wrote: > The problem is that the semantics of 666 are backwards from the > semantics of 603. > > 603 means "there is an issue with the disposition of the *called* > party that prevents completing the call." That's not how 603 is described in 3261. It can be used to express that "the user explicitly does not wish to ... participate." Whether that's based on being in the shower or not liking the number in the caller id or something else, it expresses the called party's decision not to take the call. > 666 means "there is an issue with the disposition of the *calling* > party that prevents completing the call." That's not how the mechanism is described in this document. It is not that you send back 666 when the system determines something about the calling party; you send back 666 when the called party says something (in this case "SPAM!") that indicates that the called party declined the call. I disagree that the semantics are different. > ...I think is based on a misperception of how SIP clients actually > work when they receive 6xx responses. I think this is a fair criticism insofar as I agree that either 666 or a header on 603 will work equally in today's usage scenarios. My only response is that I have rosy glasses looking to future advances that might make us regret having painted ourselves into a corner. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Mar 21 10:41:26 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6FB129A39 for ; Tue, 21 Mar 2017 10:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Df_5Vdh8NzYC for ; Tue, 21 Mar 2017 10:41:21 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [63.128.21.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB656129542 for ; Tue, 21 Mar 2017 10:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LRHDBykAdGHU7XPnVHFVHUDeLM5cInBQ1P5xb1h4wp0=; b=vP0x96G9an8yzbohmhYViJQ6+0YYC1Vu+4XMdxwbNptxjyRd6iTbxAzNbfl21hNoS6cQ/OdgoUCTz87n0947mWLpjl06SgNRDtgGkzWZUSrEjHkMfxmMHxTSK3WhYbJuH4ZObGKepbAC4EHgRn9M3/Jl3C/OO7maCcENJE72P5k= Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0087.outbound.protection.outlook.com [207.46.163.87]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-154-tcSZ-m-fP0qe7YYRJUmlRA-1; Tue, 21 Mar 2017 13:41:16 -0400 Received: from CY1PR03MB2348.namprd03.prod.outlook.com (10.166.207.147) by CY1PR03MB2346.namprd03.prod.outlook.com (10.166.207.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 21 Mar 2017 17:41:14 +0000 Received: from CY1PR03MB2348.namprd03.prod.outlook.com ([10.166.207.147]) by CY1PR03MB2348.namprd03.prod.outlook.com ([10.166.207.147]) with mapi id 15.01.0947.020; Tue, 21 Mar 2017 17:41:14 +0000 From: "Asveren, Tolga" To: Adam Roach , Pete Resnick , "ietf@ietf.org" CC: "ben@nostrum.com" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , "draft-ietf-sipcore-status-unwanted@ietf.org" Thread-Topic: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard Thread-Index: AQHSl6JN/iwWLY4Mt0+M1X82mOsOtaGfhkwAgAATaoCAAAs0QA== Date: Tue, 21 Mar 2017 17:41:14 +0000 Message-ID: References: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> <534047ad-8971-88ec-3d16-254c766bbfa3@nostrum.com> In-Reply-To: <534047ad-8971-88ec-3d16-254c766bbfa3@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 511e81d9-9378-4578-fa84-08d4708178c9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:CY1PR03MB2346; x-microsoft-exchange-diagnostics: 1; CY1PR03MB2346; 7:NjSJbCj3RvSLpZXgVp6nvO8ICOSQheC0UvllWEI+4dur4wji+hy8OZcS01re1JHqSu63jgUu8lVYl9m8JDshU1jmBOg9eDE/YLw6JDQzKTmwEsSKPqoTzHs11gjc2OrEuWlkzZzODZUaawkas/kXR7aXKta9TIBcTu1S39ZOOQP2uxne/uo80NeSsfgZOFWqO24iGxLjJxaf1iuEc/ErmFwd5bHo1lSW/z5hz8SuIKY0gERrnC8h69hqTTyN3hYIQRsGJrL/5o+u0BvluWYw5KdkOvnZEd0bYB62n2e0ybHsCw+oM+BVPvSmh9TFRijsZaovNntMU19DegyDyOaeLw==; 20:Lh0xpkzQtWd6g5Gi/Ln/HoFRDYKitSpmGy4Xg9+Oo5gSA86C0Qw86LdPH9fVAmQyE9Nf130Hp9XlvhKt0pDGr2d6BmhLDCfmllMRVYhZhOWrmGqWlMqT/Wf69yZpcDEzUF0ZtdFigT7nQqYrD12RGpjZNqy1QRzlOOecZEISwOc= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(20161123558025)(6072148); SRVR:CY1PR03MB2346; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2346; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(377454003)(24454002)(51444003)(81166006)(76176999)(74316002)(7736002)(5660300001)(9686003)(55016002)(33656002)(8936002)(6436002)(25786009)(2900100001)(8676002)(2906002)(2950100002)(3660700001)(54896002)(86362001)(54356999)(99286003)(6246003)(6306002)(50986999)(3280700002)(7696004)(66066001)(229853002)(4326008)(54906002)(6116002)(102836003)(77096006)(189998001)(38730400002)(2501003)(122556002)(230783001)(53546009)(53936002)(790700001)(6506006)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR03MB2346; H:CY1PR03MB2348.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 17:41:14.2824 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2346 X-MC-Unique: tcSZ-m-fP0qe7YYRJUmlRA-1 Content-Type: multipart/alternative; boundary="_000_CY1PR03MB23484A2E5BA8F065A090761CB23D0CY1PR03MB2348namp_" Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 17:41:25 -0000 --_000_CY1PR03MB23484A2E5BA8F065A090761CB23D0CY1PR03MB2348namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 RldJVyAoYW5kIGNvbnNpZGVyaW5nIHRoYXQgd2UgbWF5IGVuZCB1cCB3aXRoIGEg4oCccm91Z2gg Y29uc2Vuc3Vz4oCdKSwgSSBhZ3JlZSB3aXRoIEFkYW3igJlzIGFuYWx5c2lzIGJlbG93Lg0KDQpT bywgb3ZlcmFsbCBJIGRvIG5vdCB0aGluayBhbnkgY2hhbmdlcyBhcmUgbmVlZGVkIGluIHRoZSBk cmFmdCBhbmQgaXQgY2FuIHByb2NlZWQgdG8gYmVjb21lIGEgUkZDLg0KDQpUaGFua3MsDQpUb2xn YQ0KDQpGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQWRhbSBSb2FjaA0KU2VudDogVHVlc2RheSwgTWFyY2ggMjEsIDIwMTcgMTI6NTkg UE0NClRvOiBQZXRlIFJlc25pY2sgPHByZXNuaWNrQHF0aS5xdWFsY29tbS5jb20+OyBpZXRmQGll dGYub3JnDQpDYzogYmVuQG5vc3RydW0uY29tOyBzaXBjb3JlLWNoYWlyc0BpZXRmLm9yZzsgc2lw Y29yZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZEBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLXNpcGNvcmUt c3RhdHVzLXVud2FudGVkLTA0LnR4dD4gKEEgU0lQIFJlc3BvbnNlIENvZGUgZm9yIFVud2FudGVk IENhbGxzKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KDQpPbiAzLzIxLzE3IDEwOjQ5LCBQZXRlIFJl c25pY2sgd3JvdGU6DQoNCiAgMS4gIFRoZSA2NjYgbWVjaGFuaXNtIGxlYXZlcyB0aGUgZGVjaXNp b24gb2Ygd2hhdCBpcyBtZWFudCBieSAidW53YW50ZWQiIHRvIHRoZSBwcm92aWRlciwgd2hpY2gg d2lsbCBpbmV2aXRhYmx5IGNhdXNlIGRhdGEgbG9zcyB0aHJvdWdoIHRoZSB1c2Ugb2YgaGV1cmlz dGljcy4gQWRkaW5nIGEgaGVhZGVyIHRvIHRoZSA2MDMgcmVzcG9uc2UgaXMgYW4gZXh0ZW5zaWJs ZSBtZWNoYW5pc20gdGhhdCBjb3VsZCBjYXB0dXJlIHRoZSBzaW5nbGUgc2VtYW50aWMgYml0IG9m IDY2NiBhbmQgYW55IGZ1dHVyZSBzZW1hbnRpY3MgdGhhdCBvbmUgd2lzaGVzIHRvIGFkZCwgd2l0 aG91dCByZXF1aXJpbmcgdGhlIHByb3ZpZGVyIHRvIGd1ZXNzLiBUaGUgcHJvdmlkZXIgZ2V0cyBk ZWZpbml0aXZlIGluZm9ybWF0aW9uIHRoYXQgaXQgY2FuIGFjdCBvbi4NCg0KVGhlIHByb2JsZW0g aXMgdGhhdCB0aGUgc2VtYW50aWNzIG9mIDY2NiBhcmUgYmFja3dhcmRzIGZyb20gdGhlIHNlbWFu dGljcyBvZiA2MDMuDQoNCjYwMyBtZWFucyAidGhlcmUgaXMgYW4gaXNzdWUgd2l0aCB0aGUgZGlz cG9zaXRpb24gb2YgdGhlICpjYWxsZWQqIHBhcnR5IHRoYXQgcHJldmVudHMgY29tcGxldGluZyB0 aGUgY2FsbC4iDQoNCjY2NiBtZWFucyAidGhlcmUgaXMgYW4gaXNzdWUgd2l0aCB0aGUgZGlzcG9z aXRpb24gb2YgdGhlICpjYWxsaW5nKiBwYXJ0eSB0aGF0IHByZXZlbnRzIGNvbXBsZXRpbmcgdGhl IGNhbGwuIg0KDQpZb3UncmUgcHJvcG9zaW5nIGNvbmZsYXRpbmcgdGhlIHR3byBzZW1hbnRpY3Ms IHdoaWNoIG5lY2Vzc2FyaWx5IGludHJvZHVjZXMgbW9yZSBhbWJpZ3VpdHksIG5vdCBsZXNzLg0K DQpDYXJyaWVyIGRldGVybWluYXRpb24gb2YgaG93IHRvIGhhbmRsZSB0aGVzZSBjb2RlcyBpcywg YXMgd2l0aCBhbnkgbnVpc2FuY2UgY29tbXVuaWNhdGlvbiBtaXRpZ2F0aW9uLCBnb2luZyB0byBu ZWNlc3NhcmlseSBiZSBiYXNlZCBvbiBoZXVyaXN0aWNzIHRvIGF2b2lkIGFjY2lkZW50YWwgYmxh Y2tsaXN0aW5nLCBpbnRlbnRpb25hbCBibG93YmFjaywgYW5kIHRoZSBpbmV2aXRhYmxlIGdhbWlu ZyBvZiB0aGUgc3lzdGVtIGJ5IGJhZCBhY3RvcnMuIFlvdSBpbXBseSB0aGF0IHRoZSBhcHBsaWNh dGlvbiBvZiBoZXVyaXN0aWNzIGlzIGFuIHVud2FudGVkIHNpZGUgZWZmZWN0IG9mIHRoZSBzeXN0 ZW0sIHdoZW4gaXQgaW4gZmFjdCB0aGUgcHJpbWFyeSBnb2FsLg0KDQpJbiB0ZXJtcyBvZiBiZWlu ZyBhYmxlIHRvIHByb3ZpZGUgZ3JhZGF0aW9uIGJldHdlZW4gdHlwZXMgb2YgdW53YW50ZWQgY2Fs bHMsIHRoZSBhcHBsaWNhdGlvbiBvZiBhIGhlYWRlciAtLSBhcyB5b3UgcHJvcG9zZSAtLSB0byBw cm92aWRlIHN1Y2ggaW5kaWNhdGlvbiBzZWVtcyBsaWtlIGEgZmluZSBpZGVhLiBJIHdpbGwgcG9p bnQgb3V0IG9uZSBjYXZlYXQgYW5kIG1ha2Ugb25lIG9ic2VydmF0aW9uLiBUaGUgY2F2ZWF0IGlz IHRoYXQgaXQgd291bGQgYmUgaGFybWZ1bCB0byBhZGQgdGhpcyBoZWFkZXIgaW4gYSB3YXkgdGhh dCByZXZlcnNlcyB0aGUgc2Vuc2Ugb2YgYSByZXNwb25zZSBjb2RlLCBzdWNoIGFzIG1ha2luZyA2 MDMgYmVhciBvbiB0aGUgY2FsbGluZyBwYXJ0eSByYXRoZXIgdGhhbiB0aGUgY2FsbGVkIHBhcnR5 OyBzbyBzdWNoIGFuIGluZGljYXRpb24gd291bGQgbmVlZCB0byBiZSBvbiBhIG5ldyByZXNwb25z ZSBjb2RlLCBzdWNoIGFzIHRoZSBvbmUgY3VycmVudGx5IHByb3Bvc2VkIGluIGRyYWZ0LWlldGYt c2lwY29yZS1zdGF0dXMtdW53YW50ZWQuIFRoZSBvYnNlcnZhdGlvbiBpcyB0aGF0IHRoaXMgbWVj aGFuaXNtIGNhbiBiZSBhZGRlZCB0byB0aGlzIG5ldyBzdGF0dXMgYXQgYSBsYXRlciBkYXRlLCBp biBhIG1vZHVsYXIgZmFzaGlvbiBhbmQgaW4gYSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3YXkuIElu IG90aGVyIHdvcmRzOiB5b3VyIHByb3Bvc2VkIGVuaGFuY2VtZW50IGlzICpuaWNlKiwgYnV0IGl0 IGRvZXMgbm90IHByZWNsdWRlIHB1Ymxpc2hpbmcgdGhlIG1lY2hhbmlzbSBjdXJyZW50bHkgZGVz Y3JpYmVkLg0KDQoNCg0KICAxLiAgVGhlIDY2NiBtZWNoYW5pc20gbGltaXRzIHRoZSBpbXBsZW1l bnRhdGlvbiBvZiB0aGUgbWVjaGFuaXNtIHRvIGEgMS1idXR0b24gY2hvaWNlIGFuZCByZXF1aXJl cyBhZGRpdGlvbmFsIHN0YW5kYXJkaXphdGlvbiB3b3JrIHRvIHVzZSBhIGRpZmZlcmVudCBVSS4g Q2xlYXJseSA2NjYgd2FzIGRlc2lnbmVkIGFyb3VuZCBzb21ldGhpbmcgYWtpbiB0byBhICJTUEFN IiBidXR0b24gaW4gdGhlIFVJLiBCdXQgd2hhdCBpZiBJIHdhbnQgYSBmaWVsZCBpbiBteSBhZGRy ZXNzIGJvb2sgdGhhdCBzYXlzLCAiUGVybWFuZW50bHkgYmxvY2sgdGhpcyBwYXJ0aWN1bGFyIGNh bGxlciIgKHNheSwgbXkgZXgtYm95ZnJpZW5kIG9yIG15IGFubm95aW5nIG5laWdoYm9yKT8gSSBk b24ndCB3YW50IHRvIGluZGljYXRlIHRoYXQgdGhlc2UgYXJlIHNwYW0gY2FsbHMgYmVjYXVzZSBJ IGRvbid0IHdhbnQgbXkgcHJvdmlkZXIgYXBwbHlpbmcgaGV1cmlzdGljcyB0byB0aGVtLiBJIHdh bnQgdG8gc2VuZCBiYWNrIGEgNjAzIHdpdGggYSBoZWFkZXIgdGhhdCBzYXlzLCAiQmxvY2sgdGhl c2Ugd2hlbmV2ZXIgeW91IHNlZSB0aGVtLCBidXQgb25seSBmb3IgbWUuIiBJIGNhbiB0aGluayBv ZiBhbGwgc29ydHMgb2Ygb3RoZXItdGhhbi1vbmUtYnV0dG9uIFVJcyB0aGF0IHNvbWVvbmUgbWln aHQgd2FudCB0byBpbXBsZW1lbnQuIDY2NiBpcyB0aWVkIHRvIGEgcGFydGljdWxhciBVSS4gNjAz IHdpdGggYSBoZWFkZXIgaXMgZXh0ZW5zaWJsZS4NCg0KVGhhdCBraW5kIG9mIHBlcnNpc3RlbnQs IGhhcmQtc3RhdGUgdXNlciBhY2NvdW50IGNvbmZpZ3VyYXRpb24gKnJlYWxseSogaXNuJ3QgYSBy ZWFzb25hYmxlIGtpbmQgb2YgdGhpbmcgdG8gZG8gd2l0aCBhIFNJUCBzdGF0dXMgY29kZSAobm90 IGxlYXN0IG9mIGFsbCBiZWNhdXNlIHlvdSB3b3VsZCBuZWVkIHNvbWUgbWVjaGFuaXNtIGZvciBy ZXZpZXdpbmcgYW5kIG1hbmFnaW5nIHN1Y2ggYSBsaXN0OyBhbmQgd2hhdGV2ZXIgdGhhdCBtZWNo YW5pc20gaXMgY291bGQganVzdCBhcyByZWFkaWx5IGJlIHVzZWQgZm9yIGFkZGluZyBlbnRyaWVz KS4gSWYgeW91IGZlZWwgdGhlIG5lZWQgdG8gcHVyc3VlIHRoZSBzb21ld2hhdCByZWxhdGVkIHBy b2JsZW0gc3BhY2Ugb2YgYSBuZXR3b3JrLWFzc2lzdGVkIGJsb2NrbGlzdCwgd2UgaGF2ZSBhIHZh cmlldHkgb2YgdG9vbHMgd2UgY291bGQgYnJpbmcgdG8gYmVhciwgc3VjaCBhcyBYQ0FQLiBUaGF0 J3MgYSBzZXBhcmFibGUgcHJvYmxlbSwgdGhvdWdoLCBhbmQgSSB0aGluayB0aGF0IHRhbmdsaW5n IGl0IHVwIHdpdGggc3BhbSBtaXRpZ2F0aW9uIGlzIGEgaHVnZSBtaXN0YWtlLg0KDQpJJ2xsIGFs c28gcG9pbnQgb3V0IHRoYXQgZGV2aWNlcyBhcmUgcGVyZmVjdGx5IGNhcGFibGUgb2YgaGFuZGxp bmcgdGhpcyBmZWF0dXJlIGxvY2FsbHkgd2l0aG91dCBhbnkgYXNzaXN0YW5jZSBmcm9tIHRoZSBu ZXR3b3JrLCBzbyBJJ20gbm90IHN1cmUgaG93IG11Y2ggdmFsdWUgd291bGQgYmUgYWRkZWQgYnkg ZGVmaW5pbmcgYSBuZXR3b3JrLWhvc3RlZCB2ZXJzaW9uIG9mIHRoZSBzZXJ2aWNlLiBUaGUgb3Zl cmFyY2hpbmcgcG9pbnQsIHRob3VnaCwgaXMgdGhhdCBhIFNJUCByZXNwb25zZSBjb2RlIGlzIGFi c29sdXRlbHkgdGhlIHdyb25nIGFwcHJvYWNoIGZvciBkb2luZyBzby4NCg0KDQoNCiAgMS4gIFRo ZSA2NjYgbWVjaGFuaXNtIHdpbGwgYmUgdHJlYXRlZCBhcyBhIDYwMCAiQnVzeSIgZXJyb3IgYnkg dW4tdXBncmFkZWQgY2FsbGVycyBhbmQvb3IgcHJvdmlkZXJzLiBUaGF0IG1pZ2h0IGltcGx5IHRv IHNvbWUgaW1wbGVtZW50YXRpb25zIHRoYXQgdGhleSBzaG91bGQgdHJ5IHRvIHJlLWRpYWwgKGUu Zy4sIHRoZSBwcm92aWRlciB1c2luZyB0aGUgYXV0by1yZWRpYWwgZmVhdHVyZSkgb3IgdG8gZW5n YWdlIGluIG90aGVyIHBvb3IgYmVoYXZpb3IuIDYwMyB3aXRoIG5vIFJldHJ5LUFmdGVyIGhlYWRl ciBhbHJlYWR5IGhhcyBhIHNlbWFudGljIG9mICJUaGUgY2FsbCB3YXMgcmVqZWN0ZWQgYW5kIEkn bSBub3QgdGVsbGluZyB5b3Ugd2hlbiBhIGdvb2QgdGltZSB0byBjYWxsIGJhY2sgaXMiLCBzbyB0 aGVyZSBpcyBzb21lIGhvcGUgdGhhdCBhbiB1bi11cGdyYWRlZCBjYWxsZXIgaXMgbW9yZSBsaWtl bHkgdG8gZG8gdGhlIHJpZ2h0IHRoaW5nLg0KDQoNCg0KVGhpcyBpcyByZWFsbHkgcmVhY2hpbmcs IGFuZCBJIHRoaW5rIGlzIGJhc2VkIG9uIGEgbWlzcGVyY2VwdGlvbiBvZiBob3cgU0lQIGNsaWVu dHMgYWN0dWFsbHkgd29yayB3aGVuIHRoZXkgcmVjZWl2ZSA2eHggcmVzcG9uc2VzLiBUYWtlbiB0 byBpdHMgbG9naWNhbCBjb25jbHVzaW9uLCBpZiB3ZSBhY2NlcHQgeW91ciBhc3NlcnRpb24gdGhl biB3ZSBjYW4ndCBldmVyIGRlZmluZSBhIG5ldyA2eHgtY2xhc3MgU0lQIHJlc3BvbnNlIGNvZGUg Zm9yIGZlYXIgdGhhdCBzdWNoIGNvZGVzICJtaWdodCBpbXBseSB0byBzb21lIGltcGxlbWVudGF0 aW9ucyB0aGF0IHRoZXkgc2hvdWxkIHRyeSB0byByZS1kaWFsIChlLmcuLCB0aGUgcHJvdmlkZXIg dXNpbmcgdGhlIGF1dG8tcmVkaWFsIGZlYXR1cmUpIG9yIHRvIGVuZ2FnZSBpbiBvdGhlciBwb29y IGJlaGF2aW9yLiINCg0KDQoNCi9hDQo= --_000_CY1PR03MB23484A2E5BA8F065A090761CB23D0CY1PR03MB2348namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsN Cgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsN Cgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjEyMDgwMzg3MzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NzE2 MTg4NTAwO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjkwNzExMjE0MDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTcxNDMyODE2NDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxNzc5MjU0 ODIxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDM3ODcwOTk2O30NCkBsaXN0IGwyOmxldmVs MSBsZm80DQoJe21zby1sZXZlbC1zdGFydC1hdDoyO30NCkBsaXN0IGwxOmxldmVsMSBsZm82DQoJ e21zby1sZXZlbC1zdGFydC1hdDozO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij5GV0lXIChhbmQgY29uc2lkZXJpbmcgdGhhdCB3ZSBtYXkgZW5kIHVwIHdp dGggYSDigJxyb3VnaCBjb25zZW5zdXPigJ0pLCBJIGFncmVlIHdpdGggQWRhbeKAmXMgYW5hbHlz aXMgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0 Ij5Tbywgb3ZlcmFsbCBJIGRvIG5vdCB0aGluayBhbnkgY2hhbmdlcyBhcmUgbmVlZGVkIGluIHRo ZSBkcmFmdCBhbmQgaXQgY2FuIHByb2NlZWQgdG8gYmVjb21lIGEgUkZDLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k b3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k b3d0ZXh0Ij5Ub2xnYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IHNpcGNvcmUgW21haWx0bzpzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFkYW0gUm9hY2g8YnI+ DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFyY2ggMjEsIDIwMTcgMTI6NTkgUE08YnI+DQo8Yj5U bzo8L2I+IFBldGUgUmVzbmljayAmbHQ7cHJlc25pY2tAcXRpLnF1YWxjb21tLmNvbSZndDs7IGll dGZAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IGJlbkBub3N0cnVtLmNvbTsgc2lwY29yZS1jaGFp cnNAaWV0Zi5vcmc7IHNpcGNvcmVAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMt dW53YW50ZWRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzaXBjb3JlXSBMYXN0 IENhbGw6ICZsdDtkcmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVzLXVud2FudGVkLTA0LnR4dCZndDsg KEEgU0lQIFJlc3BvbnNlIENvZGUgZm9yIFVud2FudGVkIENhbGxzKSB0byBQcm9wb3NlZCBTdGFu ZGFyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiAzLzIxLzE3IDEwOjQ5LCBQZXRlIFJlc25pY2sgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj5UaGUgNjY2IG1lY2hhbmlzbSBsZWF2ZXMgdGhl IGRlY2lzaW9uIG9mIHdoYXQgaXMgbWVhbnQgYnkgJnF1b3Q7dW53YW50ZWQmcXVvdDsgdG8gdGhl IHByb3ZpZGVyLCB3aGljaCB3aWxsIGluZXZpdGFibHkgY2F1c2UgZGF0YSBsb3NzIHRocm91Z2gg dGhlIHVzZSBvZiBoZXVyaXN0aWNzLiBBZGRpbmcgYSBoZWFkZXIgdG8gdGhlIDYwMyByZXNwb25z ZSBpcyBhbiBleHRlbnNpYmxlDQogbWVjaGFuaXNtIHRoYXQgY291bGQgY2FwdHVyZSB0aGUgc2lu Z2xlIHNlbWFudGljIGJpdCBvZiA2NjYgPGVtPmFuZCBhbnkgZnV0dXJlIHNlbWFudGljcyB0aGF0 IG9uZSB3aXNoZXMgdG8gYWRkPC9lbT4sIHdpdGhvdXQgcmVxdWlyaW5nIHRoZSBwcm92aWRlciB0 byBndWVzcy4gVGhlIHByb3ZpZGVyIGdldHMgZGVmaW5pdGl2ZSBpbmZvcm1hdGlvbiB0aGF0IGl0 IGNhbiBhY3Qgb24uPG86cD48L286cD48L2xpPjwvb2w+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQpUaGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBzZW1hbnRpY3Mgb2Yg NjY2IGFyZSBiYWNrd2FyZHMgZnJvbSB0aGUgc2VtYW50aWNzIG9mIDYwMy48YnI+DQo8YnI+DQo2 MDMgbWVhbnMgJnF1b3Q7dGhlcmUgaXMgYW4gaXNzdWUgd2l0aCB0aGUgZGlzcG9zaXRpb24gb2Yg dGhlICpjYWxsZWQqIHBhcnR5IHRoYXQgcHJldmVudHMgY29tcGxldGluZyB0aGUgY2FsbC4mcXVv dDs8YnI+DQo8YnI+DQo2NjYgbWVhbnMgJnF1b3Q7dGhlcmUgaXMgYW4gaXNzdWUgd2l0aCB0aGUg ZGlzcG9zaXRpb24gb2YgdGhlICpjYWxsaW5nKiBwYXJ0eSB0aGF0IHByZXZlbnRzIGNvbXBsZXRp bmcgdGhlIGNhbGwuJnF1b3Q7PGJyPg0KPGJyPg0KWW91J3JlIHByb3Bvc2luZyBjb25mbGF0aW5n IHRoZSB0d28gc2VtYW50aWNzLCB3aGljaCBuZWNlc3NhcmlseSBpbnRyb2R1Y2VzIG1vcmUgYW1i aWd1aXR5LCBub3QgbGVzcy48YnI+DQo8YnI+DQpDYXJyaWVyIGRldGVybWluYXRpb24gb2YgaG93 IHRvIGhhbmRsZSB0aGVzZSBjb2RlcyBpcywgYXMgd2l0aCBhbnkgbnVpc2FuY2UgY29tbXVuaWNh dGlvbiBtaXRpZ2F0aW9uLCBnb2luZyB0byBuZWNlc3NhcmlseSBiZSBiYXNlZCBvbiBoZXVyaXN0 aWNzIHRvIGF2b2lkIGFjY2lkZW50YWwgYmxhY2tsaXN0aW5nLCBpbnRlbnRpb25hbCBibG93YmFj aywgYW5kIHRoZSBpbmV2aXRhYmxlIGdhbWluZyBvZiB0aGUgc3lzdGVtIGJ5IGJhZCBhY3RvcnMu DQogWW91IGltcGx5IHRoYXQgdGhlIGFwcGxpY2F0aW9uIG9mIGhldXJpc3RpY3MgaXMgYW4gdW53 YW50ZWQgc2lkZSBlZmZlY3Qgb2YgdGhlIHN5c3RlbSwgd2hlbiBpdCBpbiBmYWN0IHRoZSBwcmlt YXJ5IGdvYWwuPGJyPg0KPGJyPg0KSW4gdGVybXMgb2YgYmVpbmcgYWJsZSB0byBwcm92aWRlIGdy YWRhdGlvbiBiZXR3ZWVuIHR5cGVzIG9mIHVud2FudGVkIGNhbGxzLCB0aGUgYXBwbGljYXRpb24g b2YgYSBoZWFkZXIgLS0gYXMgeW91IHByb3Bvc2UgLS0gdG8gcHJvdmlkZSBzdWNoIGluZGljYXRp b24gc2VlbXMgbGlrZSBhIGZpbmUgaWRlYS4gSSB3aWxsIHBvaW50IG91dCBvbmUgY2F2ZWF0IGFu ZCBtYWtlIG9uZSBvYnNlcnZhdGlvbi4gVGhlIGNhdmVhdCBpcyB0aGF0IGl0IHdvdWxkDQogYmUg aGFybWZ1bCB0byBhZGQgdGhpcyBoZWFkZXIgaW4gYSB3YXkgdGhhdCByZXZlcnNlcyB0aGUgc2Vu c2Ugb2YgYSByZXNwb25zZSBjb2RlLCBzdWNoIGFzIG1ha2luZyA2MDMgYmVhciBvbiB0aGUgY2Fs bGluZyBwYXJ0eSByYXRoZXIgdGhhbiB0aGUgY2FsbGVkIHBhcnR5OyBzbyBzdWNoIGFuIGluZGlj YXRpb24gd291bGQgbmVlZCB0byBiZSBvbiBhIG5ldyByZXNwb25zZSBjb2RlLCBzdWNoIGFzIHRo ZSBvbmUgY3VycmVudGx5IHByb3Bvc2VkDQogaW4gZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11 bndhbnRlZC4gVGhlIG9ic2VydmF0aW9uIGlzIHRoYXQgdGhpcyBtZWNoYW5pc20gY2FuIGJlIGFk ZGVkIHRvIHRoaXMgbmV3IHN0YXR1cyBhdCBhIGxhdGVyIGRhdGUsIGluIGEgbW9kdWxhciBmYXNo aW9uIGFuZCBpbiBhIGJhY2t3YXJkcyBjb21wYXRpYmxlIHdheS4gSW4gb3RoZXIgd29yZHM6IHlv dXIgcHJvcG9zZWQgZW5oYW5jZW1lbnQgaXMgKm5pY2UqLCBidXQgaXQgZG9lcyBub3QgcHJlY2x1 ZGUNCiBwdWJsaXNoaW5nIHRoZSBtZWNoYW5pc20gY3VycmVudGx5IGRlc2NyaWJlZC48YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPG9sIHN0YXJ0PSIyIiB0eXBlPSIxIj4NCjxs aSBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm80Ij5UaGUgNjY2 IG1lY2hhbmlzbSBsaW1pdHMgdGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZSBtZWNoYW5pc20gdG8g YSAxLWJ1dHRvbiBjaG9pY2UgYW5kIHJlcXVpcmVzIGFkZGl0aW9uYWwgc3RhbmRhcmRpemF0aW9u IHdvcmsgdG8gdXNlIGEgZGlmZmVyZW50IFVJLiBDbGVhcmx5IDY2NiB3YXMgZGVzaWduZWQgYXJv dW5kIHNvbWV0aGluZyBha2luIHRvIGEgJnF1b3Q7U1BBTSZxdW90Ow0KIGJ1dHRvbiBpbiB0aGUg VUkuIEJ1dCB3aGF0IGlmIEkgd2FudCBhIGZpZWxkIGluIG15IGFkZHJlc3MgYm9vayB0aGF0IHNh eXMsICZxdW90O1Blcm1hbmVudGx5IGJsb2NrIHRoaXMgcGFydGljdWxhciBjYWxsZXImcXVvdDsg KHNheSwgbXkgZXgtYm95ZnJpZW5kIG9yIG15IGFubm95aW5nIG5laWdoYm9yKT8gSSBkb24ndCB3 YW50IHRvIGluZGljYXRlIHRoYXQgdGhlc2UgYXJlIHNwYW0gY2FsbHMgYmVjYXVzZSBJIGRvbid0 IHdhbnQgbXkgcHJvdmlkZXIgYXBwbHlpbmcNCiBoZXVyaXN0aWNzIHRvIHRoZW0uIEkgd2FudCB0 byBzZW5kIGJhY2sgYSA2MDMgd2l0aCBhIGhlYWRlciB0aGF0IHNheXMsICZxdW90O0Jsb2NrIHRo ZXNlIHdoZW5ldmVyIHlvdSBzZWUgdGhlbSwgYnV0IG9ubHkgZm9yIG1lLiZxdW90OyBJIGNhbiB0 aGluayBvZiBhbGwgc29ydHMgb2Ygb3RoZXItdGhhbi1vbmUtYnV0dG9uIFVJcyB0aGF0IHNvbWVv bmUgbWlnaHQgd2FudCB0byBpbXBsZW1lbnQuIDY2NiBpcyB0aWVkIHRvIGEgcGFydGljdWxhciBV SS4gNjAzIHdpdGgNCiBhIGhlYWRlciBpcyBleHRlbnNpYmxlLjxvOnA+PC9vOnA+PC9saT48L29s Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhhdCBraW5kIG9m IHBlcnNpc3RlbnQsIGhhcmQtc3RhdGUgdXNlciBhY2NvdW50IGNvbmZpZ3VyYXRpb24gKnJlYWxs eSogaXNuJ3QgYSByZWFzb25hYmxlIGtpbmQgb2YgdGhpbmcgdG8gZG8gd2l0aCBhIFNJUCBzdGF0 dXMgY29kZSAobm90IGxlYXN0IG9mIGFsbCBiZWNhdXNlIHlvdSB3b3VsZCBuZWVkIHNvbWUgbWVj aGFuaXNtIGZvciByZXZpZXdpbmcgYW5kIG1hbmFnaW5nIHN1Y2ggYSBsaXN0OyBhbmQgd2hhdGV2 ZXIgdGhhdCBtZWNoYW5pc20NCiBpcyBjb3VsZCBqdXN0IGFzIHJlYWRpbHkgYmUgdXNlZCBmb3Ig YWRkaW5nIGVudHJpZXMpLiBJZiB5b3UgZmVlbCB0aGUgbmVlZCB0byBwdXJzdWUgdGhlIHNvbWV3 aGF0IHJlbGF0ZWQgcHJvYmxlbSBzcGFjZSBvZiBhIG5ldHdvcmstYXNzaXN0ZWQgYmxvY2tsaXN0 LCB3ZSBoYXZlIGEgdmFyaWV0eSBvZiB0b29scyB3ZSBjb3VsZCBicmluZyB0byBiZWFyLCBzdWNo IGFzIFhDQVAuIFRoYXQncyBhIHNlcGFyYWJsZSBwcm9ibGVtLCB0aG91Z2gsIGFuZA0KIEkgdGhp bmsgdGhhdCB0YW5nbGluZyBpdCB1cCB3aXRoIHNwYW0gbWl0aWdhdGlvbiBpcyBhIGh1Z2UgbWlz dGFrZS48YnI+DQo8YnI+DQpJJ2xsIGFsc28gcG9pbnQgb3V0IHRoYXQgZGV2aWNlcyBhcmUgcGVy ZmVjdGx5IGNhcGFibGUgb2YgaGFuZGxpbmcgdGhpcyBmZWF0dXJlIGxvY2FsbHkgd2l0aG91dCBh bnkgYXNzaXN0YW5jZSBmcm9tIHRoZSBuZXR3b3JrLCBzbyBJJ20gbm90IHN1cmUgaG93IG11Y2gg dmFsdWUgd291bGQgYmUgYWRkZWQgYnkgZGVmaW5pbmcgYSBuZXR3b3JrLWhvc3RlZCB2ZXJzaW9u IG9mIHRoZSBzZXJ2aWNlLiBUaGUgb3ZlcmFyY2hpbmcgcG9pbnQsIHRob3VnaCwNCiBpcyB0aGF0 IGEgU0lQIHJlc3BvbnNlIGNvZGUgaXMgYWJzb2x1dGVseSB0aGUgd3JvbmcgYXBwcm9hY2ggZm9y IGRvaW5nIHNvLjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8b2wgc3RhcnQ9 IjMiIHR5cGU9IjEiPg0KPGxpIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2 ZWwxIGxmbzYiPlRoZSA2NjYgbWVjaGFuaXNtIHdpbGwgYmUgdHJlYXRlZCBhcyBhIDYwMCAmcXVv dDtCdXN5JnF1b3Q7IGVycm9yIGJ5IHVuLXVwZ3JhZGVkIGNhbGxlcnMgYW5kL29yIHByb3ZpZGVy cy4gVGhhdCBtaWdodCBpbXBseSB0byBzb21lIGltcGxlbWVudGF0aW9ucyB0aGF0IHRoZXkgc2hv dWxkIHRyeSB0byByZS1kaWFsIChlLmcuLCB0aGUgcHJvdmlkZXIgdXNpbmcgdGhlIGF1dG8tcmVk aWFsDQogZmVhdHVyZSkgb3IgdG8gZW5nYWdlIGluIG90aGVyIHBvb3IgYmVoYXZpb3IuIDYwMyB3 aXRoIG5vIFJldHJ5LUFmdGVyIGhlYWRlciBhbHJlYWR5IGhhcyBhIHNlbWFudGljIG9mICZxdW90 O1RoZSBjYWxsIHdhcyByZWplY3RlZCBhbmQgSSdtIG5vdCB0ZWxsaW5nIHlvdSB3aGVuIGEgZ29v ZCB0aW1lIHRvIGNhbGwgYmFjayBpcyZxdW90Oywgc28gdGhlcmUgaXMgc29tZSBob3BlIHRoYXQg YW4gdW4tdXBncmFkZWQgY2FsbGVyIGlzIG1vcmUgbGlrZWx5IHRvIGRvIHRoZQ0KIHJpZ2h0IHRo aW5nLjxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cD5UaGlzIGlzIHJlYWxseSByZWFjaGluZywgYW5kIEkgdGhpbmsgaXMgYmFz ZWQgb24gYSBtaXNwZXJjZXB0aW9uIG9mIGhvdyBTSVAgY2xpZW50cyBhY3R1YWxseSB3b3JrIHdo ZW4gdGhleSByZWNlaXZlIDZ4eCByZXNwb25zZXMuIFRha2VuIHRvIGl0cyBsb2dpY2FsIGNvbmNs dXNpb24sIGlmIHdlIGFjY2VwdCB5b3VyIGFzc2VydGlvbiB0aGVuIHdlIGNhbid0IGV2ZXIgZGVm aW5lIGEgbmV3IDZ4eC1jbGFzcyBTSVAgcmVzcG9uc2UgY29kZSBmb3INCiBmZWFyIHRoYXQgc3Vj aCBjb2RlcyAmcXVvdDttaWdodCBpbXBseSB0byBzb21lIGltcGxlbWVudGF0aW9ucyB0aGF0IHRo ZXkgc2hvdWxkIHRyeSB0byByZS1kaWFsIChlLmcuLCB0aGUgcHJvdmlkZXIgdXNpbmcgdGhlIGF1 dG8tcmVkaWFsIGZlYXR1cmUpIG9yIHRvIGVuZ2FnZSBpbiBvdGhlciBwb29yIGJlaGF2aW9yLiZx dW90OzxvOnA+PC9vOnA+PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD4vYTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR03MB23484A2E5BA8F065A090761CB23D0CY1PR03MB2348namp_-- From nobody Tue Mar 21 10:43:40 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCABC129C48; Tue, 21 Mar 2017 10:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.021 X-Spam-Level: X-Spam-Status: No, score=-7.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rhy6zX3Q2o8l; Tue, 21 Mar 2017 10:43:38 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC63F129BDB; Tue, 21 Mar 2017 10:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1490118217; x=1521654217; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=IcBMkB34cKarcHBeOlLpKn4unYhqK6CwGmS9B9r7/Uo=; b=OlQYadoWXeeAismjqtqQcVwcOxegIhatD61/xM2fJSkASPM0hsjwRTUU P7+wq9ZPGNiWFKeNOpvvqIkw6x3D+X2PD/c+3YnGodeulLSdN9e383vbI rKB3h1UACoY6E9/RCzsekpMEcCaficwTkXaT4Yu6KXIwBevuumNrS9GiA M=; X-IronPort-AV: E=Sophos;i="5.36,200,1486454400"; d="scan'208";a="271798514" Received: from unknown (HELO ironmsg02-L.qualcomm.com) ([10.53.140.109]) by wolverine01.qualcomm.com with ESMTP; 21 Mar 2017 10:43:36 -0700 X-IronPort-AV: E=McAfee;i="5800,7501,8474"; a="889673326" X-MGA-submission: =?us-ascii?q?MDELvyk0SZV+FWP22BiwMESYjkzI/vELT8D7rb?= =?us-ascii?q?eZlB9fMlcRBHhw9q53KnHjL0eWDVUPtfUO4Sx3K54qPDFLUbnp60y4lB?= =?us-ascii?q?IuwtIVv6i28up5GHJf0/em/FFhw2Va3Gq/0hX90edCV45diCLOc4oVHb?= =?us-ascii?q?Hk?= Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Mar 2017 10:43:36 -0700 Received: from [10.64.124.243] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 21 Mar 2017 10:43:30 -0700 From: Pete Resnick To: Alan Johnston CC: Henning Schulzrinne , "sipcore@ietf.org" , "ietf@ietf.org" , "draft-ietf-sipcore-status-unwanted@ietf.org" Date: Tue, 21 Mar 2017 12:43:28 -0500 Message-ID: <5EA78FE0-9C80-4B7F-A7F0-F9096C94F078@qti.qualcomm.com> In-Reply-To: References: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> <8443007A-60F0-4AB6-80EC-DD20368D61EA@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 17:43:40 -0000 On 21 Mar 2017, at 12:05, Alan Johnston wrote: > If you are proposing using a SIP response code 603 and with a header > field > Decline-Type: spam, the problem with this is that in SIP, failure > responses > (non-2xx) are delivered hop-by-hop and not end-to-end. This means > that > although the first hop (proxy) will get the Decline-Type:spam header > field, > any future hops will not. Instead, they will just get the 603. > > A different response code such as 666 will be conveyed end-to-end, so > every > proxy and the calling UA will get the semantics. Adam walked me through the last few paragraphs of 3261 section 6. It's not clear in that text whether proxies will or won't preserve the headers, but if they don't, I expect that's a showstopper for my proposal. That's a bummer, because I do think the status code is going to cause future heartburn. However, if you SIP folks conclude that the header will not get through proxies (and I will take you all at your word if you so conclude), and this mechanism does need to survive proxies (which I suspect it does), then I think we're stuck with the status code. If so, I will happily return to you all to your discussion of whether particular numbers do or do not belong in IETF specifications. :-) (For the record, I thought 451 set a poor precedent, but I'm a curmudgeon.) pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Mar 21 10:49:39 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E463129542; Tue, 21 Mar 2017 10:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQhQisYXlxUx; Tue, 21 Mar 2017 10:49:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F094F128854; Tue, 21 Mar 2017 10:49:36 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v2LHnWjh068329 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 21 Mar 2017 12:49:33 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Pete Resnick , Alan Johnston References: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> <8443007A-60F0-4AB6-80EC-DD20368D61EA@qti.qualcomm.com> <5EA78FE0-9C80-4B7F-A7F0-F9096C94F078@qti.qualcomm.com> Cc: "draft-ietf-sipcore-status-unwanted@ietf.org" , "sipcore@ietf.org" , "ietf@ietf.org" , Henning Schulzrinne From: Adam Roach Message-ID: <6b32dd4d-b5d8-c190-9d34-ecf54d1c3853@nostrum.com> Date: Tue, 21 Mar 2017 12:49:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5EA78FE0-9C80-4B7F-A7F0-F9096C94F078@qti.qualcomm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 17:49:38 -0000 On 3/21/17 12:43, Pete Resnick wrote: > Adam walked me through the last few paragraphs of 3261 section 6. To be clear (and this is an easy mistake to make, since the sections and their contained steps are huge), Pete is referring to the long-form version of step 6 in section 16.7 here. See RFC 3261, page 111. /a From nobody Tue Mar 21 12:51:59 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8A2128990 for ; Tue, 21 Mar 2017 12:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GeQl1GFuk52 for ; Tue, 21 Mar 2017 12:51:57 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B0D128B38 for ; Tue, 21 Mar 2017 12:51:56 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-07v.sys.comcast.net with SMTP id qPoPct9NuU9z5qPoxciCqz; Tue, 21 Mar 2017 19:51:55 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-18v.sys.comcast.net with SMTP id qPovckuQDStKdqPovcxeBw; Tue, 21 Mar 2017 19:51:54 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2LJpq5c005564; Tue, 21 Mar 2017 15:51:52 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2LJpqde005556; Tue, 21 Mar 2017 15:51:52 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Adam Roach Cc: presnick@qti.qualcomm.com, alan.b.johnston@gmail.com, Henning.Schulzrinne@fcc.gov, sipcore@ietf.org, ietf@ietf.org, draft-ietf-sipcore-status-unwanted@ietf.org In-Reply-To: <6b32dd4d-b5d8-c190-9d34-ecf54d1c3853@nostrum.com> (adam@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 21 Mar 2017 15:51:52 -0400 Message-ID: <87wpbitnl3.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfHScBlLdI+tYRt5XHbAa4RKaEE048vzUGJMqPom0i1b0uVj2G0ueJ9K4Mu9xn9ehtGaGvuS4SdaBMhdgxtrVi5FJ/C8bhU4R02f9RxvPU7aXuZdgenrL YIjwS6Udt4SZjeI9qaK/BnIpJNn9n3B1vs3PWrdTHQKWORSNI8jJ2hYod91BA+wn++WcQL7vk3y1IWTeh9lAtIpPU3f25X1Lj+1TOoNKKgExRH1nroB+1OS+ ascF+Ih7Y3NZueei5ImMsldtu3wczd2L7mhwtgZ3fsfZ1AfbmQkJzEGYszZq/N9RKQjlSjEiVno4bbyqdCm732HnZEJ31xCU91aVuq4KahyYXsGCZWDeT+vC pP0lYJQ1L+lNRVhpU8lFSngE8WwVERNeNxFDlLEjD/qYIVlxcHA= Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 19:51:59 -0000 Adam Roach writes: > To be clear (and this is an easy mistake to make, since the sections and > their contained steps are huge), Pete is referring to the long-form > version of step 6 in section 16.7 here. See RFC 3261, page 111. Ah, there's a tension between this paragraph: The stateful proxy MUST choose the "best" final response among those received and stored in the response context. and this one: 3-6xx responses are delivered hop-by-hop. When issuing a 3-6xx response, the element is effectively acting as a UAS, issuing its own response, usually based on the responses received from downstream elements. An element SHOULD preserve the To tag when simply forwarding a 3-6xx response to a request that did not contain a To tag. But if many implementations take "choose the best final response" to mean only re-sending the response code, we have a problem. OTOH, it's quite possible to reserve a *set* of 6xx response codes to carry the decline-type. The only allocated 6xx responses are 600 (generic), 603, 604, and 606. Dale From nobody Tue Mar 21 15:05:42 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A9712F28A for ; Tue, 21 Mar 2017 15:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WC25ZQ4XJxjs for ; Tue, 21 Mar 2017 15:05:39 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B42C0129C08 for ; Tue, 21 Mar 2017 15:05:39 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-03v.sys.comcast.net with SMTP id qRuMcAMjlfuM3qRuMc0dQY; Tue, 21 Mar 2017 22:05:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1490133938; bh=aod0q0mt/6bIXf7bz7KBQOc2M0pzBIW8p74/bQ0fv/M=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=n5LMme3wCgmLuyfdBndtDRNpttYX8pckiBrjP9rA0eUSSojN2nk4JcVeKGV1hXP03 O+JfsshTwty4b67KYR51u8IQC4R0duhhiswO4SUb5u8h/Vl5JL3aeCCJ9Hvolr/h5t RDk5iJB1/zBBCiw1UlvH/Xqoar32aYu8YpIhg5eLg/+xL4gxlDgVLWKoS/URiI9c5y vqQO7atfxHVnNIeH5GnUTvjJP7nZSImaZA94Y57scgKTDBGgVWXnyTzZfcl6g8NELI W6FhEqAzc+o9WmwMK6gj01bI6xj+rurlNketjtVrRc8E0CXRAest6cFK6BuSBdO7uh Uq/uDW0BfEmaQ== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-08v.sys.comcast.net with SMTP id qRuLcUd2WtZO6qRuMcR7TN; Tue, 21 Mar 2017 22:05:38 +0000 To: sipcore@ietf.org References: <87wpbitnl3.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <8bba04c7-0ea4-5088-813f-b34aeb631e5b@comcast.net> Date: Tue, 21 Mar 2017 18:05:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87wpbitnl3.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfGUoeG1dzFINiWogHrMyr95gU+L1LlKI435r6XxNaYehANbYg2opkSjBlvC0Gqwg/MAO5NXWnoCfGOPWvclZS6oXXORx0WK/AQG9nT6HGrEGXfTM2rSI XjbGWUGt+TxKFLRTktT/UMqZdWy0xaKCwd5mInEERAdbu2ssWDLFgSLIdAxrOY/xnmPgxj7Kx0owQQ== Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 22:05:41 -0000 Isn't it assumed that a Reason header is preserved e2e with error responses? On 3/21/17 3:51 PM, Dale R. Worley wrote: > Adam Roach writes: >> To be clear (and this is an easy mistake to make, since the sections and >> their contained steps are huge), Pete is referring to the long-form >> version of step 6 in section 16.7 here. See RFC 3261, page 111. > > Ah, there's a tension between this paragraph: > > The stateful proxy MUST choose the "best" final response among > those received and stored in the response context. > > and this one: > > 3-6xx responses are delivered hop-by-hop. When issuing a 3-6xx > response, the element is effectively acting as a UAS, issuing > its own response, usually based on the responses received from > downstream elements. An element SHOULD preserve the To tag > when simply forwarding a 3-6xx response to a request that did > not contain a To tag. > > But if many implementations take "choose the best final response" to > mean only re-sending the response code, we have a problem. > > OTOH, it's quite possible to reserve a *set* of 6xx response codes to > carry the decline-type. The only allocated 6xx responses are 600 > (generic), 603, 604, and 606. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Mar 21 20:44:34 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4200A131443; Tue, 21 Mar 2017 20:44:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Peter Yee To: Cc: sipcore@ietf.org, ietf@ietf.org, draft-ietf-sipcore-status-unwanted.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.00 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149015426220.3518.3546300688917567228@ietfa.amsl.com> Date: Tue, 21 Mar 2017 20:44:22 -0700 Archived-At: Subject: [sipcore] Review of draft-ietf-sipcore-status-unwanted-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 03:44:22 -0000 Reviewer: Peter Yee Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-sipcore-status-unwanted-04 Reviewer: Peter Yee Review Date: 2017-03-21 IETF LC End Date: 2017-03-21 IESG Telechat date: Not scheduled for a telechat Summary: This draft specifies a SIP response code for the callee to indicate that the call is unwanted. It goes to great lengths to specify what may be done as a result of sending this response code, all the while mandating nothing. The document has a couple of nits, but nothing seriously wrong. [Ready with nits] Major issues: None Minor issues: None Nits/editorial comments: Page 4, 1st full paragraph, 2nd sentence: I can't parse this sentence as written. It appears to be a list, but then has a clause (starting at "based on") that doesn't fit neatly in the sequence. Perhaps inserting "and" before "based" would help. Append "as" after "well". Page 5, Section 6, 2nd paragraph, 1st sentence: change "extract" to "exact". From nobody Thu Mar 23 10:29:46 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417CD1299A0 for ; Thu, 23 Mar 2017 10:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPRUNJmyHe6q for ; Thu, 23 Mar 2017 10:29:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FAF31299E5 for ; Thu, 23 Mar 2017 10:29:33 -0700 (PDT) Received: from mutabilis-2.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v2NHTWgm069323 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 23 Mar 2017 12:29:32 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be mutabilis-2.local To: SIPCORE From: "A. Jean Mahoney" Message-ID: Date: Thu, 23 Mar 2017 12:29:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] WGLC: draft-ietf-sipcore-content-id-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 17:29:45 -0000 Hi all, A 3-week working group Last Call starts today for draft-ietf-sipcore-content-id. Please provide any feedback to the sipcore mailing list by Thursday, April 13th. Thanks! Jean From nobody Sun Mar 26 07:59:25 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBF1129447; Sun, 26 Mar 2017 07:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2nuKHzmLE1U; Sun, 26 Mar 2017 07:59:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE1712943F; Sun, 26 Mar 2017 07:59:22 -0700 (PDT) Received: from [31.133.134.138] (dhcp-868a.meeting.ietf.org [31.133.134.138]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v2QExK0n043066 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 26 Mar 2017 09:59:21 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host dhcp-868a.meeting.ietf.org [31.133.134.138] claimed to be [31.133.134.138] From: "Ben Campbell" To: SIPCORE , sipcore-chairs@ietf.org, "Brian Rosen" Date: Sun, 26 Mar 2017 09:59:18 -0500 Message-ID: <417A3129-22C6-4BD7-A3EC-F0C377A0B905@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: [sipcore] New SIPCORE Chair X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 14:59:24 -0000 Hi, Since Adam will become the new ART AD this week, we need a new co-chair for SIPCORE. Please welcome Brian Rosen, who has agreed to take that on. Brian will not be in Chicago for IETF98 (he has a really good excuse), so Adam will fill in for this week's meeting. Thanks! Ben. From nobody Mon Mar 27 08:08:45 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6444B128954 for ; Mon, 27 Mar 2017 08:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az4UcpauH6Yz for ; Mon, 27 Mar 2017 08:08:41 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524AE128854 for ; Mon, 27 Mar 2017 08:08:41 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id d10so35011605qke.1 for ; Mon, 27 Mar 2017 08:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k+/EIdYmquTJzg8NjN4T0Kqb6QvDf9onha8fBxMGyeE=; b=MsnN4MPzbBLcaQKX/bI2YZpmrvKCjsdBRWdtQ7mGBpNzkr8ewuSvRsK0bd989z2Cz8 gMT4y5NmbfXdkHnvsL9Pm35HfB4MPlNcxGR+JlRU3BIoMjr5aC33mlGsY9l3LuBXkx/y pz6oqPAnOgx60v5xZHuZkamqEX44zIc9MQxOCD1ma49O6W3sxsfBtvQ5coJ3zWECVmTU 4GeBuP1qME8Kwcv/d+stlU6Ie4g/BK37vuGNEVM4umrgnNRHqrxWaIKfU1CLXdXZJa3p bwCCF3tXk/mFUYY0Jhef0OBUr+fk9UFmvdWVmTuqPGCqZbQWdfmm0+7Im1yeGzboyHTL 5D2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k+/EIdYmquTJzg8NjN4T0Kqb6QvDf9onha8fBxMGyeE=; b=Vw96K25NBfdyibG/atYu1gR/Jo3E/3zcQwWGOgcG48nnL3C/2ItzLIR8g4ghgWz1Te mnyOn2effwngHHE9Qt6y+9/L3MGl5D3ia+a400eV30vRf3DvthEutkVO0uWBvtohQ9A4 CkQHOzUbCKj2MnkoBn7Putq8+6hQ2p7kWoIHeASP5MHMJQcCfR2Nlt3fE6EoK29l4WzE 5sc3C9bI57mOiFlCH+a99gRj9pazHnB5NLvu7gcH1vX7qj1LFEZ8CZR6OZW4bSIoLX0O eHdN60KBWn71Y468/R1dKJKotfCn6TbvCfmk3GP4DvfRdEfb+aW4MPbkFdXeEiwqBYZH DYPA== X-Gm-Message-State: AFeK/H12C/cshZloCCZNjh9yJraE84bb95rqmYzA1urZ3/ocqYphVtwSH+/XCh1d9CNEDd2LGlmKukwG+98rsQ== X-Received: by 10.55.151.199 with SMTP id z190mr22388223qkd.138.1490627320390; Mon, 27 Mar 2017 08:08:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.150.171 with HTTP; Mon, 27 Mar 2017 08:08:39 -0700 (PDT) In-Reply-To: <87lgs5ypgh.fsf@hobgoblin.ariadne.com> References: <8d7c905c-3c4f-7475-4e89-5cfd66a07602@nostrum.com> <87lgs5ypgh.fsf@hobgoblin.ariadne.com> From: Yehoshua Gev Date: Mon, 27 Mar 2017 18:08:39 +0300 Message-ID: To: "Dale R. Worley" Cc: Robert Sparks , sipcore Content-Type: multipart/alternative; boundary=94eb2c07d4f2ecaad3054bb7b706 Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-name-addr-guidance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 15:08:43 -0000 --94eb2c07d4f2ecaad3054bb7b706 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 16, 2017 at 10:46 PM, Dale R. Worley wrote: > Robert Sparks writes: > > If you form the header and violate the guidance by not using <>, the > header will necessarily be parsable *by the BNF alone* in the way it was > constructed. It might also be parsable by the BNF alone in another > way. What the guidance does is resolve the parsing ambiguity by > favoring the interpretation of comma, etc. as separators in the header > rather than as characters in the URI. This is something that I raised some time ago, in this thread https://mailarchive.ietf.org/arch/msg/sipcore/8DQXMoMSXfvldRYgRu-YcwhfKFo , and I'm sorry that I've left it open then. I still think that the current wording of the draft might be misleading. The examples of: Refer-To: sip:123@host?Replaces=1111 Refer-To: sip:123@host;user=phone?Replaces=1111 will all be syntactically invalid using the interpretation proposed by the draft. I think this is ok and corresponds to my current understanding of RFC 3261. However, in the above thread, it seemed to me that on first sight, both Dale and Robert thought that those examples are valid. After the discussion there, I think (IIUC) they agreed that those are not valid. This draft is a great place to state how exactly those type of examples are parsed. Also, it might be good to show an example like: Refer-To: sip:123@host;user=phone which is valid, but interpreted with an header parameter although it might have been intended to have a URI parameter (there is a reference to section 7.3.1 of [RFC3261], but is it not stated there explicitly regarding URI). Thanks, Yehoshua Gev --94eb2c07d4f2ecaad3054bb7b706 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 16, 2017 at 10:46 PM, Dale R. Worley <worley@ariadne.com>= wrote:
Robert Sparks <r= jsparks@nostrum.com> writes:

If you form the header and violate the guidance by not using <>, the<= br> header will necessarily be parsable *by the BNF alone* in the way it was constructed.=C2=A0 It might also be parsable by the BNF alone in another way.=C2=A0 What the guidance does is resolve the parsing ambiguity by
favoring the interpretation of comma, etc. as separators in the header
rather than as characters in the URI.

This is something that I raised some time ago, in this th= read
https://mailarchive.ietf.or= g/arch/msg/sipcore/8DQXMoMSXfvldRYgRu-YcwhfKFo ,
and I'm sorry that I've left it open then.

I still think th= at the current wording of the draft might be misleading.

The examples of:
=C2=A0 =C2=A0Refe= r-To: sip:123@host?Replaces=3D1111
<= span style=3D"font-size:12.8px">=C2=A0 =C2=A0Refer-To: sip:123@host;user=3Dphone?Replaces=3D1111
will all be syntactically invalid using the interpre= tation proposed by the draft.I think this is ok and corresponds to my= current understanding of RFC 3261.

However, in the above thread, it= seemed to me that on first sight, both Dale
and Robert thought that th= ose examples are valid.
After the discussion there, I think (IIUC= ) they agreed that those are not valid.

This draft= is a great place to state how exactly those type of examples
are= parsed.
Also, it might be good to show an example like:
=C2=A0 =C2=A0Refer-To: sip:123@host;user= =3Dphone
which is val= id, but interpreted with an header parameter although it might
=
have been intended to have a U= RI parameter (there is a reference to
section 7.3.1 of [RFC3261], but is= it not stated there explicitly regarding
URI).

Thanks,
Yehoshua Gev

--94eb2c07d4f2ecaad3054bb7b706-- From nobody Mon Mar 27 11:15:23 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145A1129483 for ; Mon, 27 Mar 2017 11:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdMy4oM51B5W for ; Mon, 27 Mar 2017 11:15:21 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E540712947D for ; Mon, 27 Mar 2017 11:15:20 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-08v.sys.comcast.net with SMTP id sZAScAmTqAfZssZAmceV14; Mon, 27 Mar 2017 18:15:20 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-16v.sys.comcast.net with SMTP id sZAkcvHir9isysZAlcEOiA; Mon, 27 Mar 2017 18:15:20 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2RIFI1g024818; Mon, 27 Mar 2017 14:15:18 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2RIFH1V024815; Mon, 27 Mar 2017 14:15:17 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat Cc: sipcore@ietf.org In-Reply-To: <8bba04c7-0ea4-5088-813f-b34aeb631e5b@comcast.net> (paul.kyzivat@comcast.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 27 Mar 2017 14:15:17 -0400 Message-ID: <87a886lh6y.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfDwQJMUeOR/Iwp+/BwqNGEsHhkCOUC2n8Saj3SSoGF1gIQBMaEx2WdcKCS68Dl7CtkbfyECUfpdnYrEQYuU1sVSUVA6m6FZHRwS5rfMe+x3lL0k9Br/k K8m7e50ZaE8l5LwC5zCCGgo0zFePX6a/L+RJa21rGHdQX92ETD6JmZJyYWKQfuu6hCGHb4QgtAXniXopYli5ITQ6h6vBm8CV3KM= Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 18:15:22 -0000 Paul Kyzivat writes: > Isn't it assumed that a Reason header is preserved e2e with error responses? Watching Roland's presentation in the Dispatch WG today prodded me to think about this again. As far as I can tell, RFC 3326 envisions that Reason headers can be included in responses but doesn't specify how they are processed. OTOH, it seems to me that the odds are good that most proxies propagate backward Reason headers in failure responses, so Reason would be a good choice for carrying additional information. Dale From nobody Mon Mar 27 15:39:52 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB38112968F for ; Mon, 27 Mar 2017 15:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkRFtSFp6df1 for ; Mon, 27 Mar 2017 15:39:48 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159B712969D for ; Mon, 27 Mar 2017 15:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1490654388; x=1522190388; h=from:to:subject:date:message-id:mime-version; bh=iwQATu5Cp2T0zQOoNrpvMbZV/4nOhA6A1Af+4w9bH6o=; b=R6AJHn8rR+vx9Ffk/kW4Ubyu1Yg7Qs1axPQzP9my8+hDgcpXPWNiKH0v /x0SFC0R4L18FoT1mVFy1EvXalGOZwDjAKUvLiYILvMFO/VxFhqybQbhu a4m2bQV5pK8tw5JoazLynVGz/rTMOVteCl8ALsCjgCGJJfDwg9Y7tSnZm K1ZQP8hY6exCYNuagg2LYeBBBI5Lgj/QcIU+PuC2ccAp3fRH7VL/NKVmp ZSsTIcdfE8puIiZHH1aPhx3wT1jRL5N3LlGFaDfjXa07hMzWe0YHN5gVg FdR4YSN8XvYvLg8pPKJNP6s0zizYZ2KzGZzfyB666AWF8C28UsSN/kAU2 A==; Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT21.telekom.de with ESMTP/TLS/RC4-SHA; 28 Mar 2017 00:39:45 +0200 X-IronPort-AV: E=Sophos;i="5.36,233,1486422000"; d="scan'208,217";a="644049484" Received: from he105828.emea1.cds.t-internal.com ([10.169.119.31]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 28 Mar 2017 00:39:45 +0200 Received: from HE105828.EMEA1.cds.t-internal.com (10.169.119.31) by HE105828.emea1.cds.t-internal.com (10.169.119.31) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 28 Mar 2017 00:39:44 +0200 Received: from HE105828.EMEA1.cds.t-internal.com ([fe80::753e:c05:6c77:b585]) by HE105828.emea1.cds.t-internal.com ([fe80::753e:c05:6c77:b585%26]) with mapi id 15.00.1263.000; Tue, 28 Mar 2017 00:39:44 +0200 From: To: Thread-Topic: draft-jesske-sipcore-reason-q850-loc-00.txt Thread-Index: AdKnSNE9v38NFoCTRlOji+Ptp6SzQA== Date: Mon, 27 Mar 2017 22:39:44 +0000 Message-ID: <2249afbf500e4683808213d1546b8c58@HE105828.emea1.cds.t-internal.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.213.246.118] Content-Type: multipart/alternative; boundary="_000_2249afbf500e4683808213d1546b8c58HE105828emea1cdstintern_" MIME-Version: 1.0 Archived-At: Subject: [sipcore] draft-jesske-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 22:39:51 -0000 --_000_2249afbf500e4683808213d1546b8c58HE105828emea1cdstintern_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, today I have presented the draft-jesske-dispatch-reason-loc-q850 in the DIS= PATCH meeting. The decision was to dispatch the draft to SIPCORE. Thus I have now an update of this draft solving the comments already made o= n the dispatch email list and changing it to sipcore. https://www.ietf.org/internet-drafts/draft-jesske-sipcore-reason-q850-loc-0= 0.txt This draft adds a location value parameter to the reason-extension paramete= r in [RFC3326] so that the [Q.850] location value can be interworked from t= he PSTN. Comments are welcome. Thank you and Best Regards Roland Jesske --_000_2249afbf500e4683808213d1546b8c58HE105828emea1cdstintern_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all,
today I have presented the draft-jesske-dispatch-reason-loc-q850 in th= e DISPATCH meeting.
The decision was to dispatch the draft to SIPCORE.
Thus I have now an update of this draft solving the comments already m= ade on the dispatch email list and changing it to sipcore.
 
&nbs= p;
= This draft adds a location value parameter to the reason-extension paramete= r in [RFC3326] so that the [Q.850] location value can be interworked from t= he PSTN.
&nbs= p;
Comments are welcome.
&nbs= p;
&nbs= p;
Thank you and Best Regards
 
Roland Jesske
&nbs= p;
 --_000_2249afbf500e4683808213d1546b8c58HE105828emea1cdstintern_-- From nobody Mon Mar 27 20:31:17 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188F112922E for ; Mon, 27 Mar 2017 20:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lni6VK97b0-k for ; Mon, 27 Mar 2017 20:31:13 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25085126DED for ; Mon, 27 Mar 2017 20:31:13 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-04v.sys.comcast.net with SMTP id shqicBRQnscBPshqicyXb2; Tue, 28 Mar 2017 03:31:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1490671872; bh=xPnUQLNlGYqqhptEZ8wiIncpJ6vUpiLCL1ns9bTK6iw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=mFXxf45cLI0qtVjPEdGspAQB0pr6U8BL6mkHARsSnzf52oSso2cv3/EcAJSxmExwF P83J6U8GKVd/dkqNTBNk7kkzCfMdEoKus0Qkd8klPXoUTg51SS9kqEq2grDut3tMHU Bj8+yD+lcThZyyilhu6+4PUjU8bjJbWjVN+hN327IytjqJbhyoQd6UHZpUXbanu3vZ X7BluNmo0/a64E2o2hQ4srs8Qa2iMCARtfuAPjDYwBr9DvNShiu3gsoCf+Jw8fJNDQ GXIBegqlS0VM4PeudmVPzrafwZm1QHBrZggfo5bh2IkQdF6TmGAerF0zCpp6kxHh8h 9umbgxP1kPMhg== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-01v.sys.comcast.net with SMTP id shqhcLRniY10NshqhceyNI; Tue, 28 Mar 2017 03:31:12 +0000 To: sipcore@ietf.org References: <2249afbf500e4683808213d1546b8c58@HE105828.emea1.cds.t-internal.com> From: Paul Kyzivat Message-ID: <11663afd-e332-4737-161b-780405a74ebb@comcast.net> Date: Mon, 27 Mar 2017 23:31:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2249afbf500e4683808213d1546b8c58@HE105828.emea1.cds.t-internal.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfBniq1HE2Ag35RzB4xZqcsNN+BmxpDkBN56GGOc8AzIcAlMVvED48hRb2+BbnQ0bzc64tUBSoAsqdwAU1dj18b8N5sv0u1uOEtEQsfTgu1ZJLj21h77V PgOVNM0quBj3YC9Oy1rpvlN1vZM5X/LG4CEczIQjSQP1q4P27TO3qyIUPWy/0Zff3gFE8X9kXAf0Sw== Archived-At: Subject: Re: [sipcore] draft-jesske-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 03:31:15 -0000 I have a couple of comments: The value for "location" is defined as just a string, which allows pretty much any value. But then the draft goes on to say "The values to be used as location are:" and a list of values. There is no normative language here. So its not at all clear if this is intended to be an exhaustive list with other values being forbidden, or if this is just a list of suggested values with others being permitted. If others are permitted, no mechanism is provided for agreeing on what other values mean. IMO the list of values ought to be normative. And if it is expected that other values may be added in the future then some sort of extension mechanism should be specified. Thanks, Paul On 3/27/17 6:39 PM, R.Jesske@telekom.de wrote: > Dear all, > today I have presented the draft-jesske-dispatch-reason-loc-q850 in the > DISPATCH meeting. > The decision was to dispatch the draft to SIPCORE. > Thus I have now an update of this draft solving the comments already > made on the dispatch email list and changing it to sipcore. > > _https://www.ietf.org/internet-drafts/draft-jesske-sipcore-reason-q850-loc-00.txt_ > > This draft adds a location value parameter to the reason-extension > parameter in [RFC3326] so that the [Q.850] location value can be > interworked from the PSTN. > > Comments are welcome. > > > Thank you and Best Regards > > Roland Jesske > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Mar 28 03:21:53 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0E3129409 for ; Tue, 28 Mar 2017 03:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWpFj6dE7QrL for ; Tue, 28 Mar 2017 03:21:49 -0700 (PDT) Received: from mailout23.telekom.de (MAILOUT23.telekom.de [80.149.113.253]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0073A129353 for ; Tue, 28 Mar 2017 03:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1490696509; x=1522232509; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=FZMO2rhXw/VO9JSp8nzZ23vR1roFIxf5L8JHH2MJj+0=; b=CoPIeKf199G0Db7ELNMlWJSG9n2EotNeJwwXMYPuIPcvdwsbH8s8uoZA 3KMUJzzrvsjOuZuvaTGHlenCrGCpxFnvbRvmPW9J3059lQD1PVJwWKz/R 0dhQngeh+dU2VjOp1XpCtrQ5c8UA9R94mEssmOhqYZ2bOI8MfqNYbQDhP yhGoE8WhpEf7/e4E3wXLc9NWJhcyPjdN/4EX12jB7m4e7ytTIO3iL3QQu nIhFkxQdAxfOdCrVp1fs4Ow6aWUgAiDoQL07eYWgMY6H/sWZ3uqADkdE3 oZUuNALEgGk82/v65K60XUmYaJVeFU7WEwDhdjruxtIrAatEixMSDvY2c A==; Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by MAILOUT21.telekom.de with ESMTP/TLS/RC4-SHA; 28 Mar 2017 12:21:46 +0200 X-IronPort-AV: E=Sophos;i="5.36,236,1486422000"; d="scan'208";a="1292779657" Received: from he105828.emea1.cds.t-internal.com ([10.169.119.31]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES256-SHA; 28 Mar 2017 12:21:16 +0200 Received: from HE105828.EMEA1.cds.t-internal.com (10.169.119.31) by HE105828.emea1.cds.t-internal.com (10.169.119.31) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 28 Mar 2017 12:21:15 +0200 Received: from HE105828.EMEA1.cds.t-internal.com ([fe80::753e:c05:6c77:b585]) by HE105828.emea1.cds.t-internal.com ([fe80::753e:c05:6c77:b585%26]) with mapi id 15.00.1263.000; Tue, 28 Mar 2017 12:21:15 +0200 From: To: , Thread-Topic: [sipcore] draft-jesske-sipcore-reason-q850-loc-00.txt Thread-Index: AdKnSNE9v38NFoCTRlOji+Ptp6SzQAAGinyAABJ7txA= Date: Tue, 28 Mar 2017 10:21:15 +0000 Message-ID: <64a0942b3b144e0dbb88103f004d0e6e@HE105828.emea1.cds.t-internal.com> References: <2249afbf500e4683808213d1546b8c58@HE105828.emea1.cds.t-internal.com> <11663afd-e332-4737-161b-780405a74ebb@comcast.net> In-Reply-To: <11663afd-e332-4737-161b-780405a74ebb@comcast.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.213.198.56] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] draft-jesske-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 10:21:52 -0000 Hi Paul, Thank you for your comment. You are right. I assume that ITU-T will not touch Q.850 anymore. So I will change the wording and make the values normative. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat Gesendet: Montag, 27. M=E4rz 2017 22:31 An: sipcore@ietf.org Betreff: Re: [sipcore] draft-jesske-sipcore-reason-q850-loc-00.txt I have a couple of comments: The value for "location" is defined as just a string, which allows pretty m= uch any value. But then the draft goes on to say "The values to be used as = location are:" and a list of values. There is no normative language here. S= o its not at all clear if this is intended to be an exhaustive list with ot= her values being forbidden, or if this is just a list of suggested values w= ith others being permitted. If others are permitted, no mechanism is provid= ed for agreeing on what other values mean. IMO the list of values ought to be normative. And if it is expected that ot= her values may be added in the future then some sort of extension mechanism= should be specified. Thanks, Paul On 3/27/17 6:39 PM, R.Jesske@telekom.de wrote: > Dear all, > today I have presented the draft-jesske-dispatch-reason-loc-q850 in=20 > the DISPATCH meeting. > The decision was to dispatch the draft to SIPCORE. > Thus I have now an update of this draft solving the comments already=20 > made on the dispatch email list and changing it to sipcore. > > _https://www.ietf.org/internet-drafts/draft-jesske-sipcore-reason-q850 > -loc-00.txt_ > > This draft adds a location value parameter to the reason-extension=20 > parameter in [RFC3326] so that the [Q.850] location value can be=20 > interworked from the PSTN. > > Comments are welcome. > > > Thank you and Best Regards > > Roland Jesske > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Mar 28 03:36:43 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8331294D1 for ; Tue, 28 Mar 2017 03:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.696 X-Spam-Level: X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YBVpXqzpozB for ; Tue, 28 Mar 2017 03:36:39 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A43129353 for ; Tue, 28 Mar 2017 03:36:38 -0700 (PDT) Received: from [195.245.230.51] by server-11.bemta-3.messagelabs.com id 0A/E1-23940-4BC3AD85; Tue, 28 Mar 2017 10:36:36 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleJIrShJLcpLzFFi42LR98zp1t1icyv C4OYaNYsHP3rZLJrudLFZfP2xic2B2WPy4zmMHkuW/GTyaHupEMAcxZqZl5RfkcCaceuuUcF6 uYr5z1axNzCukexi5OIQEtjOKNG/4ws7hHOYUeJaYxOUs5lRYu3zRpYuRg4ONgF7iRl7YkDiI gJ9jBIfHt1i7WLk5BAWcJJ4tv86G4gtIuAssensVRYI20li159dYDUsAqoSW+evBbN5BUIlNu 5dxgyx4BSjxMGH95hAEpwCgRJ7Lm1iBrEZBWQlvjSuBrOZBcQlbj2ZD1YjISAgsWTPeWYIW1T i5eN/rBA1ehI3pk5hg7C1JZYtfM0MsUxQ4uTMJ2AHCQEd8W/lIqYJjCKzkIydhaR9FpL2WUja FzCyrGJUL04tKkst0rXQSyrKTM8oyU3MzNE1NDDWy00tLk5MT81JTCrWS87P3cQIjB8GINjBe KHd+RCjJAeTkijvU+NbEUJ8SfkplRmJxRnxRaU5qcWHGGU4OJQkeL2tgXKCRanpqRVpmTnASI ZJS3DwKInwBoGkeYsLEnOLM9MhUqcYFaXEeaVBEgIgiYzSPLg2WPK4xCgrJczLCHSIEE9BalF uZgmq/CtGcQ5GJWHedJApPJl5JXDTXwEtZgJafHj+DZDFJYkIKakGxtWJR2Mq3E2eGmbZXTmb Ntt0poymyIund3jPcnKoP8idprb7PZuPWUbOuqRlfU+3cLSnhdkwc+/5ejhrC2PqpGrhuzxh6 2/ttZDsT7V686Zw9WoFzopVk2W3W504m7TvgnpjwrLYE9oaOZaPJP/+K1jqHlYfn/KQ45KG9/ zVNy42dLqVls77qsRSnJFoqMVcVJwIAMDdiokZAwAA X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-12.tower-33.messagelabs.com!1490697386!101259675!9 X-Originating-IP: [47.73.108.139] X-StarScan-Received: X-StarScan-Version: 9.2.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30104 invoked from network); 28 Mar 2017 10:36:36 -0000 Received: from vgdpm13vr.vodafone.com (HELO voxe01hw.internal.vodafone.com) (47.73.108.139) by server-12.tower-33.messagelabs.com with AES256-SHA256 encrypted SMTP; 28 Mar 2017 10:36:36 -0000 Received: from VOEXH11W.internal.vodafone.com (47.73.211.215) by edge1.vodafone.com (195.232.244.46) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 28 Mar 2017 12:36:30 +0200 Received: from VOEXC04W.internal.vodafone.com (145.230.101.24) by VOEXH11W.internal.vodafone.com (47.73.211.215) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 28 Mar 2017 12:36:30 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.159]) by VOEXC04W.internal.vodafone.com ([145.230.101.24]) with mapi id 14.03.0294.000; Tue, 28 Mar 2017 12:36:29 +0200 From: "Dawes, Peter, Vodafone Group" To: "R.Jesske@telekom.de" , "paul.kyzivat@comcast.net" , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-jesske-sipcore-reason-q850-loc-00.txt Thread-Index: AdKnSNE9v38NFoCTRlOji+Ptp6SzQAAGinyAABJ7txAAAG5pkA== Date: Tue, 28 Mar 2017 10:36:29 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E1513035@VOEXM31W.internal.vodafone.com> References: <2249afbf500e4683808213d1546b8c58@HE105828.emea1.cds.t-internal.com> <11663afd-e332-4737-161b-780405a74ebb@comcast.net> <64a0942b3b144e0dbb88103f004d0e6e@HE105828.emea1.cds.t-internal.com> In-Reply-To: <64a0942b3b144e0dbb88103f004d0e6e@HE105828.emea1.cds.t-internal.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] draft-jesske-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 10:36:41 -0000 Hi Roland, A few review comments:=20 Abstract I think the following sentence from the Introduction should be added to the= end of the abstract: "This document adds a location value parameter to the= reason-extension parameter in [RFC3326] so that the [Q.850] location value= can be interworked from the PSTN".=20 1. Introduction=20 I think that the sentence "[RFC3326] does specify that a ISUP [Q.850] cause= code can be carried within a SIP response." makes more sense if it says "[= RFC6432] does specify that a ISUP [Q.850] cause code can be carried within = a SIP response". I notice that the [RFC6432] reference is not currently use= d in the body of the draft.=20 3. Rationale I think the sentence "The ISDN location is defined in [Q.850]." might be mi= sleading as [Q.850] is an informative reference and the location values are= defined within the draft. I prefer "The ISDN location is described in [Q.8= 50] and defined in this document".=20 4. Mechanism Also says "ISUP location value defined in [Q.850]", I prefer "ISUP location= value described in [Q.850] and defined in this document." 9. Acknowledgments Thanks for the acknowledgment, I noticed that my name is missing an 'e' :-) Regards, Peter > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of > R.Jesske@telekom.de > Sent: 28 March 2017 11:21 > To: paul.kyzivat@comcast.net; sipcore@ietf.org > Subject: Re: [sipcore] draft-jesske-sipcore-reason-q850-loc-00.txt >=20 > Hi Paul, > Thank you for your comment. > You are right. I assume that ITU-T will not touch Q.850 anymore. > So I will change the wording and make the values normative. >=20 > Best Regards >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyziva= t > Gesendet: Montag, 27. M=E4rz 2017 22:31 > An: sipcore@ietf.org > Betreff: Re: [sipcore] draft-jesske-sipcore-reason-q850-loc-00.txt >=20 > I have a couple of comments: >=20 > The value for "location" is defined as just a string, which allows pretty= much > any value. But then the draft goes on to say "The values to be used as > location are:" and a list of values. There is no normative language here.= So its > not at all clear if this is intended to be an exhaustive list with other = values > being forbidden, or if this is just a list of suggested values with other= s being > permitted. If others are permitted, no mechanism is provided for agreeing > on what other values mean. >=20 > IMO the list of values ought to be normative. And if it is expected that = other > values may be added in the future then some sort of extension mechanism > should be specified. >=20 > Thanks, > Paul >=20 > On 3/27/17 6:39 PM, R.Jesske@telekom.de wrote: > > Dear all, > > today I have presented the draft-jesske-dispatch-reason-loc-q850 in > > the DISPATCH meeting. > > The decision was to dispatch the draft to SIPCORE. > > Thus I have now an update of this draft solving the comments already > > made on the dispatch email list and changing it to sipcore. > > > > _https://www.ietf.org/internet-drafts/draft-jesske-sipcore-reason-q850 > > -loc-00.txt_ > > > > This draft adds a location value parameter to the reason-extension > > parameter in [RFC3326] so that the [Q.850] location value can be > > interworked from the PSTN. > > > > Comments are welcome. > > > > > > Thank you and Best Regards > > > > Roland Jesske > > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Mar 28 17:57:55 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8748B127B52 for ; Tue, 28 Mar 2017 17:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJgbVssUPwjM for ; Tue, 28 Mar 2017 17:57:52 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490151273B1 for ; Tue, 28 Mar 2017 17:57:52 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-09v.sys.comcast.net with SMTP id t1uzcPLbdQe9ct1vrc1gGs; Wed, 29 Mar 2017 00:57:51 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-13v.sys.comcast.net with SMTP id t1vpcPspAAtR2t1vqcLHof; Wed, 29 Mar 2017 00:57:51 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2T0vmN0021872; Tue, 28 Mar 2017 20:57:48 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2T0vmrj021869; Tue, 28 Mar 2017 20:57:48 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Yehoshua Gev Cc: rjsparks@nostrum.com, sipcore@ietf.org In-Reply-To: (yoshigev@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 28 Mar 2017 20:57:48 -0400 Message-ID: <877f38kigj.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfAhW6p5pNe/g15wgfUGDqM6v6rqup5uXd28JgfE0X8E2iuiGX9CUjnYpJCaOk+uQkUlp0Pe2pU7eA6sSvBiOV46MC7tz6C7L+pDe4fwi6TzVs4qfnl8H BKqk3//2mpk7kWB8F0b/yU9E3lG9bpyuhpuKFMPK1tppdqIk4e8lDQBck6V5g5N9UpkLk23QXIAtAdrxWHFIvAcsmJJswc51Z0ujFGKz1UWmBxIASWcvp32+ Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-name-addr-guidance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 00:57:53 -0000 Yehoshua Gev writes: > The examples of: > Refer-To: sip:123@host?Replaces=1111 > Refer-To: sip:123@host;user=phone?Replaces=1111 > will all be syntactically invalid using the interpretation proposed by the > draft. > I think this is ok and corresponds to my current understanding of RFC 3261. > > However, in the above thread, it seemed to me that on first sight, both Dale > and Robert thought that those examples are valid. > After the discussion there, I think (IIUC) they agreed that those are not > valid. You have to be careful about the terminology. Within the context of draft-ietf-sipcore-name-addr-guidance, there is the BNF, and then there is an extra-BNF constraint. So what does the term "syntactically valid" mean? In the context of parsing as it is used in computer programming languages, "syntactic" is usually used only in regard to what is expressed in BNF. So from that point of view, you could say that the two examples are "syntactically valid" but that they are invalid relative to the non-BNF restriction. On the other hand, you could say that "syntactically valid" means that it passes every validity check that can be implemented without reference to external information sources. In that case, the two examples are "syntactically invalid", because they violate the non-BNF restriction, and determining that doesn't require knowing anything about the domain "host". That ambiguity is why I used the term "parsable *by the BNF alone*", as that is not bedeviled by the exact definition of "syntactically". Of course, the questions you raise about what examples should be discussed in the draft are still valid. Dale From nobody Wed Mar 29 02:05:30 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DF3129698 for ; Wed, 29 Mar 2017 02:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vD43DI3VFClu for ; Wed, 29 Mar 2017 02:05:26 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88EF71293DA for ; Wed, 29 Mar 2017 02:05:26 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id r142so7243274qke.2 for ; Wed, 29 Mar 2017 02:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rvxYnUZP2DNV+mjEkchA4Vf0yG5hGoiQIt8coyPyRDo=; b=i5cw1XX1wv9X3wLgsdEAfxDmz/tbzo5kSikKemZGqQvFP5EVfdnZrOuq2232j0YUCm GeJDLzQq6XBRgktTKwY3FSkvg0dBxt7w8gmZAnqPpgOY5odMQmpMUdRjwqX6l9+lzS6Y Ugc6LEw6XDobkoi0IbscYsORlFpWjgVLNHQc4PvzmV3c9rTAPw5sOgzHsfyo2Vlw59TG SIME/9aFAZbUEUc4P7/sEsYtkFkV4L01Hv+zdf/3UvV5LkbvQlJtXGTyMQ74zkEJQoyo LsOgvA2h6o0ZTPfDFGm5W9y/ttp6Gn9nQ5KmHDVrSgXPkTHjmLF02FT/UuP7bsEH4FGf k3RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rvxYnUZP2DNV+mjEkchA4Vf0yG5hGoiQIt8coyPyRDo=; b=iGEoz5rzn/7qw00K7EHOIT4L4Z8mmpQLLiKJtjH2pvKbURdNmncTbSl0tRqaspFB8q vWdRRwnvyaPYRoN3OsRIoqRJ3B1zPFVwGWtTAVXr2gYdJpZxd6k+msc2ZQ4/0Bpuzv9G TmUbz3Di9ESvyxxXP3HEECxhDop1z7rg6LuPeUp2LJrvR4u1WR3nvKR+CoR4ZKsybZUj T0zGZv+WREQAONyg1f2DqtEDIS4Vn2vaq3QFy9u7uxVEuiAfIX3/uM2ECeLo2iORJa1h 4YsW2qZuaVtYyuEr8IPsXC0vOafqVNkE3T6F1c7Tv+0RXHuSi40/rwBw0NHQwG7ES9gV TBuw== X-Gm-Message-State: AFeK/H23Hswfwc64QzzUVXuCwzAaWhcrWmR/pB0aUTUYp3f4qi/BzQkulLzrRyPbvUqGuzjPF/ewWNBlXNSB+w== X-Received: by 10.55.157.67 with SMTP id g64mr11816128qke.192.1490778325746; Wed, 29 Mar 2017 02:05:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.150.171 with HTTP; Wed, 29 Mar 2017 02:05:25 -0700 (PDT) In-Reply-To: <877f38kigj.fsf@hobgoblin.ariadne.com> References: <877f38kigj.fsf@hobgoblin.ariadne.com> From: Yehoshua Gev Date: Wed, 29 Mar 2017 12:05:25 +0300 Message-ID: To: "Dale R. Worley" Cc: Robert Sparks , sipcore Content-Type: multipart/alternative; boundary=94eb2c05626e8bb979054bdae0ef Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-name-addr-guidance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 09:05:29 -0000 --94eb2c05626e8bb979054bdae0ef Content-Type: text/plain; charset=UTF-8 On Wed, Mar 29, 2017 at 3:57 AM, Dale R. Worley wrote: > Yehoshua Gev writes: > > The examples of: > > Refer-To: sip:123@host?Replaces=1111 > > Refer-To: sip:123@host;user=phone?Replaces=1111 > > will all be syntactically invalid using the interpretation proposed by > the > > draft. > > I think this is ok and corresponds to my current understanding of RFC > 3261. > > > > However, in the above thread, it seemed to me that on first sight, both > Dale > > and Robert thought that those examples are valid. > > After the discussion there, I think (IIUC) they agreed that those are not > > valid. > > You have to be careful about the terminology. Within the context of > draft-ietf-sipcore-name-addr-guidance, there is the BNF, and then there > is an extra-BNF constraint. So what does the term "syntactically valid" > mean? In the context of parsing as it is used in computer programming > languages, "syntactic" is usually used only in regard to what is > expressed in BNF. So from that point of view, you could say that the > two examples are "syntactically valid" but that they are invalid > relative to the non-BNF restriction. > I believe that the examples above are not valid according to the BNF - that of RFC 3515, not of 3261: Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * (SEMI generic-param) This BNF does not allow for a question mark after the name-addr. So, the interpreting the string "sip:123@host" as the addr-spec alone, renders the header non-parsable by the BNF of 3515. Also, RFC 3261 section 20: The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters. only has normative text regarding Contact, From, and To header fields. I didn't see similar normative text for other headers, so the text int the draft: "The characters after the comma, question mark, or semicolon would be interpreted..." is a new disambiguation rule (for other headers). Given so, IMHO the disambiguation rule should be stated as a normative text. Thanks, Yehoshua Gev --94eb2c05626e8bb979054bdae0ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 29, 2017 at 3:57 AM, Dale R. Worley <worley@ariadne.com>= wrote:
Yehoshua Gev <yosh= igev@gmail.com> writes:
> The examples of:
>=C2=A0 =C2=A0 Refer-To: sip:123@host?Replaces=3D1111
>=C2=A0 =C2=A0 Refer-To: sip:123@host;user=3Dphone?Replaces=3D1111<= br> > will all be syntactically invalid using the interpretation proposed by= the
> draft.
> I think this is ok and corresponds to my current understanding of RFC = 3261.
>
> However, in the above thread, it seemed to me that on first sight, bot= h Dale
> and Robert thought that those examples are valid.
> After the discussion there, I think (IIUC) they agreed that those are = not
> valid.

You have to be careful about the terminology.=C2=A0 Within the conte= xt of
draft-ietf-sipcore-name-addr-guidance, there is the BNF, and then ther= e
is an extra-BNF constraint.=C2=A0 So what does the term "syntactically= valid"
mean?=C2=A0 In the context of parsing as it is used in computer programming=
languages, "syntactic" is usually used only in regard to what is<= br> expressed in BNF.=C2=A0 So from that point of view, you could say that the<= br> two examples are "syntactically valid" but that they are invalid<= br> relative to the non-BNF restriction.
=C2=A0
= I believe that the examples above are not valid according to the BNF -
t= hat of RFC 3515, not of 3261:
=C2=A0 =C2=A0 =C2=A0 Refer-To =3D ("R= efer-To" / "r") HCOLON ( name-addr / addr-spec ) *
=C2=A0= =C2=A0 =C2=A0 (SEMI generic-param)
This BNF does not allow for a= question mark after the name-addr.
So, the interpreting the stri= ng "sip:123@host" as the addr-spec alone, renders the
h= eader non-parsable by the BNF of 3515.
=C2=A0
Also, RFC= =C2=A03261 section 20:
=C2=A0 =C2=A0 The Contact, From, and To header fi= elds contain a URI.=C2=A0 If the URI
=C2=A0 =C2=A0 contains a comma, que= stion mark or semicolon, the URI MUST be
=C2=A0 =C2=A0 enclosed in angle= brackets (< and >).=C2=A0 Any URI parameters are
=C2=A0 =C2=A0 co= ntained within these brackets.=C2=A0 If the URI is not enclosed in angle=C2=A0 =C2=A0 brackets, any semicolon-delimited parameters are header-para= meters,
=C2=A0 =C2=A0 not URI parameters.
only has normative text reg= arding Contact, From, and To header fields.
I didn't see similar nor= mative text for other headers, so the text int the
draft: "T= he characters after the comma, question mark, or semicolon would
= be interpreted..." is a new disambiguation=C2=A0rule (for other header= s).
Given so, IMHO the disambiguation rule should be stated as a = normative text.

Thanks,
Yehoshua Gev

--94eb2c05626e8bb979054bdae0ef-- From nobody Wed Mar 29 14:04:10 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8669D124217 for ; Wed, 29 Mar 2017 14:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ4U8bZ4WFuC for ; Wed, 29 Mar 2017 14:04:08 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D9AE12947E for ; Wed, 29 Mar 2017 14:04:08 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-07v.sys.comcast.net with SMTP id tKkTc5RIQU9z5tKlDc4C9s; Wed, 29 Mar 2017 21:04:07 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-05v.sys.comcast.net with SMTP id tKlBcDYp0xrGZtKlCcM98q; Wed, 29 Mar 2017 21:04:07 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2TL45L1016957; Wed, 29 Mar 2017 17:04:05 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2TL44Y9016954; Wed, 29 Mar 2017 17:04:04 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Yehoshua Gev Cc: sipcore@ietf.org In-Reply-To: (yoshigev@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 29 Mar 2017 17:04:04 -0400 Message-ID: <87mvc3iym3.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfBP86kjbX7BEgWhmMrgjRTSxo71s4ldHdG79vT0e0HX3pAYIj250ikVL1lJKPQif3KOa12RTSUts435h8+PzE0h4VasuG7ML10C24cPaQGCxWl5PdQjh mmni5fkjNiowPHwQKKS4ZgJrJCuqLkDHtnllor7xoD0COHNLxTBIbOak0XkZYlIkGYqLEbt53x5OBehQFJTsuXxNTPH6VwqB6HA= Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-name-addr-guidance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 21:04:10 -0000 Yehoshua Gev writes: >> > The examples of: >> > Refer-To: sip:123@host?Replaces=1111 >> > Refer-To: sip:123@host;user=phone?Replaces=1111 > I believe that the examples above are not valid according to the BNF - > that of RFC 3515, not of 3261: > Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * > (SEMI generic-param) > This BNF does not allow for a question mark after the name-addr. > So, the interpreting the string "sip:123@host" as the addr-spec alone, > renders the > header non-parsable by the BNF of 3515. Yes... but if you're only considering the BNF, "sip:123@host?Replaces=1111" can be parsed as an addr-spec, so the header is valid (by the BNF alone). (Actually, even "sip:123@host" can't be parsed as a name-addr, because it doesn't have "<...>".) > Given so, IMHO the disambiguation rule should be stated as a normative text. Well, in section 2 of draft-ietf-sipcore-name-addr-guidance-00, it says: This text from the introduction to section 20 of [RFC3261]: ... is replaced with: When constructing the value of any SIP header field whose grammar allows choosing between name-addr and addr-spec, such as those that use the form '(name-addr / addr-spec)', the "addr-spec" form MUST NOT be used if its value would contain a comma, semicolon, or question mark. ... So, yes, the new disambiguation rule is stated as a normative text. Dale From nobody Thu Mar 30 03:57:19 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931A31293F5 for ; Thu, 30 Mar 2017 03:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rncxR1_KH5Fk for ; Thu, 30 Mar 2017 03:57:15 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3A7129471 for ; Thu, 30 Mar 2017 03:57:15 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id p22so35957523qka.3 for ; Thu, 30 Mar 2017 03:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ttsHzhrYQz9YwQbQ/92vmr8Av5f8nm4Sw60OuIRKD+M=; b=n9xUGatsfwz22+ozAqFQKS8gGS3lsugdVsh8rEa3iRCy33CZXRzrcVm5/oWRp3d9LL I8fygqEOo2O5uitgxFG3tGiX1XFvN0525oBDu7KUbZjcphabeHQ0G1OwHS+Bv/w/xaK/ SUN9YqsE1MInJmyFEgKVweK5D95s7aftPgfU2p6yEcL5ApbqePbo2mvY/MM81gVZpxx/ OKPB+HCMsq02XoBVCKxRzFMoA5lA2iCtryMI+YAyjt2jkYAKnMXkEr3FDDdbQImIRNrA 8MOTFYPV0s1Cb3qRgvXAgydoCnI65tYBwYYzQOc3CElO/HP2yebTELTjIOQGqVwMZEwR ELDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ttsHzhrYQz9YwQbQ/92vmr8Av5f8nm4Sw60OuIRKD+M=; b=ZxH1KFdHybdhpzbtZjY9xnXYc9Cd48zg51NaLsHPsuR614EiYWcf2xndlsfMQleBXI 5BIublT/Dax/iymkY0/2XWkr5vV/XXFtcYkAtsPkEzIRpXGG+mGdzyo43HBRy4PQ1jj/ Pb1PjtoJUFWymwoCSPTF4/VNb8r7Lnp9i3Qbxwpoik233G4g6+JAsHN6bfaFaE6ujL5Q OvetpZgljTJ6UG6jHYD9Xnk86yw1pfF7GjZdtzZZl+Dd/TW5JvxZt8rxsfKNuvR2KdMN dVfUsQhHt8uwo2Wbb2jWdkT1ZIpIY8S3ijj48Q4iuBtDGtwkk2+BNvYS+BZW+CkjF+sn 0QoA== X-Gm-Message-State: AFeK/H3+9QiqUdMvdcIpn+dpnw5x2dZP7avARnEg7NxC90wGzwkILWwveDC+XCW8Au/PhytbrfWUyc8nVTJClg== X-Received: by 10.55.165.11 with SMTP id o11mr5111430qke.193.1490871434741; Thu, 30 Mar 2017 03:57:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.150.171 with HTTP; Thu, 30 Mar 2017 03:57:14 -0700 (PDT) In-Reply-To: <87mvc3iym3.fsf@hobgoblin.ariadne.com> References: <87mvc3iym3.fsf@hobgoblin.ariadne.com> From: Yehoshua Gev Date: Thu, 30 Mar 2017 13:57:14 +0300 Message-ID: To: "Dale R. Worley" Cc: sipcore Content-Type: multipart/alternative; boundary=001a114d8fdc461039054bf08e17 Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-name-addr-guidance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 10:57:18 -0000 --001a114d8fdc461039054bf08e17 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 30, 2017 at 12:04 AM, Dale R. Worley wrote: > Yehoshua Gev writes: > >> > The examples of: > >> > Refer-To: sip:123@host?Replaces=1111 > >> > Refer-To: sip:123@host;user=phone?Replaces=1111 > > > So, the interpreting the string "sip:123@host" as the addr-spec alone, > > renders the > > header non-parsable by the BNF of 3515. > > Yes... but if you're only considering the BNF, > "sip:123@host?Replaces=1111" can be parsed as an addr-spec, so the > header is valid (by the BNF alone). (Actually, even "sip:123@host" > can't be parsed as a name-addr, because it doesn't have "<...>".) Ok. I see your point. So when parsing header like "Refer-To: sip:123@host;user=phone", the BNF parser will give two possible interpretation, and the non-BNF restriction will rule out one of them. And for "Refer-To: sip:123@host?Replaces=1111", the BNF parser will give one possible interpretation, which will be ruled out by the restriction. I believe my first understanding was that the restriction is applied to addr-spec, disallowing it from having uri-parameters/headers. And if the restriction if applied after parsing the add-spec, prior to parsing the rest of the Refer-To header, it will make the header syntactically invalid. But I guess it's a philosophical question. > > Given so, IMHO the disambiguation rule should be stated as a normative > text. > ... > So, yes, the new disambiguation rule is stated as a normative text. The normative text in the draft only considers the "construction" of the header, it doesn't handle parsing/interpretation of a "constructed" header. Specifically, a sentence like "If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters" (from RFC 3261 section 20) is missing. I suggest adding a text like: "If the URI in such headers is not enclosed in angle brackets, any characters after a comma, a question mark, or a semicolon SHOULD NOT be parsed as part of the URI". Alternatively: "When a URI is part of addr-spec which is not part of name-addr, the addr-spec SHOULD NOT be parsed to include a comma, a question mark, or a semicolon". Thanks, Yehoshua --001a114d8fdc461039054bf08e17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 30, 2017 at 12:04 AM, Dale R. Worley <worley@ariadne.com>= wrote:
Yehoshua Gev <yosh= igev@gmail.com> writes:
>> > The examples of:
>> >=C2=A0 =C2=A0 Refer-To: sip:123@host?Replaces=3D1111
>> >=C2=A0 =C2=A0 Refer-To: sip:123@host;user=3Dphone?Replace= s=3D1111

> So, the interpreting the string &quo= t;sip:123@host" as the addr-spec alone,
> renders the
> header non-parsable by the BNF of 3515.

Yes... but if you're only considering the BNF,
"sip:123@host?Replaces=3D1111" can be parsed as an addr-spec, so = the
header is valid (by the BNF alone).=C2=A0 (Actually, even "sip:123@hos= t"
can't be parsed as a name-addr, because it doesn't have "<.= ..>".)

Ok. I see your point.
So when = parsing header like =C2=A0"Refer-To: sip:123@host;user=3Dphone",<= br>the BNF parser will give two possible interpretation, and the
non-BNF= restriction will rule out one of them.
And for "Refer-To: sip:123@= host?Replaces=3D1111", the BNF parser will
give one possible interp= retation, which will be ruled out by the restriction.

I believe my f= irst understanding was that the restriction is applied to
addr-spec, dis= allowing it from having uri-parameters/headers.
And if the restriction i= f applied after parsing the add-spec, prior to parsing
the rest of the R= efer-To header, it will make the header syntactically invalid.
But I gue= ss it's a philosophical question.

=C2=A0
> Given so, IMHO the disambiguation rule should be stated as a normative= text.
...
So, yes, the new disambiguation rule is stated as a normative text.=C2=A0

The normative text in the draft only conside= rs the "construction" of the header,
it doesn't han= dle parsing/interpretation of a "constructed" header.
S= pecifically, a sentence like "If the = URI is not enclosed in angle=C2=A0b= rackets,
any semicolon-de= limited parameters are header-parameters,=C2=A0not URI
param= eters" (from=C2=A0RFC=C2=A0326= 1 section 20) is missing.

I suggest adding = a text like:
"If the URI in such headers is not enclosed= in angle brackets, any characters
after a comma, a question mark= , or a semicolon SHOULD NOT be parsed as
part of the URI".
Alternatively:
"When a URI is part of addr-spec whi= ch is not part of name-addr, the addr-spec
SHOULD NOT be parsed t= o include a comma, a question mark, or a semicolon".

Thanks,
Yehoshua

--001a114d8fdc461039054bf08e17-- From nobody Thu Mar 30 13:31:50 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49141294A2 for ; Thu, 30 Mar 2017 13:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkQhCx0bTGLE for ; Thu, 30 Mar 2017 13:31:37 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28A412945E for ; Thu, 30 Mar 2017 13:31:32 -0700 (PDT) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-03v.sys.comcast.net with SMTP id tgifcO8JkfuM3tgjEcPB4P; Thu, 30 Mar 2017 20:31:32 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-03v.sys.comcast.net with SMTP id tgjCcfvMyVzqStgjDcgqve; Thu, 30 Mar 2017 20:31:31 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2UKVUPB002027 for ; Thu, 30 Mar 2017 16:31:30 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2UKVTL2002022; Thu, 30 Mar 2017 16:31:29 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-Reply-To: <87a886lh6y.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 30 Mar 2017 16:31:29 -0400 Message-ID: <87efxeh5ge.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfLhSQ+ErpsCUJ2fFcoZr5LiPoB1nKme5wYJWQ5y7yOv//O+MGB/pGo4qRnAF3d03TDdBCH31Kr06QhSaILiiwRt18YDD31twyOAsoQV+oTYo1g/PydvV mRXMsUAKu+QJdyq+U8mxcjqlnqz1n/RkJ38m2hjB//8oVWYhY3waAMOE Archived-At: Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 20:31:44 -0000 worley@ariadne.com (Dale R. Worley) writes: > As far as I can tell, RFC 3326 envisions that Reason headers can be > included in responses but doesn't specify how they are processed. OTOH, > it seems to me that the odds are good that most proxies propagate > backward Reason headers in failure responses, so Reason would be a good > choice for carrying additional information. Actually, if/when we define a "protocol" value for Response to be used with "666" responses, we should just add a normative change to 3261 that when a proxy chooses as "best response" a response with a Reason header, it must propagate the Reason header. Dale From nobody Thu Mar 30 15:22:02 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA911293EE for ; Thu, 30 Mar 2017 15:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qsBRheKWwY8 for ; Thu, 30 Mar 2017 15:21:58 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63DDE127071 for ; Thu, 30 Mar 2017 15:21:58 -0700 (PDT) Received: from dhcp-9177.meeting.ietf.org (dhcp-9177.meeting.ietf.org [31.133.145.119]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v2UMLvHi085687 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 30 Mar 2017 17:21:58 -0500 (CDT) (envelope-from mahoney@nostrum.com) To: sipcore@ietf.org References: <25855_1489353730_58C5BC02_25855_10494_1_8B970F90C584EA4E97D5BAAC9172DBB81C935BDC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: "A. Jean Mahoney" Message-ID: <58b9213c-1fb1-95f7-6888-60f7a754fc4f@nostrum.com> Date: Thu, 30 Mar 2017 17:21:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <25855_1489353730_58C5BC02_25855_10494_1_8B970F90C584EA4E97D5BAAC9172DBB81C935BDC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-parameter-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 22:22:00 -0000 Hi all, I mentioned this draft during the WG session today. Does anyone have any comments on the draft? Should it become a WG document? Thanks! Jean On 3/12/17 4:22 PM, marianne.mohali@orange.com wrote: > Hi all, > > Please find hereafter a new version of I-D, > draft-mohali-sipcore-originating-cdiv-parameter-00 (was > draft-mohali-dispatch-originating-cdiv-parameter-03). > https://www.ietf.org/internet-drafts/draft-mohali-sipcore-originating-cdiv-parameter-00.txt > > Based on ADs and Chairs guidance, this draft is moved from DISPATCH > to SIPCORE following the new charter of sipcore WG. > > Abstract: This specification defines a new parameter of the > P-Served-User header field in the Session Initiation Protocol (SIP). > This new "orig-cdiv" parameter defines the session case used by a > proxy when handling an originating session after Call Diversion > (CDIV) services has been invoked for the served user. The > P-Served-User header field is defined in RFC5502 to convey the > identity of the served user and the session case that applies to this > particular communication session and application invocation. This > document updates RFC5502 to add the "originating after CDIV" session > case and to provide more guidance for using the P-Served-User header > field in IP networks that were missing in RFC5502. > >> From the discussion in DISPATCH, in this version of the draft, the >> syntax of the header could be improved as shown below: > > sessioncase-param = ("sescase" EQUAL ("orig" / "term")) / > "orig-cdiv" registration-state-param = "regstate" EQUAL ("unreg" / > "reg") > > This draft is not in the agenda for IETF 98 but comments are welcomed > anyway. > > Best regards, Marianne > > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. If you have > received this email in error, please notify the sender and delete > this message and its attachments. As emails may be altered, Orange is > not liable for messages that have been modified, changed or > falsified. Thank you. > > _______________________________________________ sipcore mailing list > sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Mar 30 16:33:29 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCC412940A for ; Thu, 30 Mar 2017 16:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wqneWDLGnZh for ; Thu, 30 Mar 2017 16:33:27 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91FEB129495 for ; Thu, 30 Mar 2017 16:33:26 -0700 (PDT) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-04v.sys.comcast.net with SMTP id tjZ8cG4m4scBPtjZFc7CEP; Thu, 30 Mar 2017 23:33:25 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-03v.sys.comcast.net with SMTP id tjZEcgZeiVzqStjZFchEdf; Thu, 30 Mar 2017 23:33:25 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2UNXOKK020862 for ; Thu, 30 Mar 2017 19:33:24 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2UNXNEE020859; Thu, 30 Mar 2017 19:33:23 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 30 Mar 2017 19:33:23 -0400 Message-ID: <8737dugx18.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfDlN0y39RDNiwBcy315A3iiT2ljantU03em+fPybgKASUv7kNJ5O7cee4guw4Ek30pnDN77XzKa1ZN2CL5PczFPIaSftWuzovezEWnBiUN4EdNivYqn0 RluPCyTNqPHcB49ZaaLgRMKvls5s3hPaNVTo/xesI4vj1MQh1+j20Zh1 Archived-At: Subject: [sipcore] Comments on draft-winterbottom-sipcore-locparam-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 23:33:28 -0000 * Technical issues A. Should this draft explicitly update this statement in RFC 6442? A SIP intermediary SHOULD NOT add location to a SIP request that already contains location. B. Should the UE explicitly label its locationValue? 4. Mechanism A UE MUST NOT provide a loc-src parameter value. Is this the best choice? Might it be better to provide a way for the UE to mark a locationValue, so that a locationValue added by a new-type UE can be reliably distinguished from an old-type intermediate that adds a locationValue (perforce without a loc-src value)? C. The meaning of "token" as an other-loc-src is not defined. location-source = "loc-src=" (host / other-loc-src) other-loc-src = token D. Interpretation of location-source values. The processor that interprets the locationValues must be able to interpret the significance of the location-source values. For diagnostic purposes, a human can interpret host values easily enough. But for automatic processing, would the host values (even if they are known to be accurate) be interpretable with any reasonable amount of effort? Naively, it seems that the processor would need a list of all possible host values and their classification (unless the host names were constructed according to a rigid scheme). It's possible that ETSI has evaluated this question and determined that this interpretation of host values works well. But naively, it seems to me that the values you want for automatic processing are codes for the *roles* or *positions* within the dialog of the adders of the locationValues. While I was watching the presentation, I was remembering that I'd seen such a set of values defined somewhere, and it turns out that I was remembering the resp-location values from draft-jesske-dispatch-reason-loc-q850-00: The values to be used as location are: U for user LPN for private network serving the local user LN for public network serving the local user TN for transit network RLN for public network serving the remote user RPN for private network serving the remote user INTL for international network BI for network beyond interworking point >From this point of view, a more informative way to label locationValues is: geoloc-param =/ location-source location-source = "loc-src=" loc-src-value loc-src-value = U / LPN / LN / TN / RLN / RPN / INTL / BI / token geoloc-param =/ location-host location-host = "loc-host=" host where "loc-src" can be automatically processed without the processor understanding every possible host name, and "loc-host" very fine-grained for diagnostic and specialty processing. * Editorial issues 1. Introduction The SIP geolocation specification [RFC6442] describes a SIP header field that is used to indicate that the SIP message is conveying location information. I suggest changing 'describes a SIP header field that' to 'describes the "Geolocation" SIP header field which'. [RFC6442] stipulates that the order of location values in the geolocation header field aligns with the order in which they were added to the header field. "aligns with" is ambiguous -- is the first Geolocation header the first one that was added or is the last Geolocation header the first one that was added? From RFC 6442 section 4.1, the first Geolocation header is the first one added, so "aligns with" can be changed to "is" or "is the same as". 3. Rationale Thus it is intended to use this parameter in trust domains where Spec(T) as described in [RFC3325] exists only. I'm not sure of the exact rules for the use of the English word "only", but in this case it would be clearer to say Thus it is intended to use this parameter only in trust domains where Spec(T) as described in [RFC3325] exists. 4. Mechanism The Augmented BNF (ABNF) [RFC5234] for this parameter is shown in Figure 1. location-source = "loc-src=" (host / other-loc-src) other-loc-src = token Formally, this omits connecting location-source to the BNF for the Geolocation header, which is done by: geoloc-param =/ location-source -- If a node conforming to this specification receives a geolocation header field with a loc-src parameter containing an IP address then the parameter MUST be removed. This might be more aggressive than we want. The weakest acceptable requirement, I think, is that any conforming node MAY remove such a value and MUST ignore it in processing it. But ETSI may have operational experience to make it clear what the best approach is. Dale From nobody Thu Mar 30 19:24:04 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E01412953D for ; Thu, 30 Mar 2017 19:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGY6nVqVbfvb for ; Thu, 30 Mar 2017 19:24:01 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB971296C4 for ; Thu, 30 Mar 2017 19:23:57 -0700 (PDT) X-AuditID: c1b4fb25-ccfff70000002d78-e5-58ddbdb99ae8 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 97.5F.11640.9BDBDD85; Fri, 31 Mar 2017 04:23:55 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0339.000; Fri, 31 Mar 2017 04:23:52 +0200 From: Christer Holmberg To: "A. Jean Mahoney" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-parameter-00 Thread-Index: AQHSqaQP1kG+aX8W+EKllu6Z5u7OT6GuFtyA Date: Fri, 31 Mar 2017 02:23:52 +0000 Message-ID: <18CC656C-FA39-428F-B542-BE3FDCE8CACE@ericsson.com> References: <25855_1489353730_58C5BC02_25855_10494_1_8B970F90C584EA4E97D5BAAC9172DBB81C935BDC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <58b9213c-1fb1-95f7-6888-60f7a754fc4f@nostrum.com> In-Reply-To: <58b9213c-1fb1-95f7-6888-60f7a754fc4f@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-5B5D3A6D-D08E-4164-8403-CA5D07004FF3"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2K7me7uvXcjDJ70C1o0dK5ktfj6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJVx7dJtxoJ14RXHLt9hbWD8H9DFyMkhIWAi cXbnE8YuRi4OIYH1jBIT1nawQjhLGCXOtUxm72Lk4GATsJDo/qcNYooIaEs8Xa0O0sssoCnx aOdeJpCwsECYxO6ddiBhEYFwifmrPjNBVBtJrOiTBAmzCKhKfLz6kBXE5hWwl+h59xlq6z5G ibebtjKBJDiBEscn3mEGsRkFxCS+n1rDBLFKXOLWk/lMECeLSDy8eJoNwhaVePn4H9jFzAKT GSWm/53GDLFBUOLkzCcsExiFZyHpn4WsbhaSullAxzIL6EhMXsgIUa8tsWzha2YI21pixq+D bBC2qcTrox+hahQlpnQ/ZF/AyLGKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzCqDm75rbqD 8fIbx0OMAhyMSjy8C9zvRgixJpYVV+YeYlQBmvNow+oLjFIsefl5qUoivB3WQGnelMTKqtSi /Pii0pzU4kOM0hwsSuK8jvsuRAgJpCeWpGanphakFsFkmTg4pRoYTawa1th6mTzwSpnWZHbz wlvdC/Pfp84L7PjHsLZrxQLliVevx5TPqahQlnsy6d0tjiCHBgmu9VM/PHtR8nDDnOawc8Z9 luGmRrPa1uzrXii0TOSPaLZmWrxPsf/L36JpmWn81omhM5ueWjhXTWvV/FM0vTBDIi5I5pLB s60ZssFecqWl8ruVWIozEg21mIuKEwFEvJvLsgIAAA== Archived-At: Subject: Re: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-parameter-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 02:24:03 -0000 --Apple-Mail-5B5D3A6D-D08E-4164-8403-CA5D07004FF3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, I support it becoming a WG document, and I will participate in the work by r= eviewing and commenting. Regards, Christer=20 Sent from my iPhone > On 30 Mar 2017, at 17.22, A. Jean Mahoney wrote: >=20 > Hi all, >=20 > I mentioned this draft during the WG session today. Does anyone have any c= omments on the draft? Should it become a WG document? >=20 > Thanks! >=20 > Jean >=20 >> On 3/12/17 4:22 PM, marianne.mohali@orange.com wrote: >> Hi all, >>=20 >> Please find hereafter a new version of I-D, >> draft-mohali-sipcore-originating-cdiv-parameter-00 (was >> draft-mohali-dispatch-originating-cdiv-parameter-03). >> https://www.ietf.org/internet-drafts/draft-mohali-sipcore-originating-cdi= v-parameter-00.txt >>=20 >> Based on ADs and Chairs guidance, this draft is moved from DISPATCH >> to SIPCORE following the new charter of sipcore WG. >>=20 >> Abstract: This specification defines a new parameter of the >> P-Served-User header field in the Session Initiation Protocol (SIP). >> This new "orig-cdiv" parameter defines the session case used by a >> proxy when handling an originating session after Call Diversion >> (CDIV) services has been invoked for the served user. The >> P-Served-User header field is defined in RFC5502 to convey the >> identity of the served user and the session case that applies to this >> particular communication session and application invocation. This >> document updates RFC5502 to add the "originating after CDIV" session >> case and to provide more guidance for using the P-Served-User header >> field in IP networks that were missing in RFC5502. >>=20 >>> =46rom the discussion in DISPATCH, in this version of the draft, the >>> syntax of the header could be improved as shown below: >>=20 >> sessioncase-param =3D ("sescase" EQUAL ("orig" / "term")) / >> "orig-cdiv" registration-state-param =3D "regstate" EQUAL ("unreg" / >> "reg") >>=20 >> This draft is not in the agenda for IETF 98 but comments are welcomed >> anyway. >>=20 >> Best regards, Marianne >>=20 >>=20 >>=20 >>=20 >>=20 >> _________________________________________________________________________= ________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles >> d'alteration, Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not >> be distributed, used or copied without authorisation. If you have >> received this email in error, please notify the sender and delete >> this message and its attachments. As emails may be altered, Orange is >> not liable for messages that have been modified, changed or >> falsified. Thank you. >>=20 >> _______________________________________________ sipcore mailing list >> sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail-5B5D3A6D-D08E-4164-8403-CA5D07004FF3 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8zCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF+TCCA+GgAwIBAgIQMQ1yPcGTNYDzhYWhrkFQyDAN BgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MjAeFw0xNDExMDQxMjI4MTlaFw0xNzExMDQxMjI4MThaMG8xETAPBgNV BAoMCEVyaWNzc29uMRowGAYDVQQDDBFDaHJpc3RlciBIb2xtYmVyZzEtMCsGCSqGSIb3DQEJARYe Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tMQ8wDQYDVQQFEwZMTUZDSEgwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCMb7fHWIV9CIFYYov86NR/6ibdVV0I+ZqVLE21zQB7otFv 6DTKlVXE7iiC4HCvMhlGkg3/qFmAhAti5Z1Z7+5eEMEIP5JJEZ7fMm6BME33Bkdgg4EfJrq4FUG2 8Hw2//0qx3jZWvK2W751AmEuUJ5nkZ6F00GnzJmOhbveadC8E5keqwow9ria0/WazHiK3wxzjban oQaZIA+oCKj5YyCv8cCTaSk4pEAbXwxthJ97BaZPahsnb4EZEP08gxR5IE9NRi47Eqh6LtBjiWpa B42EmCEBxc2uIQ87tlJ0e2SvCo74rqxndXtUeaWauMjjt4DnhJdiXZY244D5J1gWssRFAgMBAAGj ggHEMIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmlj c3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNlcjApBgNVHREEIjAggR5j aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIw OjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9D UFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBRUo03/DrRAW2xpMmhN 2uGkvDgx6jAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAw DQYJKoZIhvcNAQEFBQADggIBALbwqG5inhl/xPxsuQWcH7GOUZIPAw0JlKltVQ/TlsF7ig0J1iyz ao6GsXItJ9H3WZPrCy5EQchJm7qcn2kKX8OGb+Yr53FisLR2gx+qkrQMDOdix9Was0cvIjDWjAQn EZbxz/a+dzdAP0TrwNvD8282bIy0fCt/3uoBfzMnvQG+4wG018bDunc+NCj1FkSKkSRb9fP2Z2li 65pfJcxtGIfb5zsXJZG4Gtbe0/hxlj3NccjB/zVPO7PQ+lnWmxtOiJQ2loA+62vQreUQr328XK4I HFnoU+zXiVfUN2urvvirQH7Ha70TBMa20J8Nn2aEvY6QYMEQJhAiVmNTiv4EGGv5heX5vb8yaj7p r4YIvb6D0r+pwpvfEE8YhAEWJgCZP7k5zQwhrpuSF/s+wEruXo59sq9bOCefghktc5fwDu8ved98 cifRPUnuT/c5slJJ8LjFn8d+LnGklUdFA9kLjIJVVx+TM4D/OTaRG+mPFbY2pTyR0V84PG7HLeku pNsFzcme7IBkQ+1zkb9hjz6pyiodf6rh7ph+8XHWNgzbC5PdGCANg8fVWrxqqOoEzvcUcPMy6XXJ s0JWhWas8mJdHq2kGDDEpA7BbBatmtEqziXRnYGJeQK3eMDXXtmOeBSA4y7YZ47y+CxvbknSQ5dy ghwkEq+a7ORPGVjsjtWJYJ6dMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZI hvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJv b3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmlj c3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcN AQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/yQori I+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8GoFOvtuV HNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAU bmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq5/yHaS48jCsOBAU0 TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9 dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpa mOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA141dhCy5EScOyNajrAXQupsDn vr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6MqeaTS9HchPtBvOrah/cTWzXzGj wMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUF BzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6 Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNl cjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYB BQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1Ud HwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25l cmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQE AwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+a lgzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUieg mAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGagdRc mH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/O zFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr /oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko 3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8 b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NY sjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+ 9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApICAQEwTjA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQMQ1yPcGTNYDz hYWhrkFQyDAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAzMzEwMjIzNTFaMCMGCSqGSIb3DQEJBDEWBBQ5VTNYxZLUqGGRQDOQduV2Hiyt UTBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYyAhAxDXI9wZM1gPOFhaGuQVDIMF8GCyqGSIb3DQEJEAILMVCg TjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MgIQMQ1yPcGTNYDzhYWhrkFQyDANBgkqhkiG9w0BAQEFAASCAQBZxT/lzlB1hwT8DbHBSPpI ej1iOEkvCoFGJhBxLWRdQP/Q5+ciTxLfwXxdvUii1GRSEjoVWsikZLXdlqRtJBcWAQdmMdRcZ+tu Ejy70AeIGKpJcBKf8yccR7H/f3uI8tc3bghw0NyiPm6SBTNcolgX5vzAkC+xKl2T3D5OQpqHMsun HZD22eFf4Uu2co0b5gypHq+JZH5BZkRYUkNA2lc8BYXeU0C4FwcWqR39gXxebUSVCC2ASz9ECE3n GXB2AX4niVZyXutP/gqx6C/G2DMdp7JsdtH5/ay9ZPRvNc3HA4hiHdu2429K7bRFxrZRVRLlDOj+ 3OpKl1sM/LbCd8UaAAAAAAAA --Apple-Mail-5B5D3A6D-D08E-4164-8403-CA5D07004FF3-- From nobody Thu Mar 30 20:09:56 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA99126BFD for ; Thu, 30 Mar 2017 20:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8g2s7PxL028 for ; Thu, 30 Mar 2017 20:09:52 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A301C129704 for ; Thu, 30 Mar 2017 20:09:51 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v2V34p59041344; Thu, 30 Mar 2017 23:09:46 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 29hdhdsxug-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Mar 2017 23:09:46 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2V39jZd032545; Thu, 30 Mar 2017 23:09:45 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2V39ctk032460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Mar 2017 23:09:40 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 31 Mar 2017 03:09:31 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.163]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0319.002; Thu, 30 Mar 2017 23:09:31 -0400 From: "DOLLY, MARTIN C" To: Christer Holmberg , "A. Jean Mahoney" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-parameter-00 Thread-Index: AQHSqaQP1kG+aX8W+EKllu6Z5u7OT6GuFtyAgAAuLyA= Date: Fri, 31 Mar 2017 03:09:30 +0000 Message-ID: References: <25855_1489353730_58C5BC02_25855_10494_1_8B970F90C584EA4E97D5BAAC9172DBB81C935BDC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <58b9213c-1fb1-95f7-6888-60f7a754fc4f@nostrum.com> <18CC656C-FA39-428F-B542-BE3FDCE8CACE@ericsson.com> In-Reply-To: <18CC656C-FA39-428F-B542-BE3FDCE8CACE@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.40.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-30_21:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703310026 Archived-At: Subject: Re: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-parameter-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 03:09:55 -0000 AT&T Supports -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: Thursday, March 30, 2017 10:24 PM To: A. Jean Mahoney Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-par= ameter-00 Hi, I support it becoming a WG document, and I will participate in the work by = reviewing and commenting. Regards, Christer=20 Sent from my iPhone > On 30 Mar 2017, at 17.22, A. Jean Mahoney wrote: >=20 > Hi all, >=20 > I mentioned this draft during the WG session today. Does anyone have any = comments on the draft? Should it become a WG document? >=20 > Thanks! >=20 > Jean >=20 >> On 3/12/17 4:22 PM, marianne.mohali@orange.com wrote: >> Hi all, >>=20 >> Please find hereafter a new version of I-D, >> draft-mohali-sipcore-originating-cdiv-parameter-00 (was=20 >> draft-mohali-dispatch-originating-cdiv-parameter-03). >> https://www.ietf.org/internet-drafts/draft-mohali-sipcore-originating >> -cdiv-parameter-00.txt >>=20 >> Based on ADs and Chairs guidance, this draft is moved from DISPATCH=20 >> to SIPCORE following the new charter of sipcore WG. >>=20 >> Abstract: This specification defines a new parameter of the=20 >> P-Served-User header field in the Session Initiation Protocol (SIP). >> This new "orig-cdiv" parameter defines the session case used by a=20 >> proxy when handling an originating session after Call Diversion >> (CDIV) services has been invoked for the served user. The=20 >> P-Served-User header field is defined in RFC5502 to convey the=20 >> identity of the served user and the session case that applies to this=20 >> particular communication session and application invocation. This=20 >> document updates RFC5502 to add the "originating after CDIV" session=20 >> case and to provide more guidance for using the P-Served-User header=20 >> field in IP networks that were missing in RFC5502. >>=20 >>> From the discussion in DISPATCH, in this version of the draft, the=20 >>> syntax of the header could be improved as shown below: >>=20 >> sessioncase-param =3D ("sescase" EQUAL ("orig" / "term")) / >> "orig-cdiv" registration-state-param =3D "regstate" EQUAL ("unreg" / >> "reg") >>=20 >> This draft is not in the agenda for IETF 98 but comments are welcomed=20 >> anyway. >>=20 >> Best regards, Marianne >>=20 >>=20 >>=20 >>=20 >>=20 >> _____________________________________________________________________ >> ____________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 >> que les pieces jointes. Les messages electroniques etant susceptibles=20 >> d'alteration, Orange decline toute responsabilite si ce message a ete=20 >> altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not=20 >> be distributed, used or copied without authorisation. If you have=20 >> received this email in error, please notify the sender and delete=20 >> this message and its attachments. As emails may be altered, Orange is=20 >> not liable for messages that have been modified, changed or=20 >> falsified. Thank you. >>=20 >> _______________________________________________ sipcore mailing list=20 >> sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Mar 30 23:21:35 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A722128616 for ; Thu, 30 Mar 2017 23:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTxVqIDVr5av for ; Thu, 30 Mar 2017 23:21:31 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC281126B72 for ; Thu, 30 Mar 2017 23:21:30 -0700 (PDT) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs213cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Mar 2017 02:21:29 -0400 Received: from XCT116CNC.rim.net (10.65.161.216) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 31 Mar 2017 02:21:29 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Fri, 31 Mar 2017 02:21:28 -0400 From: Andrew Allen To: "A. Jean Mahoney" , Christer Holmberg CC: sipcore Thread-Topic: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-parameter-00 Thread-Index: AQHSqaQPpMEb/iRhIUmCYhwgmUEorqGue3MA////VOw= Date: Fri, 31 Mar 2017 06:21:28 +0000 Message-ID: References: <25855_1489353730_58C5BC02_25855_10494_1_8B970F90C584EA4E97D5BAAC9172DBB81C935BDC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <58b9213c-1fb1-95f7-6888-60f7a754fc4f@nostrum.com>, <18CC656C-FA39-428F-B542-BE3FDCE8CACE@ericsson.com> In-Reply-To: <18CC656C-FA39-428F-B542-BE3FDCE8CACE@ericsson.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD233A8FE7B1XMB122CNCrimnet_" MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-parameter-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 06:21:34 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD233A8FE7B1XMB122CNCrimnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also support this becoming a WG document. Sent from my BlackBerry - the most secure mobile device From: christer.holmberg@ericsson.com Sent: March 30, 2017 9:24 PM To: mahoney@nostrum.com Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-par= ameter-00 Hi, I support it becoming a WG document, and I will participate in the work by = reviewing and commenting. Regards, Christer Sent from my iPhone > On 30 Mar 2017, at 17.22, A. Jean Mahoney wrote: > > Hi all, > > I mentioned this draft during the WG session today. Does anyone have any = comments on the draft? Should it become a WG document? > > Thanks! > > Jean > >> On 3/12/17 4:22 PM, marianne.mohali@orange.com wrote: >> Hi all, >> >> Please find hereafter a new version of I-D, >> draft-mohali-sipcore-originating-cdiv-parameter-00 (was >> draft-mohali-dispatch-originating-cdiv-parameter-03). >> https://www.ietf.org/internet-drafts/draft-mohali-sipcore-originating-cd= iv-parameter-00.txt >> >> Based on ADs and Chairs guidance, this draft is moved from DISPATCH >> to SIPCORE following the new charter of sipcore WG. >> >> Abstract: This specification defines a new parameter of the >> P-Served-User header field in the Session Initiation Protocol (SIP). >> This new "orig-cdiv" parameter defines the session case used by a >> proxy when handling an originating session after Call Diversion >> (CDIV) services has been invoked for the served user. The >> P-Served-User header field is defined in RFC5502 to convey the >> identity of the served user and the session case that applies to this >> particular communication session and application invocation. This >> document updates RFC5502 to add the "originating after CDIV" session >> case and to provide more guidance for using the P-Served-User header >> field in IP networks that were missing in RFC5502. >> >>> From the discussion in DISPATCH, in this version of the draft, the >>> syntax of the header could be improved as shown below: >> >> sessioncase-param =3D ("sescase" EQUAL ("orig" / "term")) / >> "orig-cdiv" registration-state-param =3D "regstate" EQUAL ("unreg" / >> "reg") >> >> This draft is not in the agenda for IETF 98 but comments are welcomed >> anyway. >> >> Best regards, Marianne >> >> >> >> >> >> ________________________________________________________________________= _________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles >> d'alteration, Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not >> be distributed, used or copied without authorisation. If you have >> received this email in error, please notify the sender and delete >> this message and its attachments. As emails may be altered, Orange is >> not liable for messages that have been modified, changed or >> falsified. Thank you. >> >> _______________________________________________ sipcore mailing list >> sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --_000_BBF5DDFE515C3946BC18D733B20DAD233A8FE7B1XMB122CNCrimnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I also support this becoming a WG document.

Sent from my BlackBerry - the most secure mobile device
From: christer.holmberg@ericsson.com
Sent: March 30, 2017 9:24 PM
To: mahoney@nostrum.com
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Draft new: draft-mohali= -sipcore-originating-cdiv-parameter-00

Hi,

I support it becoming a WG document, and I will participate in the work by = reviewing and commenting.

Regards,
Christer

Sent from my iPhone

> On 30 Mar 2017, at 17.22, A. Jean Mahoney <mahoney@nostrum.com> = wrote:
>
> Hi all,
>
> I mentioned this draft during the WG session today. Does anyone have a= ny comments on the draft? Should it become a WG document?
>
> Thanks!
>
> Jean
>
>> On 3/12/17 4:22 PM, marianne.mohali@orange.com wrote:
>> Hi all,
>>
>> Please find hereafter a new version of I-D,
>> draft-mohali-sipcore-originating-cdiv-parameter-00 (was
>> draft-mohali-dispatch-originating-cdiv-parameter-03).
>> https://www.ietf.org/internet-drafts/draft-mohali-sipcore-originating-cdiv-= parameter-00.txt
>>
>> Based on ADs and Chairs guidance, this draft is moved from DISPATC= H
>> to SIPCORE following the new charter of sipcore WG.
>>
>> Abstract: This specification defines a new parameter of the
>> P-Served-User header field in the Session Initiation Protocol (SIP= ).
>> This new "orig-cdiv" parameter defines the session case = used by a
>> proxy when handling an originating session after Call Diversion >> (CDIV) services has been invoked for the served user.  The >> P-Served-User header field is defined in RFC5502 to convey the
>> identity of the served user and the session case that applies to t= his
>> particular communication session and application invocation. = This
>> document updates RFC5502 to add the "originating after CDIV&q= uot; session
>> case and to provide more guidance for using the P-Served-User head= er
>> field in IP networks that were missing in RFC5502.
>>
>>> From the discussion in DISPATCH, in this version of the draft,= the
>>> syntax of the header could be improved as shown below:
>>
>> sessioncase-param        =3D (&= quot;sescase" EQUAL ("orig" / "term")) /
>> "orig-cdiv" registration-state-param =3D "regstate&= quot; EQUAL ("unreg" /
>> "reg")
>>
>> This draft is not in the agenda for IETF 98 but comments are welco= med
>> anyway.
>>
>> Best regards, Marianne
>>
>>
>>
>>
>>
>> __________________________________________________________________= _______________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations=
>> confidentielles ou privilegiees et ne doivent donc pas etre diffus= es,
>> exploites ou copies sans autorisation. Si vous avez recu ce messag= e
>> par erreur, veuillez le signaler a l'expediteur et le detruire ain= si
>> que les pieces jointes. Les messages electroniques etant susceptib= les
>> d'alteration, Orange decline toute responsabilite si ce message a = ete
>> altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should n= ot
>> be distributed, used or copied without authorisation. If you have<= br> >> received this email in error, please notify the sender and delete<= br> >> this message and its attachments. As emails may be altered, Orange= is
>> not liable for messages that have been modified, changed or
>> falsified. Thank you.
>>
>> _______________________________________________ sipcore mailing li= st
>> sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore
>>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.= ietf.org/mailman/listinfo/sipcore
 --_000_BBF5DDFE515C3946BC18D733B20DAD233A8FE7B1XMB122CNCrimnet_-- From nobody Fri Mar 31 00:19:38 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03435127599 for ; Fri, 31 Mar 2017 00:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pihKP8tEqal3 for ; Fri, 31 Mar 2017 00:19:34 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9230D1205D3 for ; Fri, 31 Mar 2017 00:19:33 -0700 (PDT) X-AuditID: c1b4fb25-0b71498000002d78-cc-58de0303a398 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 5D.DD.11640.3030ED85; Fri, 31 Mar 2017 09:19:31 +0200 (CEST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.66) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 31 Mar 2017 09:19:57 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jsirPwhwkpwn5F3VC5m89GYqTVSabKz29lXIwE+qGUE=; b=PKhcsWlQ9HAnOpik8F6wKduJXaY83LKMFfuMT7P/J/dDlNCQZF5nSRpj0Z+XstCFcwb3EO88kd59RZh4i65f3dgcztU/vFI350itlFKKCwedTNTOjiAZWpBoLBnb2pouB0IXpTLx/Z6FYoqXJaom1PKkuTWkcZeFJe3ANR5l0QA= Received: from DB4PR07MB0685.eurprd07.prod.outlook.com (10.141.44.27) by DB4PR07MB0687.eurprd07.prod.outlook.com (10.141.45.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Fri, 31 Mar 2017 07:19:30 +0000 Received: from DB4PR07MB0685.eurprd07.prod.outlook.com ([fe80::242f:cf81:8a0a:6b6d]) by DB4PR07MB0685.eurprd07.prod.outlook.com ([fe80::242f:cf81:8a0a:6b6d%15]) with mapi id 15.01.1005.015; Fri, 31 Mar 2017 07:19:30 +0000 From: Atle Monrad To: "mahoney@nostrum.com" , Christer Holmberg , "aallen@blackberry.com" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-parameter-00 Thread-Index: AQHSqaQebBytkeOmsEet7aXRZ9HvIqGuOGQAgABCYwCAABA2YQ== Date: Fri, 31 Mar 2017 07:19:29 +0000 Message-ID: References: <25855_1489353730_58C5BC02_25855_10494_1_8B970F90C584EA4E97D5BAAC9172DBB81C935BDC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <58b9213c-1fb1-95f7-6888-60f7a754fc4f@nostrum.com>, <18CC656C-FA39-428F-B542-BE3FDCE8CACE@ericsson.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=none action=none header.from=ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.36.80.8] x-microsoft-exchange-diagnostics: 1; DB4PR07MB0687; 7:B+aL5rUK7Dsb/yzxhQFy1VUsGJFwXUTwdzd+OsqTCB+cpcRjPMJj0qQL9WdSTbWt0fvDB9ZnY4eg+dv3nTAw44vGo1vAVOpBrtRXMjF0SUEqGokFNR2qug+BeZOlEnosKDVxZ2pyZcljGAAUU3NjmRMJsZW+N1ad3hsrH3pwyP1K8DhYJq5AkQ8yk/M6Xi1rxEMUyn5ce6UpMy1vKR8oRb9aX/18WGE7fY7ZheE/HpApxIpWYZYSKFrKikiRNtd5SHZDgVGzOG03fIxWnbvmkydA20w6+CVBCPXmToYe4JagSDWGp+1Gp738/v/G9941iuhmlhatsCrCxONEQSf3gg== x-ld-processed: 92e84ceb-fbfd-47ab-be52-080c6b87953f,ExtAddr x-ms-office365-filtering-correlation-id: 5dd23cc6-8eb2-4fab-f67e-08d4780645c3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB0687; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006093)(93001093)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:DB4PR07MB0687; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB0687; x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39850400002)(39400400002)(39410400002)(39450400003)(377454003)(24454002)(13464003)(53754006)(236005)(9686003)(6306002)(229853002)(99286003)(55016002)(25786009)(53546009)(3660700001)(4326008)(2950100002)(7696004)(54896002)(93886004)(6436002)(3280700002)(33656002)(6506006)(606005)(5250100002)(2501003)(230783001)(5890100001)(53936002)(2900100001)(5003630100001)(5660300001)(9886003)(7906003)(74316002)(7736002)(189998001)(81166006)(8936002)(6246003)(8676002)(38730400002)(2906002)(3846002)(6116002)(102836003)(86362001)(66066001)(50986999)(76176999)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB0687; H:DB4PR07MB0685.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB068577971D6F511E726F52E680370DB4PR07MB0685eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 07:19:29.9578 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB0687 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0iTYRTGeb/L9jkcvs2pJy9Eg6hM7QoKSd4ijQj6I9YyoZZ+qKlz7TPL olhR4szS6KYzdcI0L3nBCyplrilqYpokGeLKcpGaWFaitpDcPgX/+53nOTznnJeXISXNtCeT qEpjNSplskwgogoULeH+JPlRsat6ZnPQp+JmFKTVVdJB84sNglAySq+tEUYZjUtElL7NSh0j o0XBcWxyYjqr2XngjChhutRAq5djL1lzv9FadF+ejZwYwPtgvmdIkI1EjATXIdCVV64WvQhG BrNJe0HhOyT8LK+leOcBAc2WxdW2CQTGrk7aHibAfjCwNEbbDSnOR7A8OUXYDRJvhy9t7Q52 xXK4VfmZsrMUn4CSqt8Ez+HQYdE5gii8BUZHukk7i3EMtFfaCH5aAwE57/VCu+GED8PY1zIH I+wOC33PVod5wKi1hODPw2B8MUjy7AZTE8s0338PQWajP6/7wZsRK+J5E2gr5hwXAM4hoXxS R/FGMOTffrwadBSyTT9WmpgVvgbVvSd5OQk+mFoRL5+C0jkvPmaIgL6htR28YfZJG+KNCRoe VTVRechXv25vnlNhpmJEqHc8wAZ4XWCleN0PDM9/CXjeAeWl38k17jdNEOt1AxJWITeO5c6m xO/ZG8BqEmM5LlUVoGLTGtDKZ3rVZNvSit7NhJkRZpDMWWyItCgktDKdy0gxI2BImVSctX9F EscpMy6zmtTTmgvJLGdGXgwl8xCHvXyrkOB4ZRqbxLJqVrPmEoyTpxb5yAqjSkMGPW7ortuK 5L4DPeojKf3DeNC9zFkV4Vq3VXV3+mp778EyC+16SB2aZ/Zu/HtecHO8aCnQJVC/8bim7ZzE mCAp7Ij26XyYTsZcrJk22bpLgp5K6wPlmQuzLgW1KVda/mxzbu0xRES6OBcNF6ePh+QaG7ps HVn1If98ZBSXoNztS2o45X862sfESAMAAA== Archived-At: Subject: Re: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-parameter-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 07:19:37 -0000 --_000_DB4PR07MB068577971D6F511E726F52E680370DB4PR07MB0685eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I also support the draft becoming a WG document. /atle Sent from my Android phone using Symantec TouchDown (www.symantec.com) -----Original Message----- From: Andrew Allen [aallen@blackberry.com] Received: fredag, 31 mar. 2017, 8:22 To: A. Jean Mahoney [mahoney@nostrum.com]; Christer Holmberg [christer.holm= berg@ericsson.com] CC: sipcore [sipcore@ietf.org] Subject: Re: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-par= ameter-00 I also support this becoming a WG document. Sent from my BlackBerry - the most secure mobile device From: christer.holmberg@ericsson.com Sent: March 30, 2017 9:24 PM To: mahoney@nostrum.com Cc: sipcore@ietf.org Subject: Re: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-par= ameter-00 Hi, I support it becoming a WG document, and I will participate in the work by = reviewing and commenting. Regards, Christer Sent from my iPhone > On 30 Mar 2017, at 17.22, A. Jean Mahoney wrote: > > Hi all, > > I mentioned this draft during the WG session today. Does anyone have any = comments on the draft? Should it become a WG document? > > Thanks! > > Jean > >> On 3/12/17 4:22 PM, marianne.mohali@orange.com wrote: >> Hi all, >> >> Please find hereafter a new version of I-D, >> draft-mohali-sipcore-originating-cdiv-parameter-00 (was >> draft-mohali-dispatch-originating-cdiv-parameter-03). >> https://www.ietf.org/internet-drafts/draft-mohali-sipcore-originating-cd= iv-parameter-00.txt >> >> Based on ADs and Chairs guidance, this draft is moved from DISPATCH >> to SIPCORE following the new charter of sipcore WG. >> >> Abstract: This specification defines a new parameter of the >> P-Served-User header field in the Session Initiation Protocol (SIP). >> This new "orig-cdiv" parameter defines the session case used by a >> proxy when handling an originating session after Call Diversion >> (CDIV) services has been invoked for the served user. The >> P-Served-User header field is defined in RFC5502 to convey the >> identity of the served user and the session case that applies to this >> particular communication session and application invocation. This >> document updates RFC5502 to add the "originating after CDIV" session >> case and to provide more guidance for using the P-Served-User header >> field in IP networks that were missing in RFC5502. >> >>> From the discussion in DISPATCH, in this version of the draft, the >>> syntax of the header could be improved as shown below: >> >> sessioncase-param =3D ("sescase" EQUAL ("orig" / "term")) / >> "orig-cdiv" registration-state-param =3D "regstate" EQUAL ("unreg" / >> "reg") >> >> This draft is not in the agenda for IETF 98 but comments are welcomed >> anyway. >> >> Best regards, Marianne >> >> >> >> >> >> ________________________________________________________________________= _________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles >> d'alteration, Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not >> be distributed, used or copied without authorisation. If you have >> received this email in error, please notify the sender and delete >> this message and its attachments. As emails may be altered, Orange is >> not liable for messages that have been modified, changed or >> falsified. Thank you. >> >> _______________________________________________ sipcore mailing list >> sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --_000_DB4PR07MB068577971D6F511E726F52E680370DB4PR07MB0685eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi
I also support the draft becoming a WG document.

/atle


Sent from my Android phone using Symantec TouchDown (www.symantec.com)

-----Original Message-----
From: Andrew Allen [aallen@blackberry.com]
Received: fredag, 31 mar. 2017, 8:22
To: A. Jean Mahoney [mahoney@nostrum.com]; Christer Holmberg [christ= er.holmberg@ericsson.com]
CC: sipcore [sipcore@ietf.org]
Subject: Re: [sipcore] Draft new: draft-mohali-sipcore-originating-c= div-parameter-00

I also support this becoming a WG document.

Sent from my BlackBerry - the most secure mobile device
From: christer.holmberg@ericsson.com
Sent: March 30, 2017 9:24 PM
To: mahoney@nostrum.com
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Draft new: draft-mohali= -sipcore-originating-cdiv-parameter-00

Hi,

I support it becoming a WG document, and I will participate in the work by = reviewing and commenting.

Regards,
Christer

Sent from my iPhone

> On 30 Mar 2017, at 17.22, A. Jean Mahoney <mahoney@nostrum.com> = wrote:
>
> Hi all,
>
> I mentioned this draft during the WG session today. Does anyone have a= ny comments on the draft? Should it become a WG document?
>
> Thanks!
>
> Jean
>
>> On 3/12/17 4:22 PM, marianne.mohali@orange.com wrote:
>> Hi all,
>>
>> Please find hereafter a new version of I-D,
>> draft-mohali-sipcore-originating-cdiv-parameter-00 (was
>> draft-mohali-dispatch-originating-cdiv-parameter-03).
>> https://www.ietf.org/internet-drafts/draft-mohali-sipcore-originating-cdiv-= parameter-00.txt
>>
>> Based on ADs and Chairs guidance, this draft is moved from DISPATC= H
>> to SIPCORE following the new charter of sipcore WG.
>>
>> Abstract: This specification defines a new parameter of the
>> P-Served-User header field in the Session Initiation Protocol (SIP= ).
>> This new "orig-cdiv" parameter defines the session case = used by a
>> proxy when handling an originating session after Call Diversion >> (CDIV) services has been invoked for the served user.  The >> P-Served-User header field is defined in RFC5502 to convey the
>> identity of the served user and the session case that applies to t= his
>> particular communication session and application invocation. = This
>> document updates RFC5502 to add the "originating after CDIV&q= uot; session
>> case and to provide more guidance for using the P-Served-User head= er
>> field in IP networks that were missing in RFC5502.
>>
>>> From the discussion in DISPATCH, in this version of the draft,= the
>>> syntax of the header could be improved as shown below:
>>
>> sessioncase-param        =3D (&= quot;sescase" EQUAL ("orig" / "term")) /
>> "orig-cdiv" registration-state-param =3D "regstate&= quot; EQUAL ("unreg" /
>> "reg")
>>
>> This draft is not in the agenda for IETF 98 but comments are welco= med
>> anyway.
>>
>> Best regards, Marianne
>>
>>
>>
>>
>>
>> __________________________________________________________________= _______________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations=
>> confidentielles ou privilegiees et ne doivent donc pas etre diffus= es,
>> exploites ou copies sans autorisation. Si vous avez recu ce messag= e
>> par erreur, veuillez le signaler a l'expediteur et le detruire ain= si
>> que les pieces jointes. Les messages electroniques etant susceptib= les
>> d'alteration, Orange decline toute responsabilite si ce message a = ete
>> altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should n= ot
>> be distributed, used or copied without authorisation. If you have<= br> >> received this email in error, please notify the sender and delete<= br> >> this message and its attachments. As emails may be altered, Orange= is
>> not liable for messages that have been modified, changed or
>> falsified. Thank you.
>>
>> _______________________________________________ sipcore mailing li= st
>> sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore
>>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.= ietf.org/mailman/listinfo/sipcore
--_000_DB4PR07MB068577971D6F511E726F52E680370DB4PR07MB0685eurp_-- From nobody Fri Mar 31 05:30:00 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49904129735 for ; Fri, 31 Mar 2017 05:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvebQZlwNq-8 for ; Fri, 31 Mar 2017 05:29:55 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C819A12966F for ; Fri, 31 Mar 2017 05:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1490963395; x=1522499395; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TK940egS9JVTmSPdcuAxZKM0SK/TmPVWTtLTgel9dXI=; b=y6YNrLBPApEwbAsTU+F8M9kP9CTWIWogIv/7OyJt/kl6Tj20FFwy9L96 gut6E5XngHqPcFSr8BdYPxNFQvG1jeZ3z0opJwKJdrj2UUSJRy4PyWS5K lgcHDfql5nhQPBbCTqylz1h1l3T57DlTactPVIbzeC2bZiEw7V5p6r8KL AFliq/WJi476p2afNG6fmmyzahDsySpJsAcEn1YeYQqS4xhBVzTUmo74H jdYFnsgbE4XN0VrDwGNSI9pJOTAJ8dbTQiGF9n0Tg65RmNZ/exw9z+DjV G+rob/HAzhsooAxwbaXMfZyjDEkv6tCq24iihF0/yT7ogylNjOjBZ0rOy g==; Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT21.telekom.de with ESMTP/TLS/RC4-SHA; 31 Mar 2017 14:29:47 +0200 X-IronPort-AV: E=Sophos;i="5.36,251,1486422000"; d="scan'208";a="646599719" Received: from he105829.emea1.cds.t-internal.com ([10.169.119.32]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 31 Mar 2017 14:29:35 +0200 Received: from HE105828.EMEA1.cds.t-internal.com (10.169.119.31) by HE105829.emea1.cds.t-internal.com (10.169.119.32) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 31 Mar 2017 14:29:26 +0200 Received: from HE105828.EMEA1.cds.t-internal.com ([fe80::753e:c05:6c77:b585]) by HE105828.emea1.cds.t-internal.com ([fe80::753e:c05:6c77:b585%26]) with mapi id 15.00.1263.000; Fri, 31 Mar 2017 14:29:26 +0200 From: To: , Thread-Topic: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-parameter-00 Thread-Index: AQHSqaQWpesEhUHcIkeKIYpECUFQFaGu4YUw Date: Fri, 31 Mar 2017 12:29:25 +0000 Message-ID: References: <25855_1489353730_58C5BC02_25855_10494_1_8B970F90C584EA4E97D5BAAC9172DBB81C935BDC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <58b9213c-1fb1-95f7-6888-60f7a754fc4f@nostrum.com> In-Reply-To: <58b9213c-1fb1-95f7-6888-60f7a754fc4f@nostrum.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.213.204.57] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-parameter-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 12:29:58 -0000 Hi Jean, I have read Marianne's draft and support the draft to become a WG document. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von A. Jean Mahon= ey Gesendet: Donnerstag, 30. M=E4rz 2017 17:22 An: sipcore@ietf.org Betreff: Re: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-par= ameter-00 Hi all, I mentioned this draft during the WG session today. Does anyone have any co= mments on the draft? Should it become a WG document? Thanks! Jean On 3/12/17 4:22 PM, marianne.mohali@orange.com wrote: > Hi all, > > Please find hereafter a new version of I-D,=20 > draft-mohali-sipcore-originating-cdiv-parameter-00 (was=20 > draft-mohali-dispatch-originating-cdiv-parameter-03). > https://www.ietf.org/internet-drafts/draft-mohali-sipcore-originating- > cdiv-parameter-00.txt > > Based on ADs and Chairs guidance, this draft is moved from DISPATCH=20 > to SIPCORE following the new charter of sipcore WG. > > Abstract: This specification defines a new parameter of the=20 > P-Served-User header field in the Session Initiation Protocol (SIP). > This new "orig-cdiv" parameter defines the session case used by a=20 > proxy when handling an originating session after Call Diversion > (CDIV) services has been invoked for the served user. The=20 > P-Served-User header field is defined in RFC5502 to convey the=20 > identity of the served user and the session case that applies to this=20 > particular communication session and application invocation. This=20 > document updates RFC5502 to add the "originating after CDIV" session=20 > case and to provide more guidance for using the P-Served-User header=20 > field in IP networks that were missing in RFC5502. > >> From the discussion in DISPATCH, in this version of the draft, the=20 >> syntax of the header could be improved as shown below: > > sessioncase-param =3D ("sescase" EQUAL ("orig" / "term")) / > "orig-cdiv" registration-state-param =3D "regstate" EQUAL ("unreg" / > "reg") > > This draft is not in the agenda for IETF 98 but comments are welcomed=20 > anyway. > > Best regards, Marianne > > > > > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, Orange decline toute responsabilite si ce message a ete=20 > altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorisation. If you have=20 > received this email in error, please notify the sender and delete this=20 > message and its attachments. As emails may be altered, Orange is not=20 > liable for messages that have been modified, changed or falsified.=20 > Thank you. > > _______________________________________________ sipcore mailing list=20 > sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Mar 31 14:36:42 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF4912953F for ; Fri, 31 Mar 2017 14:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.033 X-Spam-Level: X-Spam-Status: No, score=-0.033 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbC5PEGI3WYX for ; Fri, 31 Mar 2017 14:36:38 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BF2812951B for ; Fri, 31 Mar 2017 14:36:37 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-05v.sys.comcast.net with SMTP id u4CecxepUygj9u4DkcPqij; Fri, 31 Mar 2017 21:36:36 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-01v.sys.comcast.net with SMTP id u4Djce9FnY10Nu4DkcpE8v; Fri, 31 Mar 2017 21:36:36 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2VLaYtV013999 for ; Fri, 31 Mar 2017 17:36:34 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2VLaYNc013968; Fri, 31 Mar 2017 17:36:34 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-Reply-To: <8737dugx18.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 31 Mar 2017 17:36:33 -0400 Message-ID: <87r31ddt7i.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfFRDAX6EENnvJTYzXwfq4X+LN2HAGBcq/YjtXeUsdEF2vxXuUxQzFLGDdy46eaepFu661ATJtfn0e+zZ9EoMege+SR6GRevQNS0izhUXO/0AVOhu5d5i M2y/leuSuPQX1jWt6Uz8J1H4ILsuburlvNGmCHFCAT93uHZmdqMQODb4 Archived-At: Subject: Re: [sipcore] Comments on draft-winterbottom-sipcore-locparam-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 21:36:41 -0000 worley@ariadne.com (Dale R. Worley) writes: > D. Interpretation of location-source values. I'm suggesting here that we want to change the example from Geolocation: , ; loc-src=edgeproxy.example.com to Geolocation: ; loc-src=U, ; loc-src=LN; loc-host=edgeproxy.example.com Dale