From nobody Sun Apr 2 07:47: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 8001F129481 for ; Sun, 2 Apr 2017 07:47:55 -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 TT-HlYznYkLO for ; Sun, 2 Apr 2017 07:47:53 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 B832D12948A for ; Sun, 2 Apr 2017 07:47:53 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id r203so102479686oib.3 for ; Sun, 02 Apr 2017 07:47:53 -0700 (PDT) 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=KDnC0EngSvHWJMkcc7lWdW/CIlPO7Lamj64Mjw/7kOA=; b=nzqWORFsCycFv984Hk17R1JE1gBiT2wWDYebRCDljjfsNfxUm4KxvXLB4pUAdVIVWY 7/X4nfDUFGI/ja73v9H8UQTAT06S3e0pjJaEdACm0435MAXQXmSwZyBzC505QqRgeJpG 0aOO+oWvNnLoia7CYgNtTaRCQIHu4qXMkWExJlYy8MSQ+SKi5YY9awbAP8paGxn8zmFY /I54q4Lw2SrzOXeKV40mXr5H+b39YfL8L7R2dE/aoNObumSUMvpo4n1qYsBCrA3BEuLX dl2QtMi8eI8VdsaSOf0hIcJb9XSI0rXxPMOIL/u4jIJvchIGe23qPggkSY0Tb91A/M4/ uR5g== 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=KDnC0EngSvHWJMkcc7lWdW/CIlPO7Lamj64Mjw/7kOA=; b=V9ESiMsBNIQiA/v2/DmlTnA/sggi1U5bKkR7McTlnJ794uP4VHqLwBXoBM/6CwrOgX 8/NGdthTxohV5CBDmlWno+FARdDk7rDzaSynQoD1Jwbsc1V5nhuFVNa+xcOJbijnNY1v evTsH/nUl1hPk3XZDzPXty22OfUXvoHJt+Up1HXdjmeke07zEdeUS/BifGobiy59TBtx 8aYgGw9Jg8uBURiRoIBOx7ZyqHTFkZ52K+4tidjRKNH4SELlzvpfi+VLetkakDRmXaz/ EQE90eM2lryusTth2Li3APdbVbu7dq/WBVmNjtVA9klE26DCW4vbAp1/oufUaYZNHmmx 9RoQ== X-Gm-Message-State: AFeK/H1iusOPijSAhlgHXLZbyLxNhglh9hp/XWFkHqGKQajHZGBnvYMGQelhzjDtOKj3UtHYcYvBTLmdR5rrqQ== X-Received: by 10.202.1.84 with SMTP id 81mr5998173oib.7.1491144472775; Sun, 02 Apr 2017 07:47:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.186.139 with HTTP; Sun, 2 Apr 2017 07:47:12 -0700 (PDT) From: Souma Badombena Date: Sun, 2 Apr 2017 07:47:12 -0700 Message-ID: To: sipcore@ietf.org Content-Type: multipart/alternative; boundary=001a1138ea629bd075054c30206e 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: Sun, 02 Apr 2017 14:47:55 -0000 --001a1138ea629bd075054c30206e Content-Type: text/plain; charset=UTF-8 "unwanted" as opposed to "blocked" -- "unwanted" is an enhancing functionality and allowing possible flexibility I just wanted to mention a relevant aspect where the "Unwanted" concept addresses a shortcoming and may be improved upon with subsequent parameters enrichments. For some SIP calling and messaging application there exists the concept of "contact blocking", "user blacklisting" or "personal blocking" where a user can select specific contacts or undersired identities (phone numbers, usernames, aliases etc...) to be blocked and therefore allowing the blocking user to reject calls or messages from a given blocked user. This very method or technique consists in maintaining a resource list of blocked contact and applying restrictive or rejection filters to them either a local (client) level or at network level. So in a parallel with the "SIP 666 - unwanted" solution, I notice that on one hand the "unwanted" method may be equivalent to the method or concept of blocking, but on the other hand it does potentially offer an extensible flexibility for particular cases, provided that the appropriate enhancement work is done in the future. For example in particular cases where a user may want to add more selectivity to the how the "unwanted" call instances and originators are treated, such as setting a time window or period for which the calls are unwanted or associating a geolocation aspect to calls that need to be treated as unwanted. etc.. There are several scenarios available provided that the specification provides for further extensibility combined to programmatic mechanisms or machine learning pattern building procedures. So with that being said, should we agree that the proposed SIP response code could be further extended to bear multiple contextual reason codes? Thanks. -- Souma Badombena-Wanta --001a1138ea629bd075054c30206e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

"unwanted" as opposed t= o "blocked" -- "unwanted" is an enhancing functionality= and allowing possible flexibility

I just wanted t= o mention a relevant aspect where the "Unwanted" concept addresse= s a shortcoming and may be improved upon with subsequent parameters enrichm= ents.
For some SIP calling and messaging application there exists= the concept of "contact blocking", "user blacklisting"= or "personal blocking" where a user can select specific contacts= or undersired identities (phone numbers, usernames, aliases etc...) to be = blocked and therefore allowing the blocking user to reject calls or message= s from a given blocked user. This very method or technique consists in main= taining a resource list of blocked contact and applying restrictive or reje= ction filters to them either a local (client) level or at network level. So= in a parallel with the "SIP 666 - unwanted" solution, I notice t= hat on one hand the =C2=A0"unwanted" method may be equivalent to = the method or concept of blocking, but on the other hand it does potentiall= y offer an extensible flexibility for particular cases, provided that the a= ppropriate enhancement work is done in the future. For example in particula= r cases where a user may want to add more selectivity to the how the "= unwanted" call instances and originators are treated, such as setting = a time window or period for which the calls are unwanted or associating a g= eolocation aspect to calls that need to be treated as unwanted. etc.. There= are several scenarios available provided that the specification provides f= or further extensibility combined to programmatic mechanisms or machine lea= rning pattern building procedures.=C2=A0So with that being said, should we = agree that the proposed SIP response code could be further extended to bear= multiple contextual reason codes?


Thanks.
--
Souma Badombena-Wanta

--001a1138ea629bd075054c30206e-- From nobody Sun Apr 2 08:38: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 4A880129407 for ; Sun, 2 Apr 2017 08:38:52 -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 ezafmcEu-g2q for ; Sun, 2 Apr 2017 08:38:50 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 AD0D0129353 for ; Sun, 2 Apr 2017 08:38:50 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id f193so103166308oib.2 for ; Sun, 02 Apr 2017 08:38:50 -0700 (PDT) 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=prlL4n2nv2IXO4j2mqJgPAKBNJ+CpEbl7kSluiV2fNE=; b=pjsidREmv9azH8mhiuBcKxrmq7pBTTcjysTDHmDadR8j9VZJ3dHy6qKzkgvsYxbbPi LAGALw+68pkE1CdUtadNNRAE/7uHf1FC2RZ7A2zS04hoyl6DtzaaXOEIV9mbKefiPIk7 B37nxlqIIXZAAhyO/gKn2bWqrwalqYaWjm1I+/AY9BFHRYN3A1yP51JRviIQcjDpOLqa KfDi+pc7UfF7caJkY56A0D8X2+5DFeiUS3oWGG8SFJIfH7f4bglx/yufkazIy5K17A8a zlbUUmYDr6RlsH5fQh4xC6YXAf53WMNwOrgEPUl7PiQ6AUQX7qQeydlcqnFwxosHgldv 250Q== 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=prlL4n2nv2IXO4j2mqJgPAKBNJ+CpEbl7kSluiV2fNE=; b=DpPckRzWc+qSUespZbv/OeXDuw0Wkmbu9FV1IRA+Db87CfZXFAN5O3lO8oRrZT84Sm +cAgJzui15vTxTxNfGASP2S0+YsIn4sKpMk05oH7f505Uhu5cBar4hx7Ngb4g7WcUtWV e245knUNk/vkZILktPTpKYk3nSO4P4q1CmzsgHStmF2mtNWCSmPaupYq2VcBaxtGQF2e w5T2p+VrisvlvSGxSxCkw15ud6qWXyvesiCuObkLFIhgV24+TXMr3oz5mcmSSu18kc5T pOabXdIcz8SSKXlanO7Y7Ap8/XfqJceGw3CdTi2xn6pmER52JAERxLW91y2OCk+tRpGk iCjQ== X-Gm-Message-State: AFeK/H3NF5qKwf3Fi3Sa7tuPxRppVMfNwgdC43UCrrulUvIs/8vceNeLnqMzmJwlpVq1SUil5GlyLxtJzDxLUg== X-Received: by 10.202.55.197 with SMTP id e188mr7436244oia.12.1491147529967; Sun, 02 Apr 2017 08:38:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.186.139 with HTTP; Sun, 2 Apr 2017 08:38:09 -0700 (PDT) From: Souma Badombena Date: Sun, 2 Apr 2017 08:38:09 -0700 Message-ID: To: sipcore@ietf.org Content-Type: multipart/alternative; boundary=001a113cf054d500bc054c30d6e6 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: Sun, 02 Apr 2017 15:38:52 -0000 --001a113cf054d500bc054c30d6e6 Content-Type: text/plain; charset=UTF-8 -------------------- On Further Collaborative implications for communications and telephony Mobile Applications (3GPP/MMTEL/IMS, RCS/GSMA etc..) As I'm going over this draft about SIP Call Info headers, I'm led to think about related implications and applicabilities it has with respect to telephony applications such a Rich Communications Services where the concept of Enriched Calling is available and involves such call operations versatilities and feasabilities as setting the subject or topic of calls in a pre-call phase feature along with being able to identify call types and decide whether to respond, defer, put on hold or reject etc... So I am wondering whether there could be some protocol specification application reference and examplification related to these SIP calling applications or if there could be possible a further draft upgrade which could discuss those specific cases and scenarios. I'm suspecting that various application developers and service providers may want to implement this specification and reference it for compliance and standard alignment. So I will try to follow this up with some specific examples and cases that we can discuss in details in the light of the proposed draft. Thanks, -- Souma Badombena-Wanta --001a113cf054d500bc054c30d6e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

--------------------
On Furt= her Collaborative implications for communications and telephony Mobile Appl= ications (3GPP/MMTEL/IMS, RCS/GSMA etc..)

As I'= ;m going over this draft about SIP Call Info headers, I'm led to think = about related implications and applicabilities it has with respect to telep= hony applications such a Rich Communications Services where the concept of = Enriched Calling is available and involves such call operations versatiliti= es and feasabilities as setting the subject or topic of calls in a pre-call= phase feature along with being able to identify call types and decide whet= her to respond, defer, put on hold or reject etc... So I am wondering wheth= er there could be some protocol specification application reference and exa= mplification related to these SIP calling applications or if there could be= possible a further draft upgrade which could discuss those specific cases = and scenarios.
I'm suspecting that various application develo= pers and service providers may want to implement this specification and ref= erence it for compliance and standard alignment. So I will try to follow th= is up with some specific examples and cases that we can discuss in details = in the light of the proposed draft.

Thanks,
-= -
Souma Badombena-Wanta=

--001a113cf054d500bc054c30d6e6-- From nobody Sun Apr 2 18:23: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 B7E0612940C for ; Sun, 2 Apr 2017 18:23:38 -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, 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 (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 dt51prm4yaq0 for ; Sun, 2 Apr 2017 18:23:35 -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 9B5A7128616 for ; Sun, 2 Apr 2017 18:23:34 -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 v331NUAx014448; Mon, 3 Apr 2017 01:23:30 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 29j5ceh9yt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 03 Apr 2017 01:23:30 +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=nJcNxCHpYiv8VM5cxfMm/ACpPzi/94Mqv4E8PEBPl6c=; b=LT7Xe1zSX3i6XZLFqZ3C60+f2TJdDQICVYO+tc7mXn7bh9vngKOaegRcwfHmrA5NlDYsaT8ZWFb/PzbMrfEWZjAdSmBTAcWwIDWe0DBDCiNd9omMB3GjDW50+sp8bd/4DLDH5onjurM9x6TummbgKZVWW0316E4u3KZHg8KQXBM= 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_128_CBC_SHA256_P256) id 15.1.1005.10; Mon, 3 Apr 2017 01:23:28 +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.1005.018; Mon, 3 Apr 2017 01:23:28 +0000 From: Henning Schulzrinne To: Souma Badombena , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt Thread-Index: AQHSq8dBC5vsdRwqDEmeC/dlsh2AV6Gy2KRT Date: Mon, 3 Apr 2017 01:23:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [76.111.6.188] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 7:RfbHIMNgvtosUBpYMnyf9quXwBBNuAY7Hf+z5+/SjQGG0KyZwWI2y6FqDX3K9ZFophHqN6TRWlFyxMo9cGcXbOplzZflp5Q5PIfbmZ7IMeEfs23XJxAWa0ErWH1cAoOccwY1bz9xjZYdKJIKZt2n9vHn1KOinunM+PMeMQyrOZf0OjBy8YL5exIUDaXz5f7eEwXHF/VgIIIUX7Gjknbn6IWjt1j6E8AfiI8564O2X6sZKiKitXlfh7Xc5d38a2M4kHxWv0B8sV4E0jsmxwpQepxR480FlI8DrngwuGJl09R/xlI5Ys2xsnFccWI4UqdlXbkn7IU+vQ341mcEDMqkmg== x-ms-office365-filtering-correlation-id: baefe287-909d-4fe5-7e54-08d47a300867 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR09MB0634; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201703061421075)(6072148); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(377454003)(7696004)(86362001)(2906002)(189998001)(6246003)(3660700001)(54896002)(9686003)(19627405001)(2950100002)(53936002)(3280700002)(8936002)(55016002)(2501003)(99286003)(53546009)(8676002)(39060400002)(229853002)(25786009)(66066001)(81166006)(38730400002)(77096006)(230783001)(2900100001)(76176999)(54356999)(6436002)(50986999)(6506006)(3846002)(6116002)(33656002)(5660300001)(122556002)(74316002)(102836003)(7736002); 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_CY1PR09MB063486602DD31489CE3AE9AAEA080CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2017 01:23:28.2070 (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-04-03_01:, , 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: Mon, 03 Apr 2017 01:23:39 -0000 --_000_CY1PR09MB063486602DD31489CE3AE9AAEA080CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not sure I'm quite following what you had in mind, so please feel free = to amplify if I missed the intent of your comment. At the recent IETF SIPCO= RE meeting, we briefly discussed that there is indeed a need for users to c= onfigure call behavior independent of the call, e.g., whether to block cert= ain categories of calls, make this dependent on the time of day, or whether= to apply other call treatments such as auto-forwarding to voicemail. (Give= n that speech-to-text is actually quite good these days, I find that I can = often simply glance at the text rendition to see if a call needs follow-up = or not.) However, since this type of setup is likely to be web-based and somewhat sp= ecific to the capabilities offered by each service, it's not clear that sta= ndards would be helpful here. That said, I do believe there's a gap that needs to be filled, namely per-c= all type identification by the called party, included in the "Unwanted" res= ponse. I'm considering using a new parameter, using the same call types as = for this draft, for the Reason parameter, since Call-Info is a request-only= header. Again, please let me know if I missed the intent of your comment. Henning ________________________________ From: sipcore on behalf of Souma Badombena Sent: Sunday, April 2, 2017 11:38:09 AM To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt -------------------- On Further Collaborative implications for communications and telephony Mobi= le Applications (3GPP/MMTEL/IMS, RCS/GSMA etc..) As I'm going over this draft about SIP Call Info headers, I'm led to think = about related implications and applicabilities it has with respect to telep= hony applications such a Rich Communications Services where the concept of = Enriched Calling is available and involves such call operations versatiliti= es and feasabilities as setting the subject or topic of calls in a pre-call= phase feature along with being able to identify call types and decide whet= her to respond, defer, put on hold or reject etc... So I am wondering wheth= er there could be some protocol specification application reference and exa= mplification related to these SIP calling applications or if there could be= possible a further draft upgrade which could discuss those specific cases = and scenarios. I'm suspecting that various application developers and service providers ma= y want to implement this specification and reference it for compliance and = standard alignment. So I will try to follow this up with some specific exam= ples and cases that we can discuss in details in the light of the proposed = draft. Thanks, -- Souma Badombena-Wanta --_000_CY1PR09MB063486602DD31489CE3AE9AAEA080CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I'm not sure I'm quite following what you had in mind, so please feel fr= ee to amplify if I missed the intent of your comment. At the recent IETF SI= PCORE meeting, we briefly discussed that there is indeed a need for users t= o configure call behavior independent of the call, e.g., whether to block certain categories of calls, make this= dependent on the time of day, or whether to apply other call treatments su= ch as auto-forwarding to voicemail. (Given that speech-to-text is actually = quite good these days, I find that I can often simply glance at the text rendition to see if a call needs fol= low-up or not.)


However, since this type of setup is likely to be web-based and somewhat= specific to the capabilities offered by each service, it's not clear that = standards would be helpful here.


That said, I do believe there's a gap that needs to be filled, namely pe= r-call type identification by the called party, included in the "Unwan= ted" response. I'm considering using a new parameter, using the same c= all types as for this draft, for the Reason parameter, since Call-Info is a request-only header.


Again, please let me know if I missed the intent of your comment.


Henning

From: sipcore <sipcore-b= ounces@ietf.org> on behalf of Souma Badombena <gmsoum@gmail.com> Sent: Sunday, April 2, 2017 11:38:09 AM
To: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-= 00.txt
 

--------------------
On Further Collaborative implications for communications and telephony= Mobile Applications (3GPP/MMTEL/IMS, RCS/GSMA etc..)

As I'm going over this draft about SIP Call Info headers, I'm led to t= hink about related implications and applicabilities it has with respect to = telephony applications such a Rich Communications Services where the concep= t of Enriched Calling is available and involves such call operations versatilities and feasabilities as setti= ng the subject or topic of calls in a pre-call phase feature along with bei= ng able to identify call types and decide whether to respond, defer, put on= hold or reject etc... So I am wondering whether there could be some protocol specification application reference a= nd examplification related to these SIP calling applications or if there co= uld be possible a further draft upgrade which could discuss those specific = cases and scenarios.
I'm suspecting that various application developers and service provide= rs may want to implement this specification and reference it for compliance= and standard alignment. So I will try to follow this up with some specific= examples and cases that we can discuss in details in the light of the proposed draft.

Thanks,
--
Souma Badombena-Wanta

--_000_CY1PR09MB063486602DD31489CE3AE9AAEA080CY1PR09MB0634namp_-- From nobody Sun Apr 2 18: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 E13D8120725 for ; Sun, 2 Apr 2017 18:29:43 -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, 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 (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 CVD97ek5FwsW for ; Sun, 2 Apr 2017 18:29:41 -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 0EB01126C25 for ; Sun, 2 Apr 2017 18:29:39 -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 v331TADX004401; Mon, 3 Apr 2017 01:29:35 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0048.outbound.protection.outlook.com [23.103.198.48]) by mx0b-0024ed01.pphosted.com with ESMTP id 29j460hawf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 03 Apr 2017 01:29:35 +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=vAk2GAdAYmNBcHm+WMZ/N6/Se73sRYXwRoUyCH4Uub8=; b=Cq9tCGPMw1PV23QGOb5VKYQhTIEDUkwby3ke+InF7yohIYNC+OdjICiwEDaJiaBnLaEYbqU0NKlDpupSUkZ22UR6FMguL120nozCx8E7d2IxvH7vvORF3eYAASvRpsz3YIwnBj7wvurVOUrX7WTgePOwiulsQWfyHev343OnL24= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0635.namprd09.prod.outlook.com (10.160.151.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Mon, 3 Apr 2017 01:29:33 +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.1005.018; Mon, 3 Apr 2017 01:29:33 +0000 From: Henning Schulzrinne To: Souma Badombena , "sipcore@ietf.org" Thread-Topic: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard Thread-Index: AQHSq8ADWVLgmk+Rg063/vBqcABfNqGy2m5C Date: Mon, 3 Apr 2017 01:29:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [76.111.6.188] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 7:S0ZUJaBOjW17gj+O82oRELekug6X0pSP6qLl/xBr0Wf9RdaDmwws7etyGWyuDLXoDcUelZo6g6H3Qd6Z6bhmQN2+CU2Il9rSnRokEaDy5udAurxfFixXLPFwDczCKWz9bCiFmTRr57p6Gr5RFAHUUL/KaibJ8W9ux6HSh6F8CzPMDG384x0bSWca8eOtL73ZS4ylZ5BShq5j+yD2ReBg3ccUEZiXAT6ol8ywDv117KjUHoo4rzam/SORacH6DbmvkT1T/Pwb6xX3Hl69fZMMDk78tQFlagnSDY5kx+jOLIq+t5xRzaJ2cEBeOt6jT1jokaxLuKEmdya8UnNZ/uu8GQ== x-ms-office365-filtering-correlation-id: eaac8189-c69d-4cf1-b95e-08d47a30e1df x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR09MB0635; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201703061421075)(20161123560025)(6072148); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(377454003)(51694002)(81166006)(74316002)(55016002)(19627405001)(8936002)(2900100001)(230783001)(6116002)(102836003)(3846002)(7736002)(8676002)(3660700001)(3280700002)(54896002)(50986999)(54356999)(76176999)(86362001)(6506006)(189998001)(2950100002)(77096006)(33656002)(6246003)(38730400002)(7696004)(9686003)(5660300001)(229853002)(25786009)(53936002)(122556002)(39060400002)(99286003)(53546009)(2906002)(2501003)(66066001)(6436002)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; 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_CY1PR09MB063459C304A66037805CE0C4EA080CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2017 01:29:33.1387 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-03_01:, , 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: Mon, 03 Apr 2017 01:29:44 -0000 --_000_CY1PR09MB063459C304A66037805CE0C4EA080CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This seems to be related to the previous comment. I agree that users should= have the ability to specify, either within an app or via a web interface c= ontrolling a carrier or third-party operated service, how calls are treated= . As you say, this could be fairly complex in its details, such as dependin= g on the time of day. ("Don't mind survey calls, but not after 7 pm.") I will note that many a moon ago, we actually developed a flexible XML-base= d language for call handling purposes (RFC 3880, CPL). Wouldn't be hard to = extend it for this purpose, but I suspect CPL is not among the commonly-imp= lemented SIP-related RFCs... Henning ________________________________ From: sipcore on behalf of Souma Badombena Sent: Sunday, April 2, 2017 10:47:12 AM To: sipcore@ietf.org Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard "unwanted" as opposed to "blocked" -- "unwanted" is an enhancing functional= ity and allowing possible flexibility I just wanted to mention a relevant aspect where the "Unwanted" concept add= resses a shortcoming and may be improved upon with subsequent parameters en= richments. For some SIP calling and messaging application there exists the concept of = "contact blocking", "user blacklisting" or "personal blocking" where a user= can select specific contacts or undersired identities (phone numbers, user= names, aliases etc...) to be blocked and therefore allowing the blocking us= er to reject calls or messages from a given blocked user. This very method = or technique consists in maintaining a resource list of blocked contact and= applying restrictive or rejection filters to them either a local (client) = level or at network level. So in a parallel with the "SIP 666 - unwanted" s= olution, I notice that on one hand the "unwanted" method may be equivalent= to the method or concept of blocking, but on the other hand it does potent= ially offer an extensible flexibility for particular cases, provided that t= he appropriate enhancement work is done in the future. For example in parti= cular cases where a user may want to add more selectivity to the how the "u= nwanted" call instances and originators are treated, such as setting a time= window or period for which the calls are unwanted or associating a geoloca= tion aspect to calls that need to be treated as unwanted. etc.. There are s= everal scenarios available provided that the specification provides for fur= ther extensibility combined to programmatic mechanisms or machine learning = pattern building procedures. So with that being said, should we agree that = the proposed SIP response code could be further extended to bear multiple c= ontextual reason codes? Thanks. -- Souma Badombena-Wanta --_000_CY1PR09MB063459C304A66037805CE0C4EA080CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This seems to be related to the previous comment. I agree that users sho= uld have the ability to specify, either within an app or via a web interfac= e controlling a carrier or third-party operated service, how calls are trea= ted. As you say, this could be fairly complex in its details, such as depending on the time of day. ("Don't= mind survey calls, but not after 7 pm.")


I will note that many a moon ago, we actually developed a flexible XML-b= ased language for call handling purposes (RFC 3880, CPL). Wouldn't be = hard to extend it for this purpose, but I suspect CPL is not among the comm= only-implemented SIP-related RFCs...


Henning

From: sipcore <sipcore-b= ounces@ietf.org> on behalf of Souma Badombena <gmsoum@gmail.com> Sent: Sunday, April 2, 2017 10:47:12 AM
To: sipcore@ietf.org
Subject: Re: [sipcore] Last Call: <draft-ietf-sipcore-status-unwa= nted-04.txt> (A SIP Response Code for Unwanted Calls) to Proposed Standa= rd
 

"unwanted" as opposed to "blocked" -- "unwant= ed" is an enhancing functionality and allowing possible flexibility

I just wanted to mention a relevant aspect where the "Unwanted&qu= ot; concept addresses a shortcoming and may be improved upon with subsequen= t parameters enrichments.
For some SIP calling and messaging application there exists the concep= t of "contact blocking", "user blacklisting" or "p= ersonal blocking" where a user can select specific contacts or undersi= red identities (phone numbers, usernames, aliases etc...) to be blocked and therefore allowing the blocking user to reject calls or messag= es from a given blocked user. This very method or technique consists in mai= ntaining a resource list of blocked contact and applying restrictive or rej= ection filters to them either a local (client) level or at network level. So in a parallel with the "= SIP 666 - unwanted" solution, I notice that on one hand the  &quo= t;unwanted" method may be equivalent to the method or concept of block= ing, but on the other hand it does potentially offer an extensible flexibility for particular cases, provided that the appropriate enhancemen= t work is done in the future. For example in particular cases where a user = may want to add more selectivity to the how the "unwanted" call i= nstances and originators are treated, such as setting a time window or period for which the calls are unwanted or ass= ociating a geolocation aspect to calls that need to be treated as unwanted.= etc.. There are several scenarios available provided that the specificatio= n provides for further extensibility combined to programmatic mechanisms or machine learning pattern building p= rocedures. So with that being said, should we agree that the proposed = SIP response code could be further extended to bear multiple contextual rea= son codes?


Thanks.
--
Souma Badombena-Wanta

--_000_CY1PR09MB063459C304A66037805CE0C4EA080CY1PR09MB0634namp_-- From nobody Mon Apr 3 03:57: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 A296C124BFA for ; Mon, 3 Apr 2017 03:57:27 -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, HTML_MESSAGE=0.001, 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 (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 azW44u8eVpv7 for ; Mon, 3 Apr 2017 03:57:25 -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 178531279EB for ; Mon, 3 Apr 2017 03:57:24 -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=3lE8TV61NP+1nSKE2xeXLMcjhtFHzQ+RYTR6x7baCPs=; b=RDAx6oqOOgcql2c7wRftGbHK8WBmN1i5KrD6bzWg1xKSaJyTPoHNu3jXl5DUjx/zuzmnuuItw5JWFAvqIVxqY4JZeOfX/ImcNeNRuPWZdXs5U1OOs5bVTLUN3pAoTSZ3ceevg+57tQNCo1oM/g/NrQDbaWthn8+8vA+Vp+rkP0o= Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0016.outbound.protection.outlook.com [216.32.180.16]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-33-p4kPITMHPEqxG2OrIt5Xag-1; Mon, 03 Apr 2017 06:57:22 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Mon, 3 Apr 2017 10:57:19 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1005.018; Mon, 3 Apr 2017 10:57:19 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , Souma Badombena , "sipcore@ietf.org" Thread-Topic: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard Thread-Index: AQHSq8ADh5sL8uiR3EmPJvVd9qFaPKGy2/6AgACcy7A= Date: Mon, 3 Apr 2017 10:57:19 +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-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:g9ilHWpLfZyBCJyvO+6VvxdlXRIGmX60j1FRECo0kT8zz8nBrTu7MFIGAzVuwjcebS6LOYM/dZ48z52d2+0Zw0XqUH7jfGK8QEfFa0w3fDS/z29wmhHSo5Duow75MPgRUMJ+5Jkplw2BcUVizxCxGgIHxMYnRk9SHv+Ad0FU0fSHcUGlYt4NM2jYgzO/ZeKacI3vMVJ7jNzkbBRcOkSAuX6puBExAaXroSDQwkfRB4iyZ7CBAG2LeYk9QqG5yKy5ZYNrMHRCKOAswFazyVn8V/baWb9z/EBybI3jpfcX5EqdFfWMEv6lgprhb2hi1kcqAgScOl3j+dD30m80yso2OA==; 20:/Kd67p0ieMiN1QysrMsNFMNNCS0JnE2CiMw4e6qzH5IScH9jwzQksCGmN00HL+Dz10gMNtkdf0XSdXuVsUiZ6NIws8J4c2Y4vR7JLFfZVnKvwEXcQJT3FN+1WSguAlm5eyShwQE0iqAQDa50XboVwj2bqyWj7gxE0ozn6kjuU8c= x-ms-office365-filtering-correlation-id: 3acf97fb-1709-4bc7-a519-08d47a803328 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:SN2PR03MB2352; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39830400002)(39410400002)(39450400003)(51694002)(377454003)(25786009)(33656002)(3660700001)(6306002)(6506006)(6436002)(55016002)(99286003)(77096006)(53546009)(3280700002)(9686003)(6246003)(54896002)(39060400002)(7696004)(790700001)(8676002)(2950100002)(81166006)(38730400002)(236005)(102836003)(6116002)(3846002)(2900100001)(2906002)(189998001)(8936002)(97736004)(66066001)(74316002)(229853002)(2501003)(50986999)(122556002)(5660300001)(230783001)(76176999)(86362001)(54356999)(7736002)(53936002)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.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: 03 Apr 2017 10:57:19.5644 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 X-MC-Unique: p4kPITMHPEqxG2OrIt5Xag-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350AB0B7A6FD6550A0A88CBB2080SN2PR03MB2350namp_" 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, 03 Apr 2017 10:57:28 -0000 --_000_SN2PR03MB2350AB0B7A6FD6550A0A88CBB2080SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable This certainly would be something completely outside of the scope of "statu= s-unwanted" AFAICT. I think we should consider how all this would work "in real life" from an "= end-user perspective". For blocking decisions, they most probably would rel= y on some web-portal. I don't see CPL (or anything else) to be utilized for= this either. One may argue, why not use a web-based interface for reportin= g that a call is "unwanted"? That would require the user to logs-in, enter = some information about the call for correlation purposes, e.g. Calling-Part= y-Id as seen by him, time of the call etc.., all after the call and nobody = would do that. The only viable way this information can be provided by end-= users is just by pressing a button during the call IMHO. And that, is the r= aison d'etre for "status unwanted". Let's keep things practically useful and simple. Thanks, Tolga From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Henning Schulz= rinne Sent: Sunday, April 2, 2017 9:30 PM To: Souma Badombena ; sipcore@ietf.org Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard This seems to be related to the previous comment. I agree that users should= have the ability to specify, either within an app or via a web interface c= ontrolling a carrier or third-party operated service, how calls are treated= . As you say, this could be fairly complex in its details, such as dependin= g on the time of day. ("Don't mind survey calls, but not after 7 pm.") I will note that many a moon ago, we actually developed a flexible XML-base= d language for call handling purposes (RFC 3880, CPL). Wouldn't be hard to = extend it for this purpose, but I suspect CPL is not among the commonly-imp= lemented SIP-related RFCs... Henning ________________________________ From: sipcore > o= n behalf of Souma Badombena > Sent: Sunday, April 2, 2017 10:47:12 AM To: sipcore@ietf.org Subject: Re: [sipcore] Last Call: (A SIP Response Code for Unwanted Calls) to Proposed Standard "unwanted" as opposed to "blocked" -- "unwanted" is an enhancing functional= ity and allowing possible flexibility I just wanted to mention a relevant aspect where the "Unwanted" concept add= resses a shortcoming and may be improved upon with subsequent parameters en= richments. For some SIP calling and messaging application there exists the concept of = "contact blocking", "user blacklisting" or "personal blocking" where a user= can select specific contacts or undersired identities (phone numbers, user= names, aliases etc...) to be blocked and therefore allowing the blocking us= er to reject calls or messages from a given blocked user. This very method = or technique consists in maintaining a resource list of blocked contact and= applying restrictive or rejection filters to them either a local (client) = level or at network level. So in a parallel with the "SIP 666 - unwanted" s= olution, I notice that on one hand the "unwanted" method may be equivalent= to the method or concept of blocking, but on the other hand it does potent= ially offer an extensible flexibility for particular cases, provided that t= he appropriate enhancement work is done in the future. For example in parti= cular cases where a user may want to add more selectivity to the how the "u= nwanted" call instances and originators are treated, such as setting a time= window or period for which the calls are unwanted or associating a geoloca= tion aspect to calls that need to be treated as unwanted. etc.. There are s= everal scenarios available provided that the specification provides for fur= ther extensibility combined to programmatic mechanisms or machine learning = pattern building procedures. So with that being said, should we agree that = the proposed SIP response code could be further extended to bear multiple c= ontextual reason codes? Thanks. -- Souma Badombena-Wanta --_000_SN2PR03MB2350AB0B7A6FD6550A0A88CBB2080SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

This certainly would be something completely outsid= e of the scope of “status-unwanted” AFAICT.

 

I think we should consider how all this would work = “in real life” from an “end-user perspective”. For = blocking decisions, they most probably would rely on some web-portal. I don’t see CPL (or anything else) to be utilized for this either. O= ne may argue, why not use a web-based interface for reporting that a call i= s “unwanted”? That would require the user to logs-in, enter som= e information about the call for correlation purposes, e.g. Calling-Party-Id as seen by him, time of the call etc.., all after th= e call and nobody would do that. The only viable way this information can b= e provided by end-users is just by pressing a button during the call IMHO. = And that, is the raison d’etre for “status unwanted”.

 

Let’s keep things practically useful and simp= le.

 

Thanks,

Tolga

 

From: sipcore [mailto:sipcore-bounce= s@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Sunday, April 2, 2017 9:30 PM
To: Souma Badombena <gmsoum@gmail.com>; sipcore@ietf.org
Subject: Re: [sipcore] Last Call: <draft-ietf-sipcore-status-unwa= nted-04.txt> (A SIP Response Code for Unwanted Calls) to Proposed Standa= rd

 

T= his seems to be related to the previous comment. I agree that users should = have the ability to specify, either within an app or via a web interface co= ntrolling a carrier or third-party operated service, how calls are treated. As you say, this could be fairly complex i= n its details, such as depending on the time of day. ("Don't mind surv= ey calls, but not after 7 pm.")

<= o:p> 

I= will note that many a moon ago, we actually developed a flexible XML-based=  language for call handling purposes (RFC 3880, CPL). Wouldn't be hard= to extend it for this purpose, but I suspect CPL is not among the commonly-implemented SIP-related RFCs...

<= o:p> 

H= enning

From: sipcor= e <sipcore-bounces@ietf.org<= /a>> on behalf of Souma Badombena <gmsou= m@gmail.com>
Sent: Sunday, April 2, 2017 10:47:12 AM
To: sipcore@ietf.org
Subject: Re: [sipcore] Last Call: <draft-ietf-sipcore-status-unwa= nted-04.txt> (A SIP Response Code for Unwanted Calls) to Proposed Standa= rd

 

 

"unwanted" as opposed to "blocked&quo= t; -- "unwanted" is an enhancing functionality and allowing possi= ble flexibility

 

I just wanted to mention a relevant aspect where the= "Unwanted" concept addresses a shortcoming and may be improved u= pon with subsequent parameters enrichments.

For some SIP calling and messaging application there= exists the concept of "contact blocking", "user blacklistin= g" or "personal blocking" where a user can select specific c= ontacts or undersired identities (phone numbers, usernames, aliases etc...) to be blocked and therefore allowing the blocking user to reject c= alls or messages from a given blocked user. This very method or technique c= onsists in maintaining a resource list of blocked contact and applying rest= rictive or rejection filters to them either a local (client) level or at network level. So in a parallel w= ith the "SIP 666 - unwanted" solution, I notice that on one hand = the  "unwanted" method may be equivalent to the method or co= ncept of blocking, but on the other hand it does potentially offer an extensible flexibility for particular cases, provided that the ap= propriate enhancement work is done in the future. For example in particular= cases where a user may want to add more selectivity to the how the "u= nwanted" call instances and originators are treated, such as setting a time window or period for which the calls a= re unwanted or associating a geolocation aspect to calls that need to be tr= eated as unwanted. etc.. There are several scenarios available provided tha= t the specification provides for further extensibility combined to programmatic mechanisms or machine learn= ing pattern building procedures. So with that being said, should we ag= ree that the proposed SIP response code could be further extended to bear m= ultiple contextual reason codes?


 

Thanks.

--

Souma Badombena-Wanta=

--_000_SN2PR03MB2350AB0B7A6FD6550A0A88CBB2080SN2PR03MB2350namp_-- From nobody Tue Apr 4 03:24: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 17C841294B3 for ; Tue, 4 Apr 2017 03:24:13 -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 z3UtFU1BPEeN for ; Tue, 4 Apr 2017 03:24:09 -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 A23701243F3 for ; Tue, 4 Apr 2017 03:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1491301448; x=1522837448; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=X3QC1cqOmhQY94/6X17iBYdcQqH69HL18YFLX3p4tQI=; b=mvg//Wpu0y60u/tv9fOGlHpolPHsOPDPvIFjbSDIZ73WcIkZBSyH7Eqd oCJQaAY3iNLSQ9eERaLSiiAEkulCetOMAGqECJhTgxgxFl6FU3ZeH5DVX TR4aKSUa6Pg1ze/pllbp0P88rN8ifOE7t2yjXUspLs+QSl5Z+Ht7usOQf KZdRau5R1rkCwvKz5bI2ekbPDyThkvajwV2YvbPmseE7mkGL3HlalZygG UKdmiU1LUSO8hOMuIKOyJ+9dUoaQLyelTpc+U/cPzWsDrhTuufk/Etd+k AcsdYBCIAm1It4N+BXw9OBBYDE9ZCAjT9Tyb9i8xeMqTvhV9d82xXTW7g Q==; Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT21.telekom.de with ESMTP/TLS/RC4-SHA; 04 Apr 2017 12:24:05 +0200 X-IronPort-AV: E=Sophos;i="5.36,275,1486422000"; d="scan'208";a="648733745" Received: from he105829.emea1.cds.t-internal.com ([10.169.119.32]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 04 Apr 2017 12:24:05 +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; Tue, 4 Apr 2017 12:24:04 +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, 4 Apr 2017 12:24:04 +0200 From: To: , Thread-Topic: [sipcore] Comments on draft-winterbottom-sipcore-locparam-00 Thread-Index: AQHSqa4NON/O4PiIm0+uPylWuCpEV6G1B3bg Date: Tue, 4 Apr 2017 10:24:04 +0000 Message-ID: <5b80ae7e6efd44dd8a9d45ab05590c30@HE105828.emea1.cds.t-internal.com> References: <8737dugx18.fsf@hobgoblin.ariadne.com> In-Reply-To: <8737dugx18.fsf@hobgoblin.ariadne.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.157.168.136] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Tue, 04 Apr 2017 10:24:13 -0000 Hi Dale, Thank you for your extensive Review and the questions. The answers are below and will hopefully clarify the issues we have also di= scussed during the SIPCOER meeting. =20 Best Regards =20 Roland =20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Dale R. > Worley > Gesendet: Donnerstag, 30. M=E4rz 2017 18:33 > An: sipcore@ietf.org > Betreff: [sipcore] Comments on draft-winterbottom-sipcore-locparam-00 >=20 > * Technical issues >=20 > A. Should this draft explicitly update this statement in RFC 6442? >=20 > A SIP intermediary SHOULD NOT add location to a SIP request that > already contains location. =20 So seen from our perspective is a SHOULD NOT an option. With regard to our = deraft we assume that there can be more than one location within the messag= e.This is was the ETSI M493 project is describing in their Specification. =20 >=20 > B. Should the UE explicitly label its locationValue? No, it is intended to use this parameter in trust domains where Spec(T) as = described in [RFC3325] exists only. =20 =20 =20 >=20 > 4. Mechanism >=20 > A UE MUST NOT provide a loc-src parameter value. >=20 > Is this the best choice? Might it be better to provide a way for the=20 > UE to mark a locationValue, so that a locationValue added by a=20 > new-type UE can be reliably distinguished from an old-type=20 > intermediate that adds a locationValue (perforce without a loc-src value)= ? =20 It is intended to use this parameter in trust domains where Spec(T) as desc= ribed in [RFC3325] exists only.=20 =20 >=20 > C. The meaning of "token" as an other-loc-src is not defined. >=20 > location-source =3D "loc-src=3D" (host / other-loc-src) > other-loc-src =3D token =20 That value allows you to use other than host to be included within the loc-= src. >=20 > D. Interpretation of location-source values. >=20 > The processor that interprets the locationValues must be able to=20 > interpret the significance of the location-source values. For=20 > diagnostic purposes, a human can interpret host values easily enough. > But for automatic processing, would the host values (even if they are=20 > known to be accurate) be interpretable with any reasonable amount of=20 > effort? Naively, it seems that the processor would need a list of all=20 > possible host values and their classification (unless the host names=20 > were constructed according to a rigid scheme). >=20 > It's possible that ETSI has evaluated this question and determined=20 > that this interpretation of host values works well. =20 ETSI has evaluated this and already described within ES 203 178 and DraftES= /NTECH-00025 =20 >=20 > But naively, it seems to me that the values you want for automatic=20 > processing are codes for the *roles* or *positions* within the dialog=20 > of the adders of the locationValues. While I was watching the=20 > presentation, I was remembering that I'd seen such a set of values=20 > defined somewhere, and it turns out that I was remembering the resp-=20 > location values from draft-jesske-dispatch-reason-loc-q850-00: >=20 > 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 >=20 > >From this point of view, a more informative way to label > locationValues is: >=20 > geoloc-param =3D/ location-source > location-source =3D "loc-src=3D" loc-src-value > loc-src-value =3D U / LPN / LN / TN / RLN / RPN / INTL / > BI / token >=20 > geoloc-param =3D/ location-host > location-host =3D "loc-host=3D" host >=20 > where "loc-src" can be automatically processed without the processor=20 > understanding every possible host name, and "loc-host" very fine-=20 > grained for diagnostic and specialty processing. =20 The labeling itself would help within one network which entity has included= the loc-serc but seen from multiple network approach this would not really= help. Because it is not known which element from which Service provider ha= s included the loc-src. Also within the own network this indication may not help since a couple of = entites may within the LN or also within a INTL. >=20 > * Editorial issues >=20 I will change the text based on your following comments within the next ver= sion of the document. =20 > 1. Introduction >=20 > The SIP geolocation specification [RFC6442] describes a SIP header > field that is used to indicate that the SIP message is conveying > location information. >=20 > I suggest changing 'describes a SIP header field that' to 'describes=20 > the "Geolocation" SIP header field which'. >=20 > [RFC6442] stipulates that the order of > location values in the geolocation header field aligns with the=20 > order > in which they were added to the header field. >=20 > "aligns with" is ambiguous -- is the first Geolocation header the=20 > first one that was added or is the last Geolocation header the first=20 > one that was added? From RFC 6442 section 4.1, the first Geolocation=20 > header is the first one added, so "aligns with" can be changed to "is" > or "is the same as". >=20 > 3. Rationale >=20 > Thus it is intended to use this parameter in > trust domains where Spec(T) as described in [RFC3325] exists only. >=20 > I'm not sure of the exact rules for the use of the English word=20 > "only", but in this case it would be clearer to say >=20 > Thus it is intended to use this parameter only in > trust domains where Spec(T) as described in [RFC3325] exists. >=20 > 4. Mechanism >=20 > The Augmented BNF (ABNF) [RFC5234] for this parameter is shown in > Figure 1. >=20 > location-source =3D "loc-src=3D" (host / other-loc-src) > other-loc-src =3D token >=20 > Formally, this omits connecting location-source to the BNF for the=20 > Geolocation header, which is done by: >=20 > geoloc-param =3D/ location-source >=20 > -- >=20 > 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. >=20 > This might be more aggressive than we want. The weakest acceptable=20 > requirement, I think, is that any conforming node MAY remove such a=20 > value and MUST ignore it in processing it. But ETSI may have=20 > operational experience to make it clear what the best approach is. >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Dale R. > Worley > Gesendet: Freitag, 31. M=E4rz 2017 01:33 > An: sipcore@ietf.org > Betreff: [sipcore] Comments on draft-winterbottom-sipcore-locparam-00 >=20 > * Technical issues >=20 > A. Should this draft explicitly update this statement in RFC 6442? >=20 > A SIP intermediary SHOULD NOT add location to a SIP request that > already contains location. >=20 > B. Should the UE explicitly label its locationValue? >=20 > 4. Mechanism >=20 > A UE MUST NOT provide a loc-src parameter value. >=20 > 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)? >=20 > C. The meaning of "token" as an other-loc-src is not defined. >=20 > location-source =3D "loc-src=3D" (host / other-loc-src) > other-loc-src =3D token >=20 > D. Interpretation of location-source values. >=20 > 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). >=20 > It's possible that ETSI has evaluated this question and determined that > this interpretation of host values works well. >=20 > 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: >=20 > 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 >=20 > >From this point of view, a more informative way to label > locationValues is: >=20 > geoloc-param =3D/ location-source > location-source =3D "loc-src=3D" loc-src-value > loc-src-value =3D U / LPN / LN / TN / RLN / RPN / INTL / > BI / token >=20 > geoloc-param =3D/ location-host > location-host =3D "loc-host=3D" host >=20 > 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. >=20 > * Editorial issues >=20 > 1. Introduction >=20 > The SIP geolocation specification [RFC6442] describes a SIP header > field that is used to indicate that the SIP message is conveying > location information. >=20 > I suggest changing 'describes a SIP header field that' to 'describes > the "Geolocation" SIP header field which'. >=20 > [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. >=20 > "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". >=20 > 3. Rationale >=20 > Thus it is intended to use this parameter in > trust domains where Spec(T) as described in [RFC3325] exists only. >=20 > 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 >=20 > Thus it is intended to use this parameter only in > trust domains where Spec(T) as described in [RFC3325] exists. >=20 > 4. Mechanism >=20 > The Augmented BNF (ABNF) [RFC5234] for this parameter is shown in > Figure 1. >=20 > location-source =3D "loc-src=3D" (host / other-loc-src) > other-loc-src =3D token >=20 > Formally, this omits connecting location-source to the BNF for the > Geolocation header, which is done by: >=20 > geoloc-param =3D/ location-source >=20 > -- >=20 > 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. >=20 > 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. >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Apr 4 08:27: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 67E4F1296CC for ; Tue, 4 Apr 2017 08:27:44 -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 zCe6NWA5z19Z for ; Tue, 4 Apr 2017 08:27:42 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 5F3B11296C6 for ; Tue, 4 Apr 2017 08:27:42 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id g2so153657169pge.3 for ; Tue, 04 Apr 2017 08:27:42 -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=SSaTcWtmy+8ZKQPC0yoI+2lYKNmb6MaqxqCDnC/5Qx8=; b=pDhfJWiHCaljEWr48oO/B+dei9Mj8X2meUuAiQ1SQV4YmN8ZFvQZN3eE4gMHuGB4jG tWjh65uXDk6o3friERWSORJZN6zN7ppzM3EOsNbtDnvBjL1kr2ch8HuzIBD37aTEXwR2 OCi9p3iYIYz1rdlW85AAWHUCy+EatJVLJSbP/JUm82Qol1dattQlazoq2yfdsYaViHbS QWzzWL0fXV3eDEL5XrRJwWkJXD2DOwaBOA63//rZ5mOzzesLuCOPGsmZH8MEbSDdPwt/ r/VnoTkmqhmeuo+w9cMhvPOaKHoVZKs14P62FSJXZ20Kf+3drq31XPTKaSt32jSfIYiP iouQ== 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=SSaTcWtmy+8ZKQPC0yoI+2lYKNmb6MaqxqCDnC/5Qx8=; b=eb1HRLiiituPPOihSvlyeseVoPs81Ab//8H1bGHBNE/qfRdSZ92Ch1TXozYDJWTGvO xFlSe9rjysBBw6g/ixwWJx/HD5wCKUOYILUlp/DLGIk2m6vKjjEngcelwzCcpKCOuPTb RSWOOqs+CbQj4QDH+F1HzXJHKVyNcPEh7KjpNc1Gl16jSHdpn0Gs/4DRG/dPDlfLzZVf TeP+q6lQxrsqJ+xJYO1P/j+aeAu3EmAreLJw1/cn/bCrkk9oTb+mUeV+rxkTKgCAC3D/ 1aVDiJOMu4K8AcrvrF/MkR5TrMd7b/OwRmPF4tmyby8H3uAVaoRP5O7N0JT+MHKIq5W5 XzTQ== X-Gm-Message-State: AFeK/H2E774WGm8G8urVqAAToRQP7jwOjdohwQCtFeVKNTDn2YB/fLP4K+22B5UOjEQfGUgZGKnrSYF1ILD7Mw== X-Received: by 10.99.42.78 with SMTP id q75mr24592281pgq.144.1491319662013; Tue, 04 Apr 2017 08:27:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.154.239 with HTTP; Tue, 4 Apr 2017 08:27:41 -0700 (PDT) In-Reply-To: References: <25855_1489353730_58C5BC02_25855_10494_1_8B970F90C584EA4E97D5BAAC9172DBB81C935BDC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <58b9213c-1fb1-95f7-6888-60f7a754fc4f@nostrum.com> From: Ranjit Avasarala Date: Tue, 4 Apr 2017 10:27:41 -0500 Message-ID: To: R.Jesske@telekom.de Cc: mahoney@nostrum.com, SIPCORE Content-Type: multipart/alternative; boundary=001a114693dab37371054c58ea0a 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: Tue, 04 Apr 2017 15:27:44 -0000 --001a114693dab37371054c58ea0a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi I read thru the draft and yes the additional parameter in P-Served-user makes sense to better handle call diversion service. But I think a value for "orig-cdiv" may be required . e.g orig-cdiv=3Dyes (default). though I = do not have a use case for orig-cdiv=3Dno as of now. Regards Ranjit On Fri, Mar 31, 2017 at 7:29 AM, wrote: > Hi Jean, > I have read Marianne's draft and support the draft to become a WG documen= t. > Best Regards > > Roland > > -----Urspr=C3=BCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von A. Jean > Mahoney > Gesendet: Donnerstag, 30. M=C3=A4rz 2017 17:22 > An: sipcore@ietf.org > Betreff: Re: [sipcore] Draft new: draft-mohali-sipcore- > originating-cdiv-parameter-00 > > 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 =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 > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a114693dab37371054c58ea0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

I read thru the draft and yes the ad= ditional parameter in P-Served-user makes sense to better handle call diver= sion service.=C2=A0 But I think a value for "orig-cdiv" may be re= quired . e.g orig-cdiv=3Dyes (default). =C2=A0though I do not have a use ca= se for orig-cdiv=3Dno as of now.=C2=A0

Regards
Ranjit


On Fri, Mar 31, 2017 at 7:29 AM, = <R.Jesske@telek= om.de> wrote:
Hi Jean,
I have read Marianne's draft and support the draft to become a WG docum= ent.
Best Regards

Roland

-----Urspr=C3=BCngliche Nachricht-----
Von: sipcore [mailto:sipcore-bo= unces@ietf.org] Im Auftrag von A. Jean Mahoney
Gesendet: Donnerstag, 30. M=C3=A4rz 2017 17:22
An: sipcore@ietf.org
Betreff: Re: [sipcore] Draft new: draft-mohali-sipcore-originating-cdi= v-parameter-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,
> draft-mohali-sipcore-originating-cdiv-parameter-00 (was
> draft-mohali-dispatch-originating-cdiv-parameter-03).
> https://www.ietf.org/inte= rnet-drafts/draft-mohali-sipcore-originating-
> cdiv-parameter-00.txt
>
>=C2=A0 Based on ADs and Chairs guidance, this draft is moved from DISPA= TCH
> 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.=C2=A0 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<= br> > particular communication session and application invocation.=C2=A0 Thi= s
> 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=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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<= br> > anyway.
>
> Best regards, Marianne
>
>
>
>
>
> ____________________________________________________________= __________
> ___________________________________________________
>
>=C2=A0 Ce message et ses pieces jointes peuvent contenir des informatio= ns
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,<= br> > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ain= si
> que les pieces jointes. Les messages electroniques etant susceptibles<= br> > 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 l= ist
> sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore
>

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

--001a114693dab37371054c58ea0a-- From nobody Tue Apr 4 12:54: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 AA25C1294E2 for ; Tue, 4 Apr 2017 12:54:21 -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 o0MR9_30BG7Z for ; Tue, 4 Apr 2017 12:54:20 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 56411127449 for ; Tue, 4 Apr 2017 12:54:18 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-10v.sys.comcast.net with SMTP id vUVocXPTY61D9vUWvcYeEU; Tue, 04 Apr 2017 19:54:17 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-04v.sys.comcast.net with SMTP id vUWucFxNGFcZ2vUWvcDs3B; Tue, 04 Apr 2017 19:54:17 +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 v34JsG1h028982 for ; Tue, 4 Apr 2017 15:54:16 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v34JsFaC028979; Tue, 4 Apr 2017 15:54:15 -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: Tue, 04 Apr 2017 15:54:15 -0400 Message-ID: <87zifw9cew.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfBzu9grnqoMobto9k9nQFyGtNFZcHhQur2br9RzkBMJ3G8OCHf8hcvp2wkU3UX1kik4gFTryyPL9HKc+Jbi65OMFSM8z3g7VqopFECKQ3fZMXV4Zcsi7 KKazXbRxsaC3PjZnrB4AQ1qKfomnoy9TEW3fExaRKNDai6iY4pmHPy+t Archived-At: Subject: [sipcore] Happy Earballs 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, 04 Apr 2017 19:54:22 -0000 I've submitted an update on the Happy Earballs algorithm I've been working on, draft-worley-sipcore-happy-earballs-00, and I'd like feedback. The details are in the draft, of course, but the outline is this: RFC 3263 specifies that the various target addresses for a SIP message must be contacted in a particular order. If a target fails to respond, the sender has to wait (possibly resending) for 32 seconds (by default) before moving on to another target. This creates a horrible user experience if the sender thinks it has connectivity to a target (e.g., an IPv6 address) but doesn't. To get around this, introduce a new rule: a sender is allowed to change the order of contacting targets provided that collectively, all targets that are "responsive" still receive the traffic distribution that would result from strict application of RFC 3263. A sender caches information about the responsiveness of targets and uses that, along with the DNS information, to decide what order to contact the targets. If a sender doesn't have responsiveness information about a target, it first sends a non-state-changing probe communication to the target to determine if the target is responsive. One example of a probe is an OPTIONS request with "Max-Forwards: 0". (In the case of two TCP targets, which parallels RFC 6555 and draft-johansson-sipcore-he-connection, the sender can simultaneously initiate TCP connections to the targets because the TCP SYNs are probes of the targets. Whichever target responds fastest is necessarily "responsive".) Within this framework, and the goal of minimizing the time required to send messages, the sender is confined to a fairly narrow range of behaviors, which can be characterized by a generic algorithm that has certain degrees of freedom that can be called a "policy". Dale From nobody Tue Apr 4 16:58: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 8FF12127449 for ; Tue, 4 Apr 2017 16:58:16 -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 PKGRgohUrQ5a for ; Tue, 4 Apr 2017 16:58:15 -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 47F4D124D6C for ; Tue, 4 Apr 2017 16:58:15 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-07v.sys.comcast.net with SMTP id vYL0cEw9fU9z5vYL0cjVhi; Tue, 04 Apr 2017 23:58:14 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-17v.sys.comcast.net with SMTP id vYKyc8tPnbkqIvYKzc1yqZ; Tue, 04 Apr 2017 23:58:14 +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 v34NwC0Q021290; Tue, 4 Apr 2017 19:58:12 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v34NwB2V021283; Tue, 4 Apr 2017 19:58:11 -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: Cc: sipcore@ietf.org In-Reply-To: <5b80ae7e6efd44dd8a9d45ab05590c30@HE105828.emea1.cds.t-internal.com> (R.Jesske@telekom.de) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 04 Apr 2017 19:58:11 -0400 Message-ID: <87d1crafos.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfMVvL4jyekSbGiFRRFlFT915A5bi7XTFuY3h1REUWfJ35R2nehYqndLTsed6+2XbjMKDjvN9OGkSZ66AlU1Q4Vc8wVp4FM/WFFCANHsKagBM35uzbK04 8ggG5P89uiOxNpLy0lpsAGi8r5Ai9tdOuhnPDLfSD+mQ/fmZiiCUtHWJrpntuK/rxfmWbBlkF/OXGQ== 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: Tue, 04 Apr 2017 23:58:17 -0000 writes: >> 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)? > > It is intended to use this parameter in trust domains where Spec(T) as > described in [RFC3325] exists only. OK... But it seems that UE/UA can be part of a trust domain, and thus Spec(T) applies. See e.g., section 8 of RFC 3325, "If a UA is part of the Trust Domain from which it received a message ...". Whereas this draft says that a UE/UA must not apply a loc-src regardless of whether it's within the trust domain or not. >> 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 > > That value allows you to use other than host to be included within the > loc-src. That's true, it does, but the text of the draft doesn't specify what the semantics of such a token would be, or reserve that the token must be as specified by another document. The BNF allows a syntax whose semantics is entirely unexplained. Dale From nobody Tue Apr 4 22:33: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 4919F129416 for ; Tue, 4 Apr 2017 22:33:52 -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, 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] 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 XJEFaMPN4Wpv for ; Tue, 4 Apr 2017 22:33:49 -0700 (PDT) Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242BE126C26 for ; Tue, 4 Apr 2017 22:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1491370426; x=1522906426; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Bq43gQuTuI8vwYaGJJwYdHjmWbU8oQMVvYKf00andn0=; b=j/C/tG8JZtG0iqxPzjv29g5r3FgFwK8r+IAwkhgraE8DcFgwsQuqeDO5 r5SBt/JnlCHOqhkpPrCxio4DqHoICvl5ZMWXcFAk6WP884Us5nI40c2vv +wm2CKX31i4503x42qxvkYZYAGZZHaRRRgDMDf/pdDmeUtJtfdfXM88bf YzCGxYCQ2I6oydc6ovroVuOlfId6G39IBcEAnVTM9iN/+KXhuKLzXuUuP 6zH6kv514FQfYNPmd7+ZyAPYjmhCieD9vUqBeGDiSG4t9Cxxk6ILmpScf 1JiYIx8VmUHn0j1xmNhRrfKPqeGNSwOl3xYU+/622Gklkz9VyS6qadz9Y Q==; Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT21.telekom.de with ESMTP/TLS/RC4-SHA; 05 Apr 2017 07:33:42 +0200 X-IronPort-AV: E=Sophos;i="5.36,277,1486422000"; d="scan'208,217";a="649389454" Received: from he105829.emea1.cds.t-internal.com ([10.169.119.32]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 05 Apr 2017 07:33:42 +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; Wed, 5 Apr 2017 07:33:41 +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; Wed, 5 Apr 2017 07:33:41 +0200 From: To: CC: , Thread-Topic: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-parameter-00 Thread-Index: AQHSqaQWpesEhUHcIkeKIYpECUFQFaGu4YUwgAZZq4CAAQnzMA== Date: Wed, 5 Apr 2017 05:33:41 +0000 Message-ID: <7ff26f92f4114c28aeddf198b37c2b12@HE105828.emea1.cds.t-internal.com> References: <25855_1489353730_58C5BC02_25855_10494_1_8B970F90C584EA4E97D5BAAC9172DBB81C935BDC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <58b9213c-1fb1-95f7-6888-60f7a754fc4f@nostrum.com> In-Reply-To: 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.239.211] Content-Type: multipart/alternative; boundary="_000_7ff26f92f4114c28aeddf198b37c2b12HE105828emea1cdstintern_" 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: Wed, 05 Apr 2017 05:33:52 -0000 --_000_7ff26f92f4114c28aeddf198b37c2b12HE105828emea1cdstintern_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudC4gSSB0aGluayBpdCBpcyBzdWZmaWNpZW50 IHRoYXQgb25seSB3aXRoIHRoZSBhcHBlYXJhbmNlIG9mIHRoZSBwYXJhbWV0ZXIgaXQgaXMgc2hv d24gdGhhdCBhIG9yaWctY2RpdiBoYXMgYmVlbiBkb25lLiBUaGUgb3V0Z29pbmcgbGVnIG9mIHRo ZSBTLUNTQ0YgaGFzIHRvIGtub3cgaWYgYSBDRElWIGFwcGVhcmVkLg0KQWxsIHN0YW5kYXJkIHBy b2NlZHVyZXMsIGkuZS4gbm8gY2RpdiBhcHBlYXJlZCwgd2lsbCBiZSB0cmlnZ2VyZWQgYW55d2F5 LiBUaGlzIGRvZXMgbm90IG5lZWQgYSBvcmlnLWNkaXY9bm8uDQpQbGVhc2Uga2VlcCBpbiBtaW5k IHRoaXMgZHJhZnQgaXMgM0dQUCBJTVMgc3BlY2lmaWMuDQoNCkJlc3QgcmVnYXJkcw0KDQpSb2xh bmQNCg0KVm9uOiBSYW5qaXQgQXZhc2FyYWxhIFttYWlsdG86cmFuaml0a2F2MDgxMUBnbWFpbC5j b21dDQpHZXNlbmRldDogRGllbnN0YWcsIDQuIEFwcmlsIDIwMTcgMTc6MjgNCkFuOiBKZXNza2Us IFJvbGFuZA0KQ2M6IG1haG9uZXlAbm9zdHJ1bS5jb207IFNJUENPUkUNCkJldHJlZmY6IFJlOiBb c2lwY29yZV0gRHJhZnQgbmV3OiBkcmFmdC1tb2hhbGktc2lwY29yZS1vcmlnaW5hdGluZy1jZGl2 LXBhcmFtZXRlci0wMA0KDQpIaQ0KDQpJIHJlYWQgdGhydSB0aGUgZHJhZnQgYW5kIHllcyB0aGUg YWRkaXRpb25hbCBwYXJhbWV0ZXIgaW4gUC1TZXJ2ZWQtdXNlciBtYWtlcyBzZW5zZSB0byBiZXR0 ZXIgaGFuZGxlIGNhbGwgZGl2ZXJzaW9uIHNlcnZpY2UuICBCdXQgSSB0aGluayBhIHZhbHVlIGZv ciAib3JpZy1jZGl2IiBtYXkgYmUgcmVxdWlyZWQgLiBlLmcgb3JpZy1jZGl2PXllcyAoZGVmYXVs dCkuICB0aG91Z2ggSSBkbyBub3QgaGF2ZSBhIHVzZSBjYXNlIGZvciBvcmlnLWNkaXY9bm8gYXMg b2Ygbm93Lg0KDQpSZWdhcmRzDQpSYW5qaXQNCg0KDQpPbiBGcmksIE1hciAzMSwgMjAxNyBhdCA3 OjI5IEFNLCA8Ui5KZXNza2VAdGVsZWtvbS5kZTxtYWlsdG86Ui5KZXNza2VAdGVsZWtvbS5kZT4+ IHdyb3RlOg0KSGkgSmVhbiwNCkkgaGF2ZSByZWFkIE1hcmlhbm5lJ3MgZHJhZnQgYW5kIHN1cHBv cnQgdGhlIGRyYWZ0IHRvIGJlY29tZSBhIFdHIGRvY3VtZW50Lg0KQmVzdCBSZWdhcmRzDQoNClJv bGFuZA0KDQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQpWb246IHNpcGNvcmUg W21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmUtYm91bmNlc0Bp ZXRmLm9yZz5dIEltIEF1ZnRyYWcgdm9uIEEuIEplYW4gTWFob25leQ0KR2VzZW5kZXQ6IERvbm5l cnN0YWcsIDMwLiBNw6RyeiAyMDE3IDE3OjIyDQpBbjogc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86 c2lwY29yZUBpZXRmLm9yZz4NCkJldHJlZmY6IFJlOiBbc2lwY29yZV0gRHJhZnQgbmV3OiBkcmFm dC1tb2hhbGktc2lwY29yZS1vcmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlci0wMA0KDQpIaSBhbGws DQoNCkkgbWVudGlvbmVkIHRoaXMgZHJhZnQgZHVyaW5nIHRoZSBXRyBzZXNzaW9uIHRvZGF5LiBE b2VzIGFueW9uZSBoYXZlIGFueSBjb21tZW50cyBvbiB0aGUgZHJhZnQ/IFNob3VsZCBpdCBiZWNv bWUgYSBXRyBkb2N1bWVudD8NCg0KVGhhbmtzIQ0KDQpKZWFuDQoNCk9uIDMvMTIvMTcgNDoyMiBQ TSwgbWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb208bWFpbHRvOm1hcmlhbm5lLm1vaGFsaUBvcmFu Z2UuY29tPiB3cm90ZToNCj4gSGkgYWxsLA0KPg0KPiBQbGVhc2UgZmluZCBoZXJlYWZ0ZXIgYSBu ZXcgdmVyc2lvbiBvZiBJLUQsDQo+IGRyYWZ0LW1vaGFsaS1zaXBjb3JlLW9yaWdpbmF0aW5nLWNk aXYtcGFyYW1ldGVyLTAwICh3YXMNCj4gZHJhZnQtbW9oYWxpLWRpc3BhdGNoLW9yaWdpbmF0aW5n LWNkaXYtcGFyYW1ldGVyLTAzKS4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LW1vaGFsaS1zaXBjb3JlLW9yaWdpbmF0aW5nLQ0KPiBjZGl2LXBhcmFtZXRlci0w MC50eHQNCj4NCj4gIEJhc2VkIG9uIEFEcyBhbmQgQ2hhaXJzIGd1aWRhbmNlLCB0aGlzIGRyYWZ0 IGlzIG1vdmVkIGZyb20gRElTUEFUQ0gNCj4gdG8gU0lQQ09SRSBmb2xsb3dpbmcgdGhlIG5ldyBj aGFydGVyIG9mIHNpcGNvcmUgV0cuDQo+DQo+IEFic3RyYWN0OiBUaGlzIHNwZWNpZmljYXRpb24g ZGVmaW5lcyBhIG5ldyBwYXJhbWV0ZXIgb2YgdGhlDQo+IFAtU2VydmVkLVVzZXIgaGVhZGVyIGZp ZWxkIGluIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkuDQo+IFRoaXMgbmV3 ICJvcmlnLWNkaXYiIHBhcmFtZXRlciBkZWZpbmVzIHRoZSBzZXNzaW9uIGNhc2UgdXNlZCBieSBh DQo+IHByb3h5IHdoZW4gaGFuZGxpbmcgYW4gb3JpZ2luYXRpbmcgc2Vzc2lvbiBhZnRlciBDYWxs IERpdmVyc2lvbg0KPiAoQ0RJVikgc2VydmljZXMgaGFzIGJlZW4gaW52b2tlZCBmb3IgdGhlIHNl cnZlZCB1c2VyLiAgVGhlDQo+IFAtU2VydmVkLVVzZXIgaGVhZGVyIGZpZWxkIGlzIGRlZmluZWQg aW4gUkZDNTUwMiB0byBjb252ZXkgdGhlDQo+IGlkZW50aXR5IG9mIHRoZSBzZXJ2ZWQgdXNlciBh bmQgdGhlIHNlc3Npb24gY2FzZSB0aGF0IGFwcGxpZXMgdG8gdGhpcw0KPiBwYXJ0aWN1bGFyIGNv bW11bmljYXRpb24gc2Vzc2lvbiBhbmQgYXBwbGljYXRpb24gaW52b2NhdGlvbi4gIFRoaXMNCj4g ZG9jdW1lbnQgdXBkYXRlcyBSRkM1NTAyIHRvIGFkZCB0aGUgIm9yaWdpbmF0aW5nIGFmdGVyIENE SVYiIHNlc3Npb24NCj4gY2FzZSBhbmQgdG8gcHJvdmlkZSBtb3JlIGd1aWRhbmNlIGZvciB1c2lu ZyB0aGUgUC1TZXJ2ZWQtVXNlciBoZWFkZXINCj4gZmllbGQgaW4gSVAgbmV0d29ya3MgdGhhdCB3 ZXJlIG1pc3NpbmcgaW4gUkZDNTUwMi4NCj4NCj4+IEZyb20gdGhlIGRpc2N1c3Npb24gaW4gRElT UEFUQ0gsIGluIHRoaXMgdmVyc2lvbiBvZiB0aGUgZHJhZnQsIHRoZQ0KPj4gc3ludGF4IG9mIHRo ZSBoZWFkZXIgY291bGQgYmUgaW1wcm92ZWQgYXMgc2hvd24gYmVsb3c6DQo+DQo+IHNlc3Npb25j YXNlLXBhcmFtICAgICAgICA9ICgic2VzY2FzZSIgRVFVQUwgKCJvcmlnIiAvICJ0ZXJtIikpIC8N Cj4gIm9yaWctY2RpdiIgcmVnaXN0cmF0aW9uLXN0YXRlLXBhcmFtID0gInJlZ3N0YXRlIiBFUVVB TCAoInVucmVnIiAvDQo+ICJyZWciKQ0KPg0KPiBUaGlzIGRyYWZ0IGlzIG5vdCBpbiB0aGUgYWdl bmRhIGZvciBJRVRGIDk4IGJ1dCBjb21tZW50cyBhcmUgd2VsY29tZWQNCj4gYW55d2F5Lg0KPg0K PiBCZXN0IHJlZ2FyZHMsIE1hcmlhbm5lDQo+DQo+DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ DQo+ICBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl cyBpbmZvcm1hdGlvbnMNCj4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk b2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsDQo+IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UNCj4gcGFyIGVycmV1 ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu c2kNCj4gcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzDQo+IGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZQ0KPiBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLg0KPg0KPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCj4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QNCj4gYmUgZGlzdHJpYnV0 ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4gSWYgeW91IGhhdmUNCj4g cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcw0KPiBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuIEFzIGVtYWlscyBt YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdA0KPiBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gVGhhbmsgeW91Lg0K Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzaXBj b3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYu b3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUg bWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcg bGlzdA0Kc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQo= --_000_7ff26f92f4114c28aeddf198b37c2b12HE105828emea1cdstintern_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJTcHJlY2hibGFzZW50ZXh0IFpjaG4iOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5TcHJlY2hibGFzZW50ZXh0WmNo bg0KCXttc28tc3R5bGUtbmFtZToiU3ByZWNoYmxhc2VudGV4dCBaY2huIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6U3ByZWNoYmxhc2VudGV4dDsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJERSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50LiBJIHRoaW5rIGl0 IGlzIHN1ZmZpY2llbnQgdGhhdCBvbmx5IHdpdGggdGhlIGFwcGVhcmFuY2Ugb2YgdGhlIHBhcmFt ZXRlciBpdCBpcyBzaG93biB0aGF0IGEgb3JpZy1jZGl2IGhhcyBiZWVuIGRvbmUuDQogVGhlIG91 dGdvaW5nIGxlZyBvZiB0aGUgUy1DU0NGIGhhcyB0byBrbm93IGlmIGEgQ0RJViBhcHBlYXJlZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsbCBzdGFuZGFyZCBw cm9jZWR1cmVzLCBpLmUuIG5vIGNkaXYgYXBwZWFyZWQsIHdpbGwgYmUgdHJpZ2dlcmVkIGFueXdh eS4gVGhpcyBkb2VzIG5vdCBuZWVkIGEgb3JpZy1jZGl2PW5vLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGtlZXAgaW4gbWluZCB0aGlzIGRyYWZ0IGlz IDNHUFAgSU1TIHNwZWNpZmljLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Sb2xhbmQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPlZvbjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g UmFuaml0IEF2YXNhcmFsYSBbbWFpbHRvOnJhbmppdGthdjA4MTFAZ21haWwuY29tXQ0KPGJyPg0K PGI+R2VzZW5kZXQ6PC9iPiBEaWVuc3RhZywgNC4gQXByaWwgMjAxNyAxNzoyODxicj4NCjxiPkFu OjwvYj4gSmVzc2tlLCBSb2xhbmQ8YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5DYzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IG1haG9uZXlAbm9zdHJ1bS5jb207IFNJUENPUkU8YnI+DQo8Yj5C ZXRyZWZmOjwvYj4gUmU6IFtzaXBjb3JlXSBEcmFmdCBuZXc6IGRyYWZ0LW1vaGFsaS1zaXBjb3Jl LW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1lPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij50ZXItMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg cmVhZCB0aHJ1IHRoZSBkcmFmdCBhbmQgeWVzIHRoZSBhZGRpdGlvbmFsIHBhcmFtZXRlciBpbiBQ LVNlcnZlZC11c2VyIG1ha2VzIHNlbnNlIHRvIGJldHRlciBoYW5kbGUgY2FsbCBkaXZlcnNpb24g c2VydmljZS4mbmJzcDsgQnV0IEkgdGhpbmsgYSB2YWx1ZSBmb3IgJnF1b3Q7b3JpZy1jZGl2JnF1 b3Q7IG1heSBiZSByZXF1aXJlZCAuIGUuZyBvcmlnLWNkaXY9eWVzIChkZWZhdWx0KS4gJm5ic3A7 dGhvdWdoIEkgZG8gbm90IGhhdmUgYSB1c2UNCiBjYXNlIGZvciBvcmlnLWNkaXY9bm8gYXMgb2Yg bm93LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5SZWdhcmRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5SYW5qaXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE1hciAzMSwgMjAxNyBhdCA3OjI5IEFNLCAmbHQ7PGEg aHJlZj0ibWFpbHRvOlIuSmVzc2tlQHRlbGVrb20uZGUiIHRhcmdldD0iX2JsYW5rIj5SLkplc3Nr ZUB0ZWxla29tLmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBKZWFuLDxicj4NCkkgaGF2ZSByZWFkIE1hcmlhbm5lJ3MgZHJhZnQgYW5kIHN1 cHBvcnQgdGhlIGRyYWZ0IHRvIGJlY29tZSBhIFdHIGRvY3VtZW50Ljxicj4NCkJlc3QgUmVnYXJk czxicj4NCjxicj4NClJvbGFuZDxicj4NCjxicj4NCi0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJp Y2h0LS0tLS08YnI+DQpWb246IHNpcGNvcmUgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c2lwY29y ZS1ib3VuY2VzQGlldGYub3JnIj5zaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBJbSBBdWZ0 cmFnIHZvbiBBLiBKZWFuIE1haG9uZXk8YnI+DQpHZXNlbmRldDogRG9ubmVyc3RhZywgMzAuIE3D pHJ6IDIwMTcgMTc6MjI8YnI+DQpBbjogPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmci PnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KQmV0cmVmZjogUmU6IFtzaXBjb3JlXSBEcmFmdCBu ZXc6IGRyYWZ0LW1vaGFsaS1zaXBjb3JlLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVyLTAwPGJy Pg0KPGJyPg0KSGkgYWxsLDxicj4NCjxicj4NCkkgbWVudGlvbmVkIHRoaXMgZHJhZnQgZHVyaW5n IHRoZSBXRyBzZXNzaW9uIHRvZGF5LiBEb2VzIGFueW9uZSBoYXZlIGFueSBjb21tZW50cyBvbiB0 aGUgZHJhZnQ/IFNob3VsZCBpdCBiZWNvbWUgYSBXRyBkb2N1bWVudD88YnI+DQo8YnI+DQpUaGFu a3MhPGJyPg0KPGJyPg0KSmVhbjxicj4NCjxicj4NCk9uIDMvMTIvMTcgNDoyMiBQTSwgPGEgaHJl Zj0ibWFpbHRvOm1hcmlhbm5lLm1vaGFsaUBvcmFuZ2UuY29tIj5tYXJpYW5uZS5tb2hhbGlAb3Jh bmdlLmNvbTwvYT4gd3JvdGU6PGJyPg0KJmd0OyBIaSBhbGwsPGJyPg0KJmd0Ozxicj4NCiZndDsg UGxlYXNlIGZpbmQgaGVyZWFmdGVyIGEgbmV3IHZlcnNpb24gb2YgSS1ELDxicj4NCiZndDsgZHJh ZnQtbW9oYWxpLXNpcGNvcmUtb3JpZ2luYXRpbmctY2Rpdi1wYXJhbWV0ZXItMDAgKHdhczxicj4N CiZndDsgZHJhZnQtbW9oYWxpLWRpc3BhdGNoLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVyLTAz KS48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1tb2hhbGktc2lwY29yZS1vcmlnaW5hdGluZy0iIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tb2hhbGktc2lwY29yZS1v cmlnaW5hdGluZy08L2E+PGJyPg0KJmd0OyBjZGl2LXBhcmFtZXRlci0wMC50eHQ8YnI+DQomZ3Q7 PGJyPg0KJmd0OyZuYnNwOyBCYXNlZCBvbiBBRHMgYW5kIENoYWlycyBndWlkYW5jZSwgdGhpcyBk cmFmdCBpcyBtb3ZlZCBmcm9tIERJU1BBVENIPGJyPg0KJmd0OyB0byBTSVBDT1JFIGZvbGxvd2lu ZyB0aGUgbmV3IGNoYXJ0ZXIgb2Ygc2lwY29yZSBXRy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBYnN0 cmFjdDogVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSBuZXcgcGFyYW1ldGVyIG9mIHRoZTxi cj4NCiZndDsgUC1TZXJ2ZWQtVXNlciBoZWFkZXIgZmllbGQgaW4gdGhlIFNlc3Npb24gSW5pdGlh dGlvbiBQcm90b2NvbCAoU0lQKS48YnI+DQomZ3Q7IFRoaXMgbmV3ICZxdW90O29yaWctY2RpdiZx dW90OyBwYXJhbWV0ZXIgZGVmaW5lcyB0aGUgc2Vzc2lvbiBjYXNlIHVzZWQgYnkgYTxicj4NCiZn dDsgcHJveHkgd2hlbiBoYW5kbGluZyBhbiBvcmlnaW5hdGluZyBzZXNzaW9uIGFmdGVyIENhbGwg RGl2ZXJzaW9uPGJyPg0KJmd0OyAoQ0RJVikgc2VydmljZXMgaGFzIGJlZW4gaW52b2tlZCBmb3Ig dGhlIHNlcnZlZCB1c2VyLiZuYnNwOyBUaGU8YnI+DQomZ3Q7IFAtU2VydmVkLVVzZXIgaGVhZGVy IGZpZWxkIGlzIGRlZmluZWQgaW4gUkZDNTUwMiB0byBjb252ZXkgdGhlPGJyPg0KJmd0OyBpZGVu dGl0eSBvZiB0aGUgc2VydmVkIHVzZXIgYW5kIHRoZSBzZXNzaW9uIGNhc2UgdGhhdCBhcHBsaWVz IHRvIHRoaXM8YnI+DQomZ3Q7IHBhcnRpY3VsYXIgY29tbXVuaWNhdGlvbiBzZXNzaW9uIGFuZCBh cHBsaWNhdGlvbiBpbnZvY2F0aW9uLiZuYnNwOyBUaGlzPGJyPg0KJmd0OyBkb2N1bWVudCB1cGRh dGVzIFJGQzU1MDIgdG8gYWRkIHRoZSAmcXVvdDtvcmlnaW5hdGluZyBhZnRlciBDRElWJnF1b3Q7 IHNlc3Npb248YnI+DQomZ3Q7IGNhc2UgYW5kIHRvIHByb3ZpZGUgbW9yZSBndWlkYW5jZSBmb3Ig dXNpbmcgdGhlIFAtU2VydmVkLVVzZXIgaGVhZGVyPGJyPg0KJmd0OyBmaWVsZCBpbiBJUCBuZXR3 b3JrcyB0aGF0IHdlcmUgbWlzc2luZyBpbiBSRkM1NTAyLjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0 OyBGcm9tIHRoZSBkaXNjdXNzaW9uIGluIERJU1BBVENILCBpbiB0aGlzIHZlcnNpb24gb2YgdGhl IGRyYWZ0LCB0aGU8YnI+DQomZ3Q7Jmd0OyBzeW50YXggb2YgdGhlIGhlYWRlciBjb3VsZCBiZSBp bXByb3ZlZCBhcyBzaG93biBiZWxvdzo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBzZXNzaW9uY2FzZS1w YXJhbSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA9ICgmcXVvdDtzZXNjYXNlJnF1b3Q7IEVR VUFMICgmcXVvdDtvcmlnJnF1b3Q7IC8gJnF1b3Q7dGVybSZxdW90OykpIC88YnI+DQomZ3Q7ICZx dW90O29yaWctY2RpdiZxdW90OyByZWdpc3RyYXRpb24tc3RhdGUtcGFyYW0gPSAmcXVvdDtyZWdz dGF0ZSZxdW90OyBFUVVBTCAoJnF1b3Q7dW5yZWcmcXVvdDsgLzxicj4NCiZndDsgJnF1b3Q7cmVn JnF1b3Q7KTxicj4NCiZndDs8YnI+DQomZ3Q7IFRoaXMgZHJhZnQgaXMgbm90IGluIHRoZSBhZ2Vu ZGEgZm9yIElFVEYgOTggYnV0IGNvbW1lbnRzIGFyZSB3ZWxjb21lZDxicj4NCiZndDsgYW55d2F5 Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEJlc3QgcmVnYXJkcywgTWFyaWFubmU8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zPGJyPg0KJmd0OyBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRy ZSBkaWZmdXNlcyw8YnI+DQomZ3Q7IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2U8YnI+DQomZ3Q7IHBhciBlcnJldXIsIHZl dWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpPGJy Pg0KJmd0OyBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl cyBldGFudCBzdXNjZXB0aWJsZXM8YnI+DQomZ3Q7IGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZTxicj4NCiZndDsgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3I8 YnI+DQomZ3Q7IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzsgdGhleSBzaG91bGQgbm90PGJyPg0KJmd0OyBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLiBJZiB5b3UgaGF2ZTxicj4NCiZndDsgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpczxicj4NCiZndDsgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLiBBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Q8YnI+DQomZ3Q7IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxicj4NCiZn dDsgVGhhbmsgeW91Ljxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fIHNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8 YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9yZzwvYT4gPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNv cmU8L2E+PGJyPg0KJmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8 L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzaXBj b3JlQGlldGYub3JnIj5zaXBjb3JlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7ff26f92f4114c28aeddf198b37c2b12HE105828emea1cdstintern_-- From nobody Wed Apr 5 03:24: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 0BB80126BFD for ; Wed, 5 Apr 2017 03:24:24 -0700 (PDT) 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 jcckV5PGuGjz for ; Wed, 5 Apr 2017 03:24:22 -0700 (PDT) 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 77415127201 for ; Wed, 5 Apr 2017 03:24:22 -0700 (PDT) X-AuditID: c1b4fb30-ea83298000006667-d6-58e4c5d4f9df Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 38.10.26215.4D5C4E85; Wed, 5 Apr 2017 12:24:20 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.158]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0339.000; Wed, 5 Apr 2017 12:23:08 +0200 From: Christer Holmberg To: "drafts-expert-review@iana.org" , "sipcore@ietf.org" , "draft-ietf-sipcore-status-unwanted.all@tools.ietf.org" Thread-Topic: [IANA #953831] expert review for draft-ietf-sipcore-status-unwanted (sip-parameters) Thread-Index: AQHSrZPhhWNm7fr/4UCwss+LYPtvhqG2o+eA Date: Wed, 5 Apr 2017 10:23:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <971C8CC56842AC47A0EF72CD30328D5A@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2K7ru6Vo08iDDb+VbJoX7iY2eLT33CL FRsOsFp8/bGJzYHF4+/7D0wePfIeS5b8ZPL4cvkzWwBLFJdNSmpOZllqkb5dAlfGva8vGAvm cVUsed7K1sC4gqOLkZNDQsBEomnFefYuRi4OIYH1jBJ7N75lgnAWM0qcbZrE0sXIwcEmYCHR /U8bJC4i8JBR4vHKecwg3cwCxhI3Nl9jAbGFBZIlpp7rYQepFxFIkbjaHwoSFhEwkti7Yy0z SJhFQEVi7cJ8kDCvgLXEta4PLBCrzjJKLGtYDTaSU8BRov/fLbCRjAJiEt9PrWGCWCUucevJ fCaIowUkluw5zwxhi0q8fPyPFcQWFdCT2PfvKxvILgkBJYlpW9MgWvUkbkydwgZhW0vMuDWT BcLWlli28DUzxD2CEidnPmGZwCg+C8m2WUjaZyFpn4WkfRaS9gWMrKsYRYtTi5Ny042M9FKL MpOLi/Pz9PJSSzYxAuPx4JbfBjsYXz53PMQowMGoxMP7YNnjCCHWxLLiytxDjBIczEoivI2r n0QI8aYkVlalFuXHF5XmpBYfYpTmYFES53XcdyFCSCA9sSQ1OzW1ILUIJsvEwSnVwMgq/zDc 7/5PnslXZmzexv5E80NKZ/XGJ7aSBvl/vm6Tey1/82Hlt+fX64vnfJtj+9mOc2VdaMUT2ZwW 4UIfwVVb9n3Iv+elVrVYa2pb7SYuW4tFey7eX/zf6MIDLf7+2E1z3jI+m3HpS32Ere87Rb25 qcuOLv8wKd+1fob66piFZ3t+K0h8We+qxFKckWioxVxUnAgAde/AkcMCAAA= Archived-At: Subject: Re: [sipcore] [IANA #953831] expert review for draft-ietf-sipcore-status-unwanted (sip-parameters) 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, 05 Apr 2017 10:24:24 -0000 Hi, I have performed an expert review of the sip.666 feature capability indicator defined in draft-ietf-sipcore-status-unwanted. In general the registration is ok: 1. The feature capability indicator is to be used in a SIP REGISTER response, which is appropriate usage. 2. The feature capability indicator indicates support of a feature (a SIP response code). 3. The reference provides information on how the feature capability indicator is used. 4. The mandatory information for registering a feature capability indicator is properly provided. NOTE: There has been a discussion to change the response code value from 666 to something else. Such change would also impact the name of the feature capability indicator. I guess the chairs/AD can give more input on the status of that discussion. One editorial comments on the Description: Q: I suggest to say: "This feature-capability indicator, when included in a Feature-Caps header field of a REGISTER response, indicates that the server supports, and will process, the 666 (Unwanted) response code." While the current text isn=B9t wrong, the suggested change makes the text more aligned with the style used in the descriptions of the currently registered feature capability indicators. Regards, Christer From nobody Wed Apr 5 12:05: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 E1640127B5A for ; Wed, 5 Apr 2017 12:05:08 -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, 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 ob43gjol5dJ2 for ; Wed, 5 Apr 2017 12:05:07 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 013DC126C26 for ; Wed, 5 Apr 2017 12:05:05 -0700 (PDT) X-AuditID: c1b4fb3a-baef298000005492-64-58e53fdfde72 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id BA.EF.21650.FDF35E85; Wed, 5 Apr 2017 21:05:04 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.158]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0339.000; Wed, 5 Apr 2017 21:05:01 +0200 From: Christer Holmberg To: "sipcore@ietf.org" CC: "sipcore-chairs@tools.ietf.org" Thread-Topic: IETF#98: SIPCORE notes (Christer) Thread-Index: AdKuRxQZMH0rQBy3TnWHUYiW+p6R2Q== Date: Wed, 5 Apr 2017 19:05:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB4C731@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB4C731ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2J7iO4D+6cRBl0TWC1OvTrNbPH1xyY2 ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvj9/aHLAX9lxkrun98YWlg3LeDsYuRk0NC wETi3Ly9bF2MXBxCAusZJebNf8YE4SxmlLi6bhZQFQcHm4CFRPc/bZAGEQFNieXftrKD2MwC zhK3t21gAikRFtCSmHvUC6JEX2LJ9T8sELaexPUHXWBTWARUJOY2RYGEeQV8JRrutrKC2IwC YhLfT61hgpgoLnHryXwmiNMEJJbsOc8MYYtKvHz8jxXCVpJYsf0SI0R9vkT75AXsEDMFJU7O fMIygVFoFpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxihanFhfnphsZ 6aUWZSYXF+fn6eWllmxiBMbJwS2/rXYwHnzueIhRgINRiYc34ceTCCHWxLLiytxDjBIczEoi vOrvgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5HfZdiBASSE8sSc1OTS1ILYLJMnFwSjUwZjVe vfv44Ez3S7Uh9wM21uw7wW42WbJ90uIAy7s+nJXTbDct+l6T9Idprfdv4XfzlZX3yi8sMb3a F3ztrMpbmw2FAgfmXTwZ/c33/dZHG0U7AlL3/2fO/62Ter9p1aKj2l+3h/sv1zt8rGVD6uv9 f+WO3LLN1JkzOWMNo4hByedlp39aJru3hCuxFGckGmoxFxUnAgB/2BSzjwIAAA== Archived-At: Subject: [sipcore] IETF#98: SIPCORE notes (Christer) 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, 05 Apr 2017 19:05:09 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB4C731ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below are my notes from the SIPCORE session. Regards, Christer --------------------------------------------------------------------------- Topic: SIP Call-Info Parameters for Labeling Calls Presenter: Henning Schulzrinne Draft: draft-ietf-sipcore-callinfo-spam-00 What is it? - Defines SIP Call-Info parameters and a feature tag that allow or= iginating, intermediate and terminating SIP entities to label calls as to t= heir type, spam probability and references to additional information. Presentation in a nutshell? - Generic presentation about robocalls. - Some are illegal, some are legal but unwanted, and some are want= ed/helpful. - Call filtering can be done by carriers themselves, by carriers u= sing third-party tools, or by a device itself. - Presentation of new SIP Call-Info header field parameters and an= associated feature capability indicator. What did people say? - It was asked whether it would be better to insert the informatio= n in the STIR PASSPortT structure instead. Indicated that it could be part = of PASSPorT in the future. Ok, so what next? - Additional comments are welcome. - ACTION POINT: Christer H and Paul K will review the feature capa= bility indicator. ------------ Topic: Location Source Parameter for the SIP Geolocation H= eader Field Presenter: Roland Jesske Draft: draft-winterbottom-sipcore-locparam-00 What is it? - Adds parameter to the Geolocation header field values to indicat= e the node that added the value. Presentation in a nutshell? - Indicated that the feature is required by ETSI M/493 in order to= assist downstream nodes. - Proposed to adopt the draft by the SIPCORE WG and initiate WGLC. What did people say? - Some had issues with the use of domain name to indicate nodes. - The chairs asked people to review the draft. Ok, so what next? - The discussion will continue on the mailing list. Topic: Third-Party Authentication for Session Initiation P= rotocol (SIP) Presenter: Rifaat Shekh-Yusef Draft: draft-yusef-sipcore-sip-authn-01 What is it? - Authentication mechanism for SIP, that is based on the OAuth 2.0= and OpenID Connect Core 1.0 specifications. Presentation in a nutshell? - Difference between the draft and a previous draft. The new draft= is a scaled down version, where previously controversial parts have been r= emoved. What did people say? - Jon Peterson, who raised issues on the previous draft, indicated= that he has some minor issues, but that he is ok with the scope of the dra= ft and moving it forward. Ok, so what next? - The chairs did a hum regarding taking on the work. - OUTCOME: There was a clear consensus for taking on the work. Topic: ISUP Cause Location Parameter for the SIP Reason He= ader Field Presenter: Roland Jesske Draft: draft-jesske-sipcore-reason-q850-loc-00 - The draft had previously been discussed in DISPATCH (see notes f= or more information), where it was decided to move the draft to the SIPCORE= WG and let SIPCORE decided on whether take on the work. Ok, so what next? - The chairs did a hum regarding taking on the work. - OUTCOME: There was a clear consensus for taking on the work. Topic: The Session Initiation Protocol (SIP) Digest Authen= tication Scheme Presenter: Rifaat Shekh-Yusef Draft: draft-yusef-sipcore-digest-scheme-05 What is it? - Updates the Digest Access Authentication scheme used by the Sess= ion Initiation Protocol (SIP) to add support for SHA2 digest algorithms to = replace the MD5 algorithm Presentation in a nutshell? - Background what has happened for HTTP, and to apply the same for= SIP. - Indicated that forking could potentially cause problems, if mult= iple servers are to be authenticated by the client. What did people say? - It was questioned whether there is a need for a UA to authentica= te multiple servers. It was indicated that it would be problematic with cur= rent behaviour of forking proxies. Nobody could identity a case where it wo= uld be needed. - Indicated that similar algorithm update is also done for STUN, s= o the author was advised to take a look at the STUNbis draft. Ok, so what next? - No decision was made. Discussions will continue on the list. --_000_7594FB04B1934943A5C02806D1A2204B4CB4C731ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

Below are my notes from the SIPCORE session.

 

Regards,

 

Christer

 

----------------------------------------------------= -----------------------

 

Topic:       &= nbsp;          SIP Call-Info P= arameters for Labeling Calls

Presenter:      &nb= sp;   Henning Schulzrinne

Draft:       &= nbsp;          draft-ietf-sipc= ore-callinfo-spam-00

 

What is it?

 

-     &= nbsp;    Defines 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 infor= mation.

 

Presentation in a nutshell?

 

-     &= nbsp;    Generic presentation about robocalls.

-     &= nbsp;    Some are illegal, some are legal but unwanted, and = some are wanted/helpful.

-     &= nbsp;    Call filtering can be done by carriers themselves, = by carriers using third-party tools, or by a device itself.

-     &= nbsp;    Presentation of new SIP Call-Info header field para= meters and an associated feature capability indicator.

 

What did people say?

 

-     &= nbsp;    It was asked whether it would be better to insert t= he information in the STIR PASSPortT structure instead. Indicated that it c= ould be part of PASSPorT in the future.

 

Ok, so what next?

 

-     &= nbsp;    Additional comments are welcome.

-     &= nbsp;    ACTION POINT: Christer H and Paul K will review the= feature capability indicator.

 

------------

 

Topic:       &= nbsp;          Location Source= Parameter for the SIP Geolocation Header Field

Presenter:      &nb= sp;   Roland Jesske

Draft:       &= nbsp;          draft-winterbot= tom-sipcore-locparam-00

 

What is it?

 

-     &= nbsp;    Adds parameter to the Geolocation header field valu= es to indicate the node that added the value.

Presentation in a nutshell?

 

-     &= nbsp;    Indicated that the feature is required by ETSI M/49= 3 in order to assist downstream nodes.

-     &= nbsp;    Proposed to adopt the draft by the SIPCORE WG and i= nitiate WGLC.

 

What did people say?

 

-     &= nbsp;    Some had issues with the use of domain name to indi= cate nodes.

-     &= nbsp;    The chairs asked people to review the draft.

 

Ok, so what next?

 

-     &= nbsp;    The discussion will continue on the mailing list.

 

 

Topic:       &= nbsp;          Third-Party Aut= hentication for Session Initiation Protocol (SIP)

Presenter:      &nb= sp;   Rifaat Shekh-Yusef

Draft:       &= nbsp;          draft-yusef-sip= core-sip-authn-01

 

What is it?

 

-     &= nbsp;    Authentication mechanism for SIP, that is based on = the OAuth 2.0 and OpenID Connect Core 1.0 specifications.

 

Presentation in a nutshell?

 

-     &= nbsp;    Difference between the draft and a previous draft. = The new draft is a scaled down version, where previously controversial part= s have been removed.

 

What did people say?

 

-     &= nbsp;    Jon Peterson, who raised issues on the previous dra= ft, indicated that he has some minor issues, but that he is ok with the sco= pe of the draft and moving it forward.

 

Ok, so what next?

 

-     &= nbsp;    The chairs did a hum regarding taking on the work. =

-     &= nbsp;    OUTCOME: There was a clear consensus for taking on = the work.

 

 

Topic:       &= nbsp;          ISUP Cause Loca= tion Parameter for the SIP Reason Header Field

Presenter:      &nb= sp;   Roland Jesske

Draft:        =           draft-jesske-sipcore= -reason-q850-loc-00

 

-     &= nbsp;    The draft had previously been discussed in DISPATCH= (see notes for more information), where it was decided to move the draft t= o the SIPCORE WG and let SIPCORE decided on whether take on the work.<= /o:p>

 

Ok, so what next?

 

-     &= nbsp;    The chairs did a hum regarding taking on the work. =

-     &= nbsp;    OUTCOME: There was a clear consensus for taking on = the work.

 

 

Topic:       &= nbsp;          The Session Ini= tiation Protocol (SIP) Digest Authentication Scheme

Presenter:      &nb= sp;   Rifaat Shekh-Yusef

Draft:       &= nbsp;          draft-yusef-sip= core-digest-scheme-05

 

What is it?

 

-     &= nbsp;    Updates the Digest Access Authentication scheme use= d by the Session Initiation Protocol (SIP) to add support for SHA2 digest a= lgorithms to replace the MD5 algorithm

 

Presentation in a nutshell?

 

-     &= nbsp;    Background what has happened for HTTP, and to apply= the same for SIP.

-     &= nbsp;    Indicated that forking could potentially cause prob= lems, if multiple servers are to be authenticated by the client.=

 

What did people say?

 

-     &= nbsp;    It was questioned whether there is a need for a UA = to authenticate multiple servers. It was indicated that it would be problem= atic with current behaviour of forking proxies. Nobody could identity a cas= e where it would be needed.

-     &= nbsp;    Indicated that similar algorithm update is also don= e for STUN, so the author was advised to take a look at the STUNbis draft.<= o:p>

 

Ok, so what next?

 

-     &= nbsp;    No decision was made. Discussions will continue on = the list.

--_000_7594FB04B1934943A5C02806D1A2204B4CB4C731ESESSMB109erics_-- From nobody Wed Apr 5 13:12: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 CC115129490 for ; Wed, 5 Apr 2017 13:12: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 9DJDHTxy6Vx2 for ; Wed, 5 Apr 2017 13:12:23 -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 E32C812948A for ; Wed, 5 Apr 2017 13:12:22 -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 v35KCHSj012035 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 5 Apr 2017 15:12:18 -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: Christer Holmberg , "sipcore@ietf.org" Cc: "sipcore-chairs@tools.ietf.org" References: <7594FB04B1934943A5C02806D1A2204B4CB4C731@ESESSMB109.ericsson.se> From: "A. Jean Mahoney" Message-ID: <0ab1c9cd-58f3-3b41-d286-f3865f54cec0@nostrum.com> Date: Wed, 5 Apr 2017 15:12:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB4C731@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] IETF#98: SIPCORE notes (Christer) 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, 05 Apr 2017 20:12:25 -0000 Thank you for the notes, Christer! Session participants, please review and send any corrections to the list. Jean On 4/5/17 2:05 PM, Christer Holmberg wrote: > Hi, > > Below are my notes from the SIPCORE session. > > Regards, > > Christer > > --------------------------------------------------------------------------- > > *Topic: SIP Call-Info Parameters for Labeling Calls* > > *Presenter: Henning Schulzrinne* > > *Draft: draft-ietf-sipcore-callinfo-spam-00* > > What is it? > > -Defines 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. > > Presentation in a nutshell? > > -Generic presentation about robocalls. > > -Some are illegal, some are legal but unwanted, and some are wanted/helpful. > > -Call filtering can be done by carriers themselves, by carriers using > third-party tools, or by a device itself. > > -Presentation of new SIP Call-Info header field parameters and an > associated feature capability indicator. > > What did people say? > > -It was asked whether it would be better to insert the information in > the STIR PASSPortT structure instead. Indicated that it could be part of > PASSPorT in the future. > > Ok, so what next? > > -Additional comments are welcome. > > -ACTION POINT: Christer H and Paul K will review the feature capability > indicator. > > ------------ > > *Topic: Location Source Parameter for the SIP > Geolocation Header Field* > > *Presenter: Roland Jesske* > > *Draft: draft-winterbottom-sipcore-locparam-00* > > What is it? > > -Adds parameter to the Geolocation header field values to indicate the > node that added the value. > > Presentation in a nutshell? > > -Indicated that the feature is required by ETSI M/493 in order to assist > downstream nodes. > > -Proposed to adopt the draft by the SIPCORE WG and initiate WGLC. > > What did people say? > > -Some had issues with the use of domain name to indicate nodes. > > -The chairs asked people to review the draft. > > Ok, so what next? > > -The discussion will continue on the mailing list. > > *Topic: Third-Party Authentication for Session > Initiation Protocol (SIP)* > > *Presenter: Rifaat Shekh-Yusef* > > *Draft: draft-yusef-sipcore-sip-authn-01* > > What is it? > > -Authentication mechanism for SIP, that is based on the OAuth 2.0 and > OpenID Connect Core 1.0 specifications. > > Presentation in a nutshell? > > -Difference between the draft and a previous draft. The new draft is a > scaled down version, where previously controversial parts have been removed. > > What did people say? > > -Jon Peterson, who raised issues on the previous draft, indicated that > he has some minor issues, but that he is ok with the scope of the draft > and moving it forward. > > Ok, so what next? > > -The chairs did a hum regarding taking on the work. > > -OUTCOME: There was a clear consensus for taking on the work. > > *Topic: ISUP Cause Location Parameter for the SIP > Reason Header Field* > > *Presenter: Roland Jesske* > > *Draft: draft-jesske-sipcore-reason-q850-loc-00* > > -The draft had previously been discussed in DISPATCH (see notes for more > information), where it was decided to move the draft to the SIPCORE WG > and let SIPCORE decided on whether take on the work. > > Ok, so what next? > > -The chairs did a hum regarding taking on the work. > > -OUTCOME: There was a clear consensus for taking on the work. > > *Topic: The Session Initiation Protocol (SIP) Digest > Authentication Scheme* > > *Presenter: Rifaat Shekh-Yusef* > > *Draft: draft-yusef-sipcore-digest-scheme-05* > > What is it? > > -Updates the Digest Access Authentication scheme used by the Session > Initiation Protocol (SIP) to add support for SHA2 digest algorithms to > replace the MD5 algorithm > > Presentation in a nutshell? > > -Background what has happened for HTTP, and to apply the same for SIP. > > -Indicated that forking could potentially cause problems, if multiple > servers are to be authenticated by the client. > > What did people say? > > -It was questioned whether there is a need for a UA to authenticate > multiple servers. It was indicated that it would be problematic with > current behaviour of forking proxies. Nobody could identity a case where > it would be needed. > > -Indicated that similar algorithm update is also done for STUN, so the > author was advised to take a look at the STUNbis draft. > > Ok, so what next? > > -No decision was made. Discussions will continue on the list. > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Apr 6 01:19:06 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 8392F124281 for ; Thu, 6 Apr 2017 01:19:04 -0700 (PDT) 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 9G3hMg_CgZ72 for ; Thu, 6 Apr 2017 01:19:03 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 2EF3B12940B for ; Thu, 6 Apr 2017 01:18:59 -0700 (PDT) X-AuditID: c1b4fb2d-18964980000033e1-59-58e5f9f26aca Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 13.04.13281.1F9F5E85; Thu, 6 Apr 2017 10:18:58 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.158]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0339.000; Thu, 6 Apr 2017 10:17:54 +0200 From: Christer Holmberg To: "sipcore@ietf.org" CC: "draft-ietf-sipcore-callinfo-spam.all@tools.ietf.org" Thread-Topic: callinfo-spam: review of sip.call-info.spam feature capability indicator Thread-Index: AQHSrq5J+i8BhoeC3UGtAh/+efsIWA== Date: Thu, 6 Apr 2017 08:17:53 +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.2.170228 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3A5BCA423AF0D741AE20042B9E65463A@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbHdW/fTz6cRBusOy1hcXzyD3eLrj01s DkweS5b8ZPL4cvkzWwBTFJdNSmpOZllqkb5dAlfGybVbGAsW8lW0rf7A3sDYyt3FyMkhIWAi cXD9EzYQW0hgPaNEx47ULkYuIHsxo8ShrlPsXYwcHGwCFhLd/7RBakQENCWWf9vKDmIzCxRK vDrQAGYLCwRL3P5yjhWkXEQgQuLHFA2Icj2JVV0zmUBsFgEVicZJh5lBSngFrCW2/vEBCTMK iEl8P7WGCWKiuMStJ/OZIC4TkFiy5zwzhC0q8fLxP1YQWxRo5L5/X9kg4ooSO8+2M0P06knc mDqFDcK2lrh59T6UrS2xbOFrsBpeAUGJkzOfsExgFJ2FZN0sJO2zkLTPQtI+C0n7AkbWVYyi xanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBkXNwy2/dHYyrXzseYhTgYFTi4U348SRCiDWxrLgy 9xCjBAezkgiv+nugEG9KYmVValF+fFFpTmrxIUZpDhYlcV6HfRcihATSE0tSs1NTC1KLYLJM HJxSDYzruiTXKwa46JZcbP8Yv/hl8Mb6RdsreWzvMXzPffDTYt2RC4E5D/6vnn23YfVXn7zo o7dvz72Y/CY8y/2B5v+k9nMGBzkEA1V2vGave//nWGuG1ozJV7IrelMM3uyJfeeRIDg1MrX8 hPEbh+Vv0sXumq1kbrUVMjkmfPUAr48Oq6HzsQkzbr1SYinOSDTUYi4qTgQAvRHd6pgCAAA= Archived-At: Subject: [sipcore] callinfo-spam: review of sip.call-info.spam feature capability indicator 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, 06 Apr 2017 08:19:04 -0000 Hi, In Chicago, I was asked to take a look at the sip.call-info.spam feature capability indicator (fci), defined and used in draft-ietf-sipcore-callinfo-spam-00. General: Q1: I think there should be some more information on how the fci is used. For example, including a REGISTER response which contains the fci. Q2: Related to Q1, there is no text regarding the procedures of the receiver (i.e., the called party) of the fci. Section 3: Q3: s/a new feature tag/a new feature capability indicator Q4: The text says: "indicates whether the terminating carrier will remove untrusted information." The text should also include the name of the feature that the terminating carrier supports. It would also be good to mention how/when the support is indicated in the section. Something like: =B3that the terminating carrier can use in a REGISTER response in order to indicate support of XXX, and that it will remove untrusted information.=B2 Q5: The text says: "SIP entities MUST add a new Call-Info "info" header field instance, rather than add parameters to an existing one.=B2 What SIP entities? Q6: I think the sentence above should also indicate from where untrusted information will be removed. I assume it is from the Call-Info header field. Q7: The text above talks about removing information, which the description in section 8.2 also talks about adding and altering information. I think the text in sections 3 and 8.2 need to be aligned. Section 8.2: Q8: In general, the registration of the fci looks ok. See Q7. Section 9: Q9: The text says: "SIP entities MUST remove any parameters defined here that were provided by untrusted third parties.=B2 What SIP entities? Regards, Christer From nobody Thu Apr 6 12:08: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 B936E129446 for ; Thu, 6 Apr 2017 12:08:42 -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 LR9MkL_t8bBJ for ; Thu, 6 Apr 2017 12:08:41 -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 A2B89129632 for ; Thu, 6 Apr 2017 12:08:40 -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 v36J8df6057744 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 6 Apr 2017 14:08:40 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be mutabilis-2.local From: "A. Jean Mahoney" To: SIPCORE Message-ID: <01194ff4-c044-0861-6a30-3cc54fc0a455@nostrum.com> Date: Thu, 6 Apr 2017 14:08:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] draft-yusef-sipcore-sip-authn - WG item? 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, 06 Apr 2017 19:08:43 -0000 Hi all, During the WG session in Chicago, Rifaat presented this draft, and the chairs took a hum on whether the WG should take on this draft as a WG item. There was consensus at the meeting to take this draft on. Now I'm gauging interest on the mailing list. Please let the list know if you have any objections to taking this work on. Thanks! Jean From nobody Thu Apr 6 12:08:58 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 EC412129627 for ; Thu, 6 Apr 2017 12:08:56 -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 VwviljTyVZWl for ; Thu, 6 Apr 2017 12:08:55 -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 CFB0B1293D9 for ; Thu, 6 Apr 2017 12:08:51 -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 v36J8pNU057764 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 6 Apr 2017 14:08:51 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be mutabilis-2.local From: "A. Jean Mahoney" To: SIPCORE Message-ID: <6222bd21-f1b1-88a2-5afd-1c85825a9bac@nostrum.com> Date: Thu, 6 Apr 2017 14:08:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] draft-jesske-sipcore-reason-q850-loc - WG item? 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, 06 Apr 2017 19:08:57 -0000 Hi all, During the WG session in Chicago, Roland presented this draft, and the chairs took a hum on whether the WG should take on this draft as a WG item. There was consensus at the meeting to take this draft on. Now I'm gauging interest on the mailing list. Please let the list know if you have any objections to taking this work on. Thanks! Jean From nobody Thu Apr 6 12:10: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 51F33128BBB for ; Thu, 6 Apr 2017 12:10:37 -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 CLH8LPjxuNuj for ; Thu, 6 Apr 2017 12:10:35 -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 4A08212741D for ; Thu, 6 Apr 2017 12:10:35 -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 v36J4lQB013000; Thu, 6 Apr 2017 15:10:32 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 29nug487v4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Apr 2017 15:10:31 -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 v36JAUir017377; Thu, 6 Apr 2017 15:10:31 -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 v36JALuf017164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Apr 2017 15:10:25 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 6 Apr 2017 19:10:16 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.163]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0319.002; Thu, 6 Apr 2017 15:10:16 -0400 From: "DOLLY, MARTIN C" To: "A. Jean Mahoney" , SIPCORE Thread-Topic: [sipcore] draft-jesske-sipcore-reason-q850-loc - WG item? Thread-Index: AQHSrwlBw6Ik5h33Bk6Vl8oJ1BkpxqG4tKnA Date: Thu, 6 Apr 2017 19:10:16 +0000 Message-ID: References: <6222bd21-f1b1-88a2-5afd-1c85825a9bac@nostrum.com> In-Reply-To: <6222bd21-f1b1-88a2-5afd-1c85825a9bac@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.63.92] 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-04-06_14:, , 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-1704060155 Archived-At: Subject: Re: [sipcore] draft-jesske-sipcore-reason-q850-loc - WG item? 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, 06 Apr 2017 19:10:37 -0000 I support this being taken on as a WG item. -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean Mahone= y Sent: Thursday, April 06, 2017 3:09 PM To: SIPCORE Subject: [sipcore] draft-jesske-sipcore-reason-q850-loc - WG item? Hi all, During the WG session in Chicago, Roland presented this draft, and the chai= rs took a hum on whether the WG should take on this draft as a WG item. There was consensus at the meeting to take this draft on. Now I'm gauging i= nterest on the mailing list. Please let the list know if you have any objec= tions to taking this work on. Thanks! Jean _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3DqWKx44eKSceDp05yOy_ni-sK4FLNngMz6iPrpTcZ1PA&s=3DR4CQH4ugSxdpFoH= _1FZ7xHAvc3n1mNCf1chEUgkTXgU&e=3D=20 From nobody Thu Apr 6 12:11: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 4984E129413 for ; Thu, 6 Apr 2017 12:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.395 X-Spam-Level: X-Spam-Status: No, score=-5.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 uSMJHPBgYq1d for ; Thu, 6 Apr 2017 12:11:32 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3B112741D for ; Thu, 6 Apr 2017 12:11:32 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id B3F55401F5; Thu, 6 Apr 2017 21:11:30 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 8B9DD1A0061; Thu, 6 Apr 2017 21:11:30 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0319.002; Thu, 6 Apr 2017 21:11:30 +0200 From: To: "DOLLY, MARTIN C" , "A. Jean Mahoney" , SIPCORE Thread-Topic: [sipcore] draft-jesske-sipcore-reason-q850-loc - WG item? Thread-Index: AQHSrwlBEdgHpSyL1UO+1umGn0No/KG4kz8AgAAh1BA= Date: Thu, 6 Apr 2017 19:11:29 +0000 Message-ID: <15428_1491505890_58E692E2_15428_5207_1_8B970F90C584EA4E97D5BAAC9172DBB81C97D419@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <6222bd21-f1b1-88a2-5afd-1c85825a9bac@nostrum.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] 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 - WG item? 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, 06 Apr 2017 19:11:34 -0000 +1 > -----Message d'origine----- > De=A0: sipcore [mailto:sipcore-bounces@ietf.org] De la part de DOLLY, MAR= TIN C > Envoy=E9=A0: jeudi 6 avril 2017 21:10 > =C0=A0: A. Jean Mahoney; SIPCORE > Objet=A0: Re: [sipcore] draft-jesske-sipcore-reason-q850-loc - WG item? >=20 > I support this being taken on as a WG item. >=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean > Mahoney > Sent: Thursday, April 06, 2017 3:09 PM > To: SIPCORE > Subject: [sipcore] draft-jesske-sipcore-reason-q850-loc - WG item? >=20 > Hi all, >=20 > During the WG session in Chicago, Roland presented this draft, and the ch= airs > took a hum on whether the WG should take on this draft as a WG item. >=20 > There was consensus at the meeting to take this draft on. Now I'm gauging > interest on the mailing list. Please let the list know if you have any ob= jections to > taking this work on. >=20 > Thanks! >=20 > Jean >=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=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DqWKx44eKSceDp05y > Oy_ni- > sK4FLNngMz6iPrpTcZ1PA&s=3DR4CQH4ugSxdpFoH_1FZ7xHAvc3n1mNCf1chEUgkT > XgU&e=3D >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore ___________________________________________________________________________= ______________________________________________ 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 Thu Apr 6 12:45:22 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 3CA9B129407 for ; Thu, 6 Apr 2017 12:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 MUEPjOvhfZ9G for ; Thu, 6 Apr 2017 12:45:18 -0700 (PDT) Received: from qproxy4.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) (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 54FA7129639 for ; Thu, 6 Apr 2017 12:45:18 -0700 (PDT) Received: from cmgw2 (unknown [10.0.90.83]) by qproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 01228A12C7 for ; Thu, 6 Apr 2017 13:45:18 -0600 (MDT) Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id 57gF1v0011MNPNq017gJCl; Thu, 06 Apr 2017 13:40:18 -0600 X-Authority-Analysis: v=2.2 cv=LIwWeNe9 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=AzvcPWV-tVgA:10 a=jqBRFv0mrdUA:10 a=ZZnuYtJkoWoA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=Z80JlwQ0AAAA:8 a=WQs5VQhos0FS8CK3NxwA:9 a=OpEF6aJzLM4KoTWQ:21 a=bSe9Ky922Pbc1Svi:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=Zz-tw7mMPhxMdvFcggwQ:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=i0m75mpCpMLnBNtcEqhm1PzjUnlryE6YUZZ176APuFE=; b=IewOSZBcrhf0lT4f94s+3nC9uu 7JaKTDSQrNhUzG6bgJSpvF/J9dtmK1nuTBH+GkwMuzLKA5bDaGL8NbVGkSfm5ILltHB02axkWLwZP E4hL32JRSayWvHyjhQZ4PKznK; Received: from pool-100-36-44-71.washdc.fios.verizon.net ([100.36.44.71]:54342 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.87) (envelope-from ) id 1cwDGQ-0001uw-Qe; Thu, 06 Apr 2017 13:40:14 -0600 User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Thu, 06 Apr 2017 15:40:12 -0400 From: Richard Shockey To: "A. Jean Mahoney" , SIPCORE Message-ID: <87A13571-FC25-4D01-B728-E0C8A380F663@shockey.us> Thread-Topic: [sipcore] draft-jesske-sipcore-reason-q850-loc - WG item? References: <6222bd21-f1b1-88a2-5afd-1c85825a9bac@nostrum.com> In-Reply-To: <6222bd21-f1b1-88a2-5afd-1c85825a9bac@nostrum.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.44.71 X-Exim-ID: 1cwDGQ-0001uw-Qe X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-44-71.washdc.fios.verizon.net ([192.168.1.152]) [100.36.44.71]:54342 X-Source-Auth: richard+shockey.us X-Email-Count: 2 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [sipcore] draft-jesske-sipcore-reason-q850-loc - WG item? 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, 06 Apr 2017 19:45:20 -0000 +1 =20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 On 4/6/17, 3:08 PM, "sipcore on behalf of A. Jean Mahoney" wrote: Hi all, =20 During the WG session in Chicago, Roland presented this draft, and the=20 chairs took a hum on whether the WG should take on this draft as a WG i= tem. =20 There was consensus at the meeting to take this draft on. Now I'm=20 gauging interest on the mailing list. Please let the list know if you=20 have any objections to taking this work on. =20 Thanks! =20 Jean =20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =20 From nobody Thu Apr 6 14:22:18 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 A2CFD1295E4 for ; Thu, 6 Apr 2017 14:22:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Qf4GgHW1nboL for ; Thu, 6 Apr 2017 14:22:15 -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 684041294A4 for ; Thu, 6 Apr 2017 14:22:15 -0700 (PDT) X-AuditID: c1b4fb25-84bff70000006af2-97-58e6b184ff55 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id B8.E7.27378.481B6E85; Thu, 6 Apr 2017 23:22:13 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.339.0; Thu, 6 Apr 2017 23:22:12 +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=L5dDWBq72y9VNrhGa2wrfQzQ3tSTRJPtYOBoPpzr658=; b=aZ1rnLOSoj8dV8weq+CKWFiBn11JYARPYCkCMVupRrtySwB4AapIDcoBq9Wr1Vlu0s9uVoUB8+pqD3cklYYWIA1AuRcO/av7C7IfGuvLaYLKnXrNJfO9vGwexnjEuf1cAcbB1bii0xq3WFsQTxOSS4Zzh9m/isT1WHH/2pAolUI= Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) by AM5PR0701MB2466.eurprd07.prod.outlook.com (10.169.153.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Thu, 6 Apr 2017 21:22:10 +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.1019.019; Thu, 6 Apr 2017 21:22:10 +0000 From: Ivo Sedlacek To: "A. Jean Mahoney" , SIPCORE Thread-Topic: [sipcore] draft-yusef-sipcore-sip-authn - WG item? Thread-Index: AQHSrwlSMg6FrRxplkCt1BJxr8mwDqG42ZNw Date: Thu, 6 Apr 2017 21:22:10 +0000 Message-ID: References: <01194ff4-c044-0861-6a30-3cc54fc0a455@nostrum.com> In-Reply-To: <01194ff4-c044-0861-6a30-3cc54fc0a455@nostrum.com> 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-originating-ip: [67.139.165.143] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2466; 7:CE01Czvgctl6m8PeyrHnC71D/+8wzD5JBLefpfQWebmcgetZ2QC7UFiukqxd9Kv1TxnpxlJ7nMBJ5P3M6CHo3vqVNO8q2Uhj5Fh17SMGhZG4mvrXCRFqI60847A/Dtd6Fx7JTRv6xZP6nQ/u5Et3sqbdzUqMsO5trZnQG5u/vW0ldFBYKMRhonrEKO586v9WDLOWT7GdiUYo1ExOiBWDhbH5zd1Opkip77JP+owiCYEL95OVE80TJlpMTKF32aKXsNheP68OtBrYOGtp+cAvv4kH5Gyh3znIS7sxPjyIJS5WYaup3N5tMBi1WSUb68exDHL5acIJ8naB1MWUXjQopg== x-ms-office365-filtering-correlation-id: 3433a2bb-9d96-42d2-5f21-08d47d32fc80 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2466; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:AM5PR0701MB2466; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2466; x-forefront-prvs: 02698DF457 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39450400003)(39840400002)(39410400002)(377454003)(13464003)(53754006)(6116002)(102836003)(99286003)(2900100001)(122556002)(3846002)(6306002)(9686003)(230783001)(53936002)(86362001)(33656002)(81166006)(8676002)(8936002)(66066001)(6506006)(7736002)(6436002)(3660700001)(305945005)(77096006)(2950100002)(53546009)(3280700002)(25786009)(5660300001)(7696004)(189998001)(2906002)(50986999)(74316002)(54356999)(76176999)(38730400002)(229853002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2466; H:AM5PR0701MB2468.eurprd07.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-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2017 21:22:10.1078 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2466 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42KZGbE9ULd147MIgyeL5C0aOleyWnz9sYnN gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4Mp4sKuZpWAtW8Wi84uZGhinsnYxcnJICJhI /Jn6grGLkYtDSGA9o8SEy4dZIJzjjBJ3X64Ay7AI9DJLNL3cApWZxSRx4sEfVgjnNKPEt+uT 2UGGsQnoSUzccgRssIiAu8Tv5puMILawgL3Eyt1N7BBxB4lJ206yQNhGEhsm3werZxFQkfg+ cxlYDa9AgkTr/xdgNUICdhILfx5hBrE5geb0rNoBZjMKiEl8P7WGCcRmFhCXuPVkPhPEQwIS S/acZ4awRSVePv7HClE/kVGibbNuFyMHUFxJovFCEcj9EgJ9zBKTjl2FqveV6Ot8zAqRaGCU 2LfkAFQiX+LrkgVQC6wlmi9fZoIousokMWfOBKgiGYmZR2ZDdTeySszqgnhNWEBK4u6VTmhQ yEi8uLOXFeJsHYkFuz+xTWDUmIXki1lIUhC2tsSyha+ZZ4FDRlDi5MwnLAsYWVYxihanFifl phsZ66UWZSYXF+fn6eWllmxiBCaPg1t+q+5gvPzG8RCjAAejEg9vwo8nEUKsiWXFlbmHGCU4 mJVEeNXfA4V4UxIrq1KL8uOLSnNSiw8xSnOwKInzOu67ECEkkJ5YkpqdmlqQWgSTZeLglGpg 5Hx/yoj9qdyBROfV5Zvr9gdNkJo97b1y2oKEs/7p21fvnqxT9WR2b4UhW3qx0dJsFefgSe/M pv15PvX6tZms/EujXzgd1enyPaiTeCDj+Mk/ts61WTpBK+T2+a5j3/j05dM5HWu14/p/cS0p LXLV33h0plVR7+0d/rMfnmvrqNdUN9Q+3K/yQomlOCPRUIu5qDgRAE/8lwgaAwAA Archived-At: Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item? 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, 06 Apr 2017 21:22:17 -0000 I support adoption of this draft. Kind regards Ivo -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean Mahone= y Sent: Thursday, April 06, 2017 12:09 PM To: SIPCORE Subject: [sipcore] draft-yusef-sipcore-sip-authn - WG item? Hi all, During the WG session in Chicago, Rifaat presented this draft, and the chai= rs took a hum on whether the WG should take on this draft as a WG item. There was consensus at the meeting to take this draft on. Now I'm gauging i= nterest on the mailing list. Please let the list know if you have any objec= tions to taking this work on. Thanks! Jean _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Apr 6 14:25: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 B36D412946D for ; Thu, 6 Apr 2017 14:24:59 -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 tXACm155rY6O for ; Thu, 6 Apr 2017 14:24:57 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 79BFB12945E for ; Thu, 6 Apr 2017 14:24:56 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v36LFg3I015480; Thu, 6 Apr 2017 17:24:53 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 29nvext7r6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Apr 2017 17:24:53 -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 v36LOq21032500; Thu, 6 Apr 2017 17:24:52 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v36LOddw032291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Apr 2017 17:24:46 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 6 Apr 2017 21:24:25 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.163]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0319.002; Thu, 6 Apr 2017 17:24:25 -0400 From: "DOLLY, MARTIN C" To: Ivo Sedlacek , "A. Jean Mahoney" , SIPCORE Thread-Topic: [sipcore] draft-yusef-sipcore-sip-authn - WG item? Thread-Index: AQHSrwlSRAekgqslvkmWtXmwfbxlkaG42ZNwgAAAowA= Date: Thu, 6 Apr 2017 21:24:24 +0000 Message-ID: References: <01194ff4-c044-0861-6a30-3cc54fc0a455@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.48.100] 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-04-06_14:, , 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-1704060172 Archived-At: Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item? 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, 06 Apr 2017 21:25:00 -0000 +1 -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek Sent: Thursday, April 06, 2017 5:22 PM To: A. Jean Mahoney ; SIPCORE Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item? I support adoption of this draft. Kind regards Ivo -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean Mahone= y Sent: Thursday, April 06, 2017 12:09 PM To: SIPCORE Subject: [sipcore] draft-yusef-sipcore-sip-authn - WG item? Hi all, During the WG session in Chicago, Rifaat presented this draft, and the chai= rs took a hum on whether the WG should take on this draft as a WG item. There was consensus at the meeting to take this draft on. Now I'm gauging i= nterest on the mailing list. Please let the list know if you have any objec= tions to taking this work on. Thanks! Jean _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3Dck-1qeAMpbzYFf5UBvoFKj98k9MTJHJGX_DeD1jDwpg&s=3D4AZmdhGRJRfSJOY= ozSWuXz38Zbt9hM7HJlW7s3jSaak&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=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3Dck-1qeAMpbzYFf5UBvoFKj98k9MTJHJGX_DeD1jDwpg&s=3D4AZmdhGRJRfSJOY= ozSWuXz38Zbt9hM7HJlW7s3jSaak&e=3D=20 From nobody Fri Apr 7 03:34:34 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 761DE1243FE for ; Fri, 7 Apr 2017 03:34:32 -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 TVGxXuVEtk11 for ; Fri, 7 Apr 2017 03:34:29 -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 88B6C129416 for ; Fri, 7 Apr 2017 03:34:28 -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=I1tKOD9IEyfj37scbKksq/zlyAfcFGbr4N6dyELIJg0=; b=sgN9KjLC5AjMzozjHWe3u1b8SuuJs0b96TQx3DDa7Ofup4gXnFUJ4RHMKh+7TuQ1RwhgCnfIWnWRmIojVU3yqqx3BUyozUsiUNvZHQwhaKPb5AnsBAlf3j04TLVAiE1Dj9+XqovhoT7QKRCupw7Gtj25nSt9DMaGMnnJNalrUMQ= Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03lp0049.outbound.protection.outlook.com [216.32.180.49]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-159-Qjl1UDB2O0K3QHGU2YZEwA-1; Fri, 07 Apr 2017 06:34:23 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2351.namprd03.prod.outlook.com (10.166.210.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Fri, 7 Apr 2017 10:34:21 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1019.021; Fri, 7 Apr 2017 10:34:20 +0000 From: "Asveren, Tolga" To: SIPCORE Thread-Topic: [sipcore] draft-yusef-sipcore-sip-authn - WG item? Thread-Index: AQHSrwlEXVIhbJcvO0y3ZBInvVIv5KG42aEAgAAAnwCAANxuoA== Date: Fri, 7 Apr 2017 10:34:20 +0000 Message-ID: References: <01194ff4-c044-0861-6a30-3cc54fc0a455@nostrum.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-microsoft-exchange-diagnostics: 1; SN2PR03MB2351; 7:kyeJ4Ra5Os8VcSAsM0w7Zqd1/KlYwcFmvL2IOWX9cpAAScZ219bn9oga27rrSNuIsfDGzZ08qLsrcoFaDBucWBwN9IrD8SVcNdWI1+G/garUWkoTaN9KtylyNe977UdbIevcsNPDj/W6IIDsYVdOu1i5uzy1XiDABbm8UjXat10Ntnoyk20iLoLCHiS3+NnPUtYbfjffK+bwGPshW2ZXlGyxKcQ/iRIBHXyQchKAjDcEEldNKSAfLpBVrgy1GE32vfOpOCq35Ii0cbQHoL19yn02DR3z80OsmoXyp9WZiHAHIBVS5/KJDe8QnV5E18xBjAc5tK9h2GvAWbGsGM+H4g==; 20:MkYAV9Xt48TGQYQAB8SR+F768/MRY+zG8+MplbPchYQ/l21IEdh7TC4OVUOYln6RIOTlkzmNRGnZsL+t8huhrulGw7/MOjmNNGUQarSDIOsJIMiJ9uGns64SwXmQKQnoc/BqEkuslVgW4U7O7Rr3W3Cl3IqhYAOr58c3BKlx72w= x-ms-office365-filtering-correlation-id: 1ebf1f5b-726f-415d-52a0-08d47da1a6e1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN2PR03MB2351; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(10436049006162)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(6072148); SRVR:SN2PR03MB2351; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2351; x-forefront-prvs: 0270ED2845 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39400400002)(39830400002)(377454003)(53754006)(13464003)(6506006)(55016002)(9686003)(77096006)(53936002)(6436002)(99286003)(6306002)(2900100001)(102836003)(3846002)(33656002)(6116002)(6246003)(86362001)(3280700002)(2906002)(575784001)(3660700001)(7696004)(50986999)(8936002)(122556002)(5660300001)(66066001)(305945005)(74316002)(8676002)(81166006)(7736002)(38730400002)(76176999)(54356999)(6916009)(110136004)(2950100002)(25786009)(189998001)(229853002)(53546009)(230783001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2351; H:SN2PR03MB2350.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: 07 Apr 2017 10:34:20.5470 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2351 X-MC-Unique: Qjl1UDB2O0K3QHGU2YZEwA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item? 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, 07 Apr 2017 10:34:32 -0000 I also support adoption of this draft as a WG item and willing to review/co= ntribute. Thanks, Tolga -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN = C Sent: Thursday, April 6, 2017 5:24 PM To: Ivo Sedlacek ; A. Jean Mahoney ; SIPCORE Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item? +1 -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek Sent: Thursday, April 06, 2017 5:22 PM To: A. Jean Mahoney ; SIPCORE Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item? I support adoption of this draft. Kind regards Ivo -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean Mahone= y Sent: Thursday, April 06, 2017 12:09 PM To: SIPCORE Subject: [sipcore] draft-yusef-sipcore-sip-authn - WG item? Hi all, During the WG session in Chicago, Rifaat presented this draft, and the chai= rs took a hum on whether the WG should take on this draft as a WG item. There was consensus at the meeting to take this draft on. Now I'm gauging i= nterest on the mailing list. Please let the list know if you have any objec= tions to taking this work on. Thanks! Jean _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3Dck-1qeAMpbzYFf5UBvoFKj98k9MTJHJGX_DeD1jDwpg&s=3D4AZmdhGRJRfSJOY= ozSWuXz38Zbt9hM7HJlW7s3jSaak&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=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3Dck-1qeAMpbzYFf5UBvoFKj98k9MTJHJGX_DeD1jDwpg&s=3D4AZmdhGRJRfSJOY= ozSWuXz38Zbt9hM7HJlW7s3jSaak&e=3D=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Apr 7 08:15: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 05DB8127333 for ; Fri, 7 Apr 2017 08:15:52 -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 9UCL0L5Y8SdY for ; Fri, 7 Apr 2017 08:15:50 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (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 C73D3129415 for ; Fri, 7 Apr 2017 08:15:50 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-12v.sys.comcast.net with SMTP id wVblciRFWdlFQwVc6ci55n; Fri, 07 Apr 2017 15:15:50 +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 wVc4cs5RCngy3wVc5c19zt; Fri, 07 Apr 2017 15:15:49 +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 v37FFmcw025476; Fri, 7 Apr 2017 11:15:48 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v37FFlhi025473; Fri, 7 Apr 2017 11:15:47 -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: sipcore@ietf.org In-Reply-To: <6222bd21-f1b1-88a2-5afd-1c85825a9bac@nostrum.com> (mahoney@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 07 Apr 2017 11:15:47 -0400 Message-ID: <87o9w8dza4.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfMRFAHih2tL1mx0KIojle9x092a8Rmg3FiaUZ0elQmAXa/W/795itXLgki2qfPwdAo03k9KERNIbmL6dyOlFJBVq9zmfi0E8dpqklojE8i+2qL9H1qrE l1wPa2zE/svE6i6Mm3uHx156WNxyokqNHtG+m+TyT2tUNqRuH8S70TICezjMae6SU+pUi4yt9883+A== Archived-At: Subject: Re: [sipcore] draft-jesske-sipcore-reason-q850-loc - WG item? 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, 07 Apr 2017 15:15:52 -0000 "A. Jean Mahoney" writes: > There was consensus at the meeting to take this draft on. Now I'm > gauging interest on the mailing list. Please let the list know if you > have any objections to taking this work on. I favor taking this on, since it's useful to ETSI. Dale From nobody Fri Apr 7 14:18: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 97860128B91 for ; Fri, 7 Apr 2017 14:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mvvJ04Dg4rTX for ; Fri, 7 Apr 2017 14:18:12 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751B5129408 for ; Fri, 7 Apr 2017 14:17:57 -0700 (PDT) Received: from xct107cnc.rim.net ([10.65.161.207]) by mhs212cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Apr 2017 17:17:40 -0400 Received: from XCT115CNC.rim.net (10.65.161.215) by XCT107CNC.rim.net (10.65.161.207) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 7 Apr 2017 17:17:40 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT115CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Fri, 7 Apr 2017 17:17:39 -0400 From: Andrew Allen To: "Asveren, Tolga" , SIPCORE Thread-Topic: [sipcore] draft-yusef-sipcore-sip-authn - WG item? Thread-Index: AQHSrwk4h01fExV4z0m6XXqPfMmIQaG5HK8AgAAAoACAANy0AIAAcJaA Date: Fri, 7 Apr 2017 21:17:39 +0000 Message-ID: References: <01194ff4-c044-0861-6a30-3cc54fc0a455@nostrum.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item? 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, 07 Apr 2017 21:18:18 -0000 I indicated support in Chicago but also add it again here -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, Tolga Sent: Friday, April 7, 2017 6:34 AM To: SIPCORE Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item? I also support adoption of this draft as a WG item and willing to review/co= ntribute. Thanks, Tolga -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN = C Sent: Thursday, April 6, 2017 5:24 PM To: Ivo Sedlacek ; A. Jean Mahoney ; SIPCORE Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item? +1 -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek Sent: Thursday, April 06, 2017 5:22 PM To: A. Jean Mahoney ; SIPCORE Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item? I support adoption of this draft. Kind regards Ivo -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean Mahone= y Sent: Thursday, April 06, 2017 12:09 PM To: SIPCORE Subject: [sipcore] draft-yusef-sipcore-sip-authn - WG item? Hi all, During the WG session in Chicago, Rifaat presented this draft, and the chai= rs took a hum on whether the WG should take on this draft as a WG item. There was consensus at the meeting to take this draft on. Now I'm gauging i= nterest on the mailing list. Please let the list know if you have any objec= tions to taking this work on. Thanks! Jean _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3Dck-1qeAMpbzYFf5UBvoFKj98k9MTJHJGX_DeD1jDwpg&s=3D4AZmdhGRJRfSJOY= ozSWuXz38Zbt9hM7HJlW7s3jSaak&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=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= ItG0r2g&m=3Dck-1qeAMpbzYFf5UBvoFKj98k9MTJHJGX_DeD1jDwpg&s=3D4AZmdhGRJRfSJOY= ozSWuXz38Zbt9hM7HJlW7s3jSaak&e=3D=20 _______________________________________________ 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 Mon Apr 10 14:49: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 B5E91128708 for ; Mon, 10 Apr 2017 14:49:44 -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 H6IBQCLEs0KE for ; Mon, 10 Apr 2017 14:49:43 -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 9365F128B38 for ; Mon, 10 Apr 2017 14:49:43 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-04v.sys.comcast.net with SMTP id xhB9cWfMnscBPxhBucHl33; Mon, 10 Apr 2017 21:49:42 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-06v.sys.comcast.net with SMTP id xhBtchNjJeyvGxhBtccujS; Mon, 10 Apr 2017 21:49: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 v3ALne0m029781 for ; Mon, 10 Apr 2017 17:49:40 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v3ALnebJ029778; Mon, 10 Apr 2017 17:49:40 -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: Mon, 10 Apr 2017 17:49:40 -0400 Message-ID: <87shlgndaj.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfKHDw7N0bFOSMMTe8exSEMkxCFuiZFVeLPiGYff2VsJ/Ma4seC7vfja4H0k2zQZ38gincpq5D3IeRQdFuMjnZg0PoBLqyQhojmbxjur2TjOgejGKv+nF 9gOW5hsMDzmclJtGV7FDhIiLRjouceCL56ISSYZ+q00Bay66rItjwCHh Archived-At: Subject: [sipcore] Comments on 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: Mon, 10 Apr 2017 21:49:45 -0000 The short title is "Content-ID-in-SIP", whereas it seems more natural to use "Content-ID in SIP". Table of Contents 1.1. Setting up ID value uniquely identifying body . . . . . . 2 1.2. Referencing the ID value uniquely identifying body . . . 3 This seems an awkward way of phrasing it. In particular, there seems to be no reason to emphasize uniqueness here. Perhaps 1.1. Establishing a Content-ID identifying the body 1.2. Referencing the Content-ID value identifying the body -- 5.1. Header Field . . . . . . . . . . . . . . . . . . . . . . 6 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 These items capitalize later words, whereas the other items capitalize only initial words. It seems that the current RFC style heavily favors capitalizing all the "important" words in section titles. 1. Introduction A message-body of the SIP message can contain one body only or can contain several body parts, as specified in [RFC3261] and [RFC5621]. Strictly speaking, a SIP message containing several body parts also has a body (whose MIME type is multipart/something). I think it would be better to phrase this A message-body of the SIP message can be a non-multipart body or can be a multipart body that contains several body parts, as specified in [RFC3261] and [RFC5621]. I think this can be carried through to other places that use the phrase "one body". (Although "one body" is a close version of the phrase "unitary body", which would be a good term for "non-multipart body", though nobody uses the phrase!) 1.5. Solution Section 1.5 looks much like section 3.3, and I think the duplication should be reduced. Perhaps the text in 1.5 could be reduced to The Content-ID header field included in header fields of a SIP message identifies a body part consisting of the message-body of the SIP message. The metadata provided by some additional header fields also applies to the message body as a whole. 3.2. Syntax The ABNF for the Content-ID header fields is: Content-ID = "Content-ID" HCOLON msg-id NOTE: msg-id is specified in [RFC5322]. Comparing with RFC 5322, I see: msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] CFWS = (1*([FWS] comment) [FWS]) / FWS comment = "(" *([FWS] ccontent) [FWS] ")" I'm sure we don't want to allow comments! I can see a couple of ways to avoid this. One is to annotate it: The ABNF for the Content-ID header fields is: Content-ID = "Content-ID" HCOLON msg-id NOTE: msg-id is specified in [RFC5322], but may not contain "comment". But this allows RFC 5322's FWS, which is slightly broader than RFC 3261's SWS. Probably best is to force the whitespace to be in the style of RFC 3261: The ABNF for the Content-ID header fields is: Content-ID = "Content-ID" HCOLON msg-id msg-id = "<" id-left "@" id-right ">" NOTE: id-left and id-right are specified in [RFC5322]. Note that SIP header fields generally do not allow trailing whitespace. 3.3. Semantic I think you want "Semantics" as the section title. I notice this item in the list (which is duplicated in section 1.5): o a Content-ID header field, if included in the header fields of the SIP message; This reads awkwardly, because the beginning of the paragraph has specified that there is a Content-ID header field in the message. I think this could be clarified by promoting this item to the top of the list and explicitly labeling it all as metadata: The Content-ID header field included in header fields of a SIP message identifies a body part consisting of the message-body of the SIP message and the following metadata: o the Content-ID header field itself; and then continuing with "a MIME-Version header field", etc. Dale From nobody Tue Apr 11 03:09: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 1768C120727 for ; Tue, 11 Apr 2017 03:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.998 X-Spam-Level: X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 ZEpGap1bGZCp for ; Tue, 11 Apr 2017 03:09:01 -0700 (PDT) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.111]) by ietfa.amsl.com (Postfix) with ESMTP id DEA23126E01 for ; Tue, 11 Apr 2017 03:09:00 -0700 (PDT) Received: from [193.109.254.3] by server-7.bemta-6.messagelabs.com id 58/C4-04817-B3BACE85; Tue, 11 Apr 2017 10:08:59 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleJIrShJLcpLzFFi42LR98zp1LVe/Sb C4N5lTYuGzpWsFl9/bGJzYPJYsuQnk8esnU9YApiiWDPzkvIrElgz+iY2sxR0sVd8XPCEsYHx P2sXIxeHkMB2RonJZ75BOYcZJc72XmKDcDYzSsy88Y+5i5GDg03AXmLGnpguRk4OEQF3id/NN xlBbGEBN4lPu6+zw8R3P7rJAmEbSWzYOpMZxGYRUJU4uG4rK4jNKxAqMWtuF1i9kICdxOKeFW D1nEDjf7a3g9UzCshKfGlcDWYzC4hL3HoynwnElhAQkFiy5zwzhC0q8fLxP1aIGh2JBbs/sUH Y2hLLFr5mhtglKHFy5hMWiF2qEv9WLmKawCgyC8nYWUjaZyFpn4WkfQEjyypGjeLUorLUIl1D E72kosz0jJLcxMwcXUMDM73c1OLixPTUnMSkYr3k/NxNjMBoYQCCHYzXNwYcYpTkYFIS5Q2Y+ TpCiC8pP6UyI7E4I76oNCe1+BCjDAeHkgRv1qo3EUKCRanpqRVpmTnAuIVJS3DwKInwWoKkeY sLEnOLM9MhUqcYdTnm3Pv6nkmIJS8/L1VKnNcEpEgApCijNA9uBCyFXGKUlRLmZQQ6SoinILU oN7MEVf4VozgHo5IwbwbIFJ7MvBK4Ta+AjmACOuLMrpcgR5QkIqSkGhjrVeM7otUb8qLOCWYb FLrVKbyYdXnGk4S8xFdBC5cXvDoU9Inf2q6KuVFSpvZF1qU2/iBDFt/5l6WerrvPuHVhQWDwv oVn49Z9aFgi6bbn6VbbY2Ear7/uTzxW82zejmn7Z70olVu/JOz5a72NGybM8TvDHC1S9N+h/v A0d94Ztm9iz8nPPHNKiaU4I9FQi7moOBEA1x0ryhwDAAA= X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-15.tower-184.messagelabs.com!1491905337!109702551!8 X-Originating-IP: [47.73.108.137] X-StarScan-Received: X-StarScan-Version: 9.2.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9909 invoked from network); 11 Apr 2017 10:08:59 -0000 Received: from vgdpm11vr.vodafone.com (HELO voxe04hw.internal.vodafone.com) (47.73.108.137) by server-15.tower-184.messagelabs.com with SMTP; 11 Apr 2017 10:08:59 -0000 Received: from VOEXH10W.internal.vodafone.com (47.73.211.214) by edge1.vodafone.com (195.232.244.49) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 11 Apr 2017 12:08:47 +0200 Received: from VOEXC02W.internal.vodafone.com (145.230.101.22) by VOEXH10W.internal.vodafone.com (47.73.211.214) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 11 Apr 2017 12:08:46 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.159]) by VOEXC02W.internal.vodafone.com ([145.230.101.22]) with mapi id 14.03.0294.000; Tue, 11 Apr 2017 12:08:46 +0200 From: "Dawes, Peter, Vodafone Group" To: "A. Jean Mahoney" , SIPCORE Thread-Topic: [sipcore] draft-jesske-sipcore-reason-q850-loc - WG item? Thread-Index: AQHSrwlBDJuSZQ9dzE2aEmbSb5U166G/+MPg Date: Tue, 11 Apr 2017 10:08:45 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E1531A58@VOEXM31W.internal.vodafone.com> References: <6222bd21-f1b1-88a2-5afd-1c85825a9bac@nostrum.com> In-Reply-To: <6222bd21-f1b1-88a2-5afd-1c85825a9bac@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] draft-jesske-sipcore-reason-q850-loc - WG item? 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, 11 Apr 2017 10:09:03 -0000 I support adopting the draft and made some review comments in https://maila= rchive.ietf.org/arch/msg/sipcore/0fr61CQjGnuCQwrtvFEH1sqzkBc -Peter > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean > Mahoney > Sent: 06 April 2017 20:09 > To: SIPCORE > Subject: [sipcore] draft-jesske-sipcore-reason-q850-loc - WG item? >=20 > Hi all, >=20 > During the WG session in Chicago, Roland presented this draft, and the ch= airs > took a hum on whether the WG should take on this draft as a WG item. >=20 > There was consensus at the meeting to take this draft on. Now I'm gauging > interest on the mailing list. Please let the list know if you have any ob= jections > to taking this work on. >=20 > Thanks! >=20 > Jean >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Apr 13 07:47:34 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 33655129AB3 for ; Thu, 13 Apr 2017 07:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.019 X-Spam-Level: X-Spam-Status: No, score=0.019 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 YrADfQEz83GB for ; Thu, 13 Apr 2017 07:47:11 -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 A9F231298A1 for ; Thu, 13 Apr 2017 07:47:11 -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 v3DEl9a0082857 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 13 Apr 2017 09:47:11 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be mutabilis-2.local From: "A. Jean Mahoney" To: SIPCORE References: Message-ID: <1a1e7560-1176-a584-c164-ef5f89c14dde@nostrum.com> Date: Thu, 13 Apr 2017 09:47:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [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, 13 Apr 2017 14:47:13 -0000 Just a reminder that WGLC closes today. Thanks! Jean On 3/23/17 12:29 PM, A. Jean Mahoney wrote: > 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 > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Apr 13 07:49: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 DFBBE1205D3 for ; Thu, 13 Apr 2017 07:49:44 -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 oSUpeOuqVZ7P for ; Thu, 13 Apr 2017 07:49:43 -0700 (PDT) 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 266571289B0 for ; Thu, 13 Apr 2017 07:49:41 -0700 (PDT) X-AuditID: c1b4fb30-ea83298000006667-17-58ef9004e434 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id F6.31.26215.4009FE85; Thu, 13 Apr 2017 16:49:40 +0200 (CEST) Received: from ESESSMB102.ericsson.se ([169.254.2.218]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0339.000; Thu, 13 Apr 2017 16:49:38 +0200 From: Christer Holmberg To: "A. Jean Mahoney" , SIPCORE Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-content-id-01 Thread-Index: AQHSo/sfi1NxsQu/8UGWpUH0dB3/xqHDYCsAgAA0JQA= Date: Thu, 13 Apr 2017 14:50:13 +0000 Message-ID: References: <1a1e7560-1176-a584-c164-ef5f89c14dde@nostrum.com> In-Reply-To: <1a1e7560-1176-a584-c164-ef5f89c14dde@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0B36338C64CF6045BBFD714ACC43D530@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2J7lC7LhPcRBpsXKVk0dK5ktfj6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJVxZ/kzxoJm9oozb++yNTC+YO1i5OSQEDCR OL9rMXMXIxeHkMB6Rol/p1sZIZwljBKX590Gcjg42AQsJLr/aYM0iAi4S/xuvskIYgsL2Ers urycGSJuJ9H+cxGUbSXRuf8zO4jNIqAqsWXbTRYQm1fAWuLn07lgvUICxRILdu0FszkF7CWa n0H0MgqISXw/tYYJxGYWEJe49WQ+E8ShAhJL9pxnhrBFJV4+/gf2gKiAnsS+f1/ZIOKKEu1P GxghevUkbkydwgZhW0t07FjBCmFrSyxb+JoZ4h5BiZMzn7BMYBSbhWTdLCTts5C0z0LSPgtJ +wJG1lWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgXF1cMtvgx2ML587HmIU4GBU4uFNaHkf IcSaWFZcmXuIUYKDWUmEd1obUIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv474LEUIC6Yklqdmp qQWpRTBZJg5OqQZGn3u371pl/JAqFTHWi5fIVLzzWlrb5F2ddXnYekvXV9sjCw6Kznm9am55 7JPEHc+Kt57ziVi6bVXP0/aut2GNWzVPsz3Ykn3gtaNGv2FUncnqw/FrrpxccsS18rCv5Mk9 idtcb7px/CgOueFh+HqawyWfzWYbZ5xpPrpeISpUPEaovOmS8odqJZbijERDLeai4kQAtB5l hqcCAAA= Archived-At: Subject: Re: [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, 13 Apr 2017 14:49:45 -0000 Hi, Me an Ivo have been looking at the comments provided by Dale. We=B9ll get back after Easter. Regards, Christer On 13/04/17 17:47, "sipcore on behalf of A. Jean Mahoney" wrote: >Just a reminder that WGLC closes today. > >Thanks! > >Jean > >On 3/23/17 12:29 PM, A. Jean Mahoney wrote: >> Hi all, >>=20 >> 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. >>=20 >> Thanks! >>=20 >> Jean >>=20 >> _______________________________________________ >> 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 Thu Apr 13 14:43:28 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 8447112EAA4 for ; Thu, 13 Apr 2017 14:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 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, 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 xlbDrXvPLPCj for ; Thu, 13 Apr 2017 14:43:25 -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 26303120227 for ; Thu, 13 Apr 2017 14:43:25 -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 v3DLhNN1029336 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 13 Apr 2017 16:43:23 -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: <87mvc3iym3.fsf@hobgoblin.ariadne.com> From: Robert Sparks Message-ID: <6c99cbac-212e-dbc0-5328-57222e8547b7@nostrum.com> Date: Thu, 13 Apr 2017 16:43:23 -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: Content-Type: multipart/alternative; boundary="------------F7BC6CF4FBDA5DEB5282BBF2" 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, 13 Apr 2017 21:43:27 -0000 This is a multi-part message in MIME format. --------------F7BC6CF4FBDA5DEB5282BBF2 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Yehoshua - On 3/30/17 5:57 AM, Yehoshua Gev wrote: > 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". 3261 does already say this. and there's no ambiguity to clear up - we'd be restating it here, and restating things that are required by a base specification is something we avoid. > > Thanks, > Yehoshua > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --------------F7BC6CF4FBDA5DEB5282BBF2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Yehoshua -


On 3/30/17 5:57 AM, Yehoshua Gev wrote:
On Thu, Mar 30, 2017 at 12:04 AM, Dale R. Worley <worley@ariadne.com> wrote:
Yehoshua Gev <yoshigev@gmail.com> 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".
3261 does already say this. and there's no ambiguity to clear up - we'd be restating it here, and restating things that are required by a base specification is something we avoid.

Thanks,
Yehoshua



_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--------------F7BC6CF4FBDA5DEB5282BBF2-- From nobody Tue Apr 18 00:42: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 323751317DC for ; Tue, 18 Apr 2017 00:42:29 -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 igG--g6O4Go4 for ; Tue, 18 Apr 2017 00:42: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 42D501317D4 for ; Tue, 18 Apr 2017 00:42:26 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id d131so123152985qkc.3 for ; Tue, 18 Apr 2017 00:42: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=36ghL6m5GdsA0eTlNdYsslLXX3e3nVJNwy8XrVABwDk=; b=Ut+LnLixe4RR//nY07AIYIALPY3n+Hq+c1yB/XKT3/IJEtB3gCfALuLJ5l78FVTQ0P ihbz34ZJ9gL5O/oCsK5LNJvcaPVjKt+8YnpIfCUyaW+tH4q2JC6xUTAAP79/ByheWJp5 ofXruC808AdTRBbmjzKODwcpR9rpCTSSb+ie/m5VGrMKsxRqtNgyf8Nygi7gBTvDHw+0 OlssCfk7v8gOHG41SgypnEE2sJI8CEmoYfPkkIFNnErGTBevPd0w9LjsdnnmNU8gTHYb J8cauhMfV3W6ccGjQkduGeQTPCECJ/htt1aP+kkU0W74eDlIj3rZNgC9Ctu1tI9ZWH3k xsAw== 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=36ghL6m5GdsA0eTlNdYsslLXX3e3nVJNwy8XrVABwDk=; b=RfEsP5fxD62n6hOk4BrwRWtOXn8jt8pIuAfJL8yE2hF2xa2LHJhT+Fu8Qhjidq1Ixj EIS3Q5LLWk3gjHNqkFuXe5W63EJ52oqqu2DKlvfqu3AzL/QH1DpNUgzruJq0dlilj9md S4zC74ydFH82gqUY+MpPv2TammLbE/W0t4CmheSK/N7zIhsk/g2CzE2jzts/xeAP7JI7 8MpkbXl3I2Ei2Wjxfwq9A0OIpkrRYJRBZkfWT92XLd4ggoVpxKN+0JMrtSTVnaFPbAZ8 XRSmUvcGWlud+MxuNuMpxHKYzj16/jeU/DyEIkFyGKsn8InVDZckGbVfYdGLFBMHRCnl LTsQ== X-Gm-Message-State: AN3rC/7FtVl4mJVYRdGV6qq4E16dPw4f1xqxs4EH+d4A33uGKncnMyED LTbFMJyOX9xjQHeIUUOU2QS49M2Ae3NwQr8= X-Received: by 10.55.107.132 with SMTP id g126mr11784850qkc.112.1492501345456; Tue, 18 Apr 2017 00:42:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.154.130 with HTTP; Tue, 18 Apr 2017 00:42:25 -0700 (PDT) In-Reply-To: <6c99cbac-212e-dbc0-5328-57222e8547b7@nostrum.com> References: <87mvc3iym3.fsf@hobgoblin.ariadne.com> <6c99cbac-212e-dbc0-5328-57222e8547b7@nostrum.com> From: Yehoshua Gev Date: Tue, 18 Apr 2017 10:42:25 +0300 Message-ID: To: Robert Sparks Cc: sipcore Content-Type: multipart/alternative; boundary=001a11487acc85d827054d6c0ca4 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: Tue, 18 Apr 2017 07:42:29 -0000 --001a11487acc85d827054d6c0ca4 Content-Type: text/plain; charset=UTF-8 Hi Robert, Can you point me to the text on 3261 that has the disambiguation rule? I could only find it in the last paragraph of section 20, which only speaks about "Contact, From, and To". I believe the intention of this draft is to expand this paragraph to cover all other "problematic" headers, so it should also expand the disambiguation rule to the other headers. Thanks, Yehoshua On Fri, Apr 14, 2017 at 12:43 AM, Robert Sparks wrote: > Hi Yehoshua - > > On 3/30/17 5:57 AM, Yehoshua Gev wrote: > > 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". > > 3261 does already say this. and there's no ambiguity to clear up - we'd be > restating it here, and restating things that are required by a base > specification is something we avoid. > > > Thanks, > Yehoshua > > > > _______________________________________________ > sipcore mailing listsipcore@ietf.orghttps://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --001a11487acc85d827054d6c0ca4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Robert,

Can you point me to the tex= t on 3261 that has the disambiguation rule?
I could only find it in the last paragraph of section 20, which only speak= s about "Contact,= From, and To".
I believe the intention of this draft= is to expand this paragraph to cover all other "problematic" hea= ders,
so it should also expand the disambiguation rule to = the other headers.

Thanks,
Yehoshua
<= div class=3D"gmail_quote">


On Fri, Apr 1= 4, 2017 at 12:43 AM, Robert Sparks <rjsparks@nostrum.com>= wrote:
=20 =20 =20

Hi Yehoshua -


On 3/30/17 5= :57 AM, Yehoshua Gev wrote:
On Thu, Mar 30, 2017 at 12:04 AM, Dale R. Worley <worley@ariadne.com> wrote:
Yehoshua Gev <yoshigev@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?Repl= aces=3D1111

>= ; 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=3D1111" can be parsed as an addr-spec, so the
header is valid (by the BNF alone).=C2=A0 (Actually, even "sip:123@host"
can't be parsed as a name-addr, because it doesn't ha= ve "<...>".)

Ok. I see your point.
So when parsing header like =C2=A0"Refer-To: = sip:123@host;user=3Dphone",
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 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.

=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 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=C2=A0brackets= ,
any semicolon-delimited parameters are header-parameters,=C2=A0not URI
parameters" (from=C2= =A0RFC=C2=A03261 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".
3261 does already say this. and there's no ambiguity to clear up - we'd be restating it here, and restating things that are required b= y a base specification is something we avoid.

Thanks,
Yehoshua


= 

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ie=
tf.org/mailman/listinfo/sipcore


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

--001a11487acc85d827054d6c0ca4-- From nobody Wed Apr 19 08:59:08 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 EF8C8129B04 for ; Wed, 19 Apr 2017 08:59:06 -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 h9hqYxPHl1yA for ; Wed, 19 Apr 2017 08:59:04 -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 AF1D2129577 for ; Wed, 19 Apr 2017 08:59:04 -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 v3JFx2OR029500 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 19 Apr 2017 10:59:03 -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@ietf.org References: <7594FB04B1934943A5C02806D1A2204B4CB4C731@ESESSMB109.ericsson.se> <0ab1c9cd-58f3-3b41-d286-f3865f54cec0@nostrum.com> From: "A. Jean Mahoney" Message-ID: Date: Wed, 19 Apr 2017 10:59:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <0ab1c9cd-58f3-3b41-d286-f3865f54cec0@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] IETF#98: SIPCORE notes (Christer) 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, 19 Apr 2017 15:59:07 -0000 Since there have been no comments, I'll be uploading these notes as the minutes. Thanks again, Christer! Jean On 4/5/17 3:12 PM, A. Jean Mahoney wrote: > Thank you for the notes, Christer! > > Session participants, please review and send any corrections to the list. > > Jean > > > On 4/5/17 2:05 PM, Christer Holmberg wrote: >> Hi, >> >> Below are my notes from the SIPCORE session. >> >> Regards, >> >> Christer >> >> --------------------------------------------------------------------------- >> >> >> *Topic: SIP Call-Info Parameters for Labeling Calls* >> >> *Presenter: Henning Schulzrinne* >> >> *Draft: draft-ietf-sipcore-callinfo-spam-00* >> >> What is it? >> >> -Defines 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. >> >> Presentation in a nutshell? >> >> -Generic presentation about robocalls. >> >> -Some are illegal, some are legal but unwanted, and some are >> wanted/helpful. >> >> -Call filtering can be done by carriers themselves, by carriers using >> third-party tools, or by a device itself. >> >> -Presentation of new SIP Call-Info header field parameters and an >> associated feature capability indicator. >> >> What did people say? >> >> -It was asked whether it would be better to insert the information in >> the STIR PASSPortT structure instead. Indicated that it could be part >> of PASSPorT in the future. >> >> Ok, so what next? >> >> -Additional comments are welcome. >> >> -ACTION POINT: Christer H and Paul K will review the feature >> capability indicator. >> >> ------------ >> >> *Topic: Location Source Parameter for the SIP >> Geolocation Header Field* >> >> *Presenter: Roland Jesske* >> >> *Draft: draft-winterbottom-sipcore-locparam-00* >> >> What is it? >> >> -Adds parameter to the Geolocation header field values to indicate the >> node that added the value. >> >> Presentation in a nutshell? >> >> -Indicated that the feature is required by ETSI M/493 in order to >> assist downstream nodes. >> >> -Proposed to adopt the draft by the SIPCORE WG and initiate WGLC. >> >> What did people say? >> >> -Some had issues with the use of domain name to indicate nodes. >> >> -The chairs asked people to review the draft. >> >> Ok, so what next? >> >> -The discussion will continue on the mailing list. >> >> *Topic: Third-Party Authentication for Session >> Initiation Protocol (SIP)* >> >> *Presenter: Rifaat Shekh-Yusef* >> >> *Draft: draft-yusef-sipcore-sip-authn-01* >> >> What is it? >> >> -Authentication mechanism for SIP, that is based on the OAuth 2.0 and >> OpenID Connect Core 1.0 specifications. >> >> Presentation in a nutshell? >> >> -Difference between the draft and a previous draft. The new draft is a >> scaled down version, where previously controversial parts have been >> removed. >> >> What did people say? >> >> -Jon Peterson, who raised issues on the previous draft, indicated that >> he has some minor issues, but that he is ok with the scope of the >> draft and moving it forward. >> >> Ok, so what next? >> >> -The chairs did a hum regarding taking on the work. >> >> -OUTCOME: There was a clear consensus for taking on the work. >> >> *Topic: ISUP Cause Location Parameter for the SIP >> Reason Header Field* >> >> *Presenter: Roland Jesske* >> >> *Draft: draft-jesske-sipcore-reason-q850-loc-00* >> >> -The draft had previously been discussed in DISPATCH (see notes for >> more information), where it was decided to move the draft to the >> SIPCORE WG and let SIPCORE decided on whether take on the work. >> >> Ok, so what next? >> >> -The chairs did a hum regarding taking on the work. >> >> -OUTCOME: There was a clear consensus for taking on the work. >> >> *Topic: The Session Initiation Protocol (SIP) Digest >> Authentication Scheme* >> >> *Presenter: Rifaat Shekh-Yusef* >> >> *Draft: draft-yusef-sipcore-digest-scheme-05* >> >> What is it? >> >> -Updates the Digest Access Authentication scheme used by the Session >> Initiation Protocol (SIP) to add support for SHA2 digest algorithms to >> replace the MD5 algorithm >> >> Presentation in a nutshell? >> >> -Background what has happened for HTTP, and to apply the same for SIP. >> >> -Indicated that forking could potentially cause problems, if multiple >> servers are to be authenticated by the client. >> >> What did people say? >> >> -It was questioned whether there is a need for a UA to authenticate >> multiple servers. It was indicated that it would be problematic with >> current behaviour of forking proxies. Nobody could identity a case >> where it would be needed. >> >> -Indicated that similar algorithm update is also done for STUN, so the >> author was advised to take a look at the STUNbis draft. >> >> Ok, so what next? >> >> -No decision was made. Discussions will continue on the list. >> >> >> >> _______________________________________________ >> 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 Thu Apr 20 05:35:06 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 44D4C1294E6 for ; Thu, 20 Apr 2017 05:35: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, 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] 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 kffi_hW4hBIl for ; Thu, 20 Apr 2017 05:34:55 -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 1C6AA129506 for ; Thu, 20 Apr 2017 05:34:54 -0700 (PDT) X-AuditID: c1b4fb25-c27a798000006af2-9e-58f8aaecbfd8 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 05.2E.27378.CEAA8F85; Thu, 20 Apr 2017 14:34:53 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.339.0; Thu, 20 Apr 2017 14:34:50 +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=eeVedoJwM8S2ozxSDCmn/VaIJi2UtIRp8t2ULhfjajI=; b=e+lNYGYMXLdKlgfL5Uzsy0XdmQx9p5+Cd9BpI08/9a1XTL1gA1kbfgnIYOAro3LnfJA9Tsc2tUyyzejW/v5Pxh7nuorjtrmLV/pcatKnNG7iuZ5uPErfDdQdCLBaVKscSKaQJBjB/FEYNxkRofC2TOV8fjz521n666c/mH3Weus= Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) by AM5PR0701MB2466.eurprd07.prod.outlook.com (10.169.153.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Thu, 20 Apr 2017 12:34:49 +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.1047.008; Thu, 20 Apr 2017 12:34:49 +0000 From: Ivo Sedlacek To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-content-id-01 Thread-Index: AQHSskRz2SRrl2rmbEy4SIhztfbLoqHOPt7w Date: Thu, 20 Apr 2017 12:34:49 +0000 Message-ID: References: <87shlgndaj.fsf@hobgoblin.ariadne.com> In-Reply-To: <87shlgndaj.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ariadne.com; dkim=none (message not signed) header.d=none;ariadne.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [193.179.210.162] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2466; 7:xBfumkEdto6dKblF7KU/nzJREaa0/QqY8cB+ZkomVnEdDfCavA09k0W8ecQAx38czTu1mSjNYQhluNyW30OxjEszwJ2X38eg1b1sH1dFUP36206XjipjMFm4hd5JEE84vhBU8O0sMEhuU8sboiAQL6ahq/LjJQ/6fJlI/WUrtV43N8dnpUct0wwY4O+I45+bbHb7K7opB+VyAPUvnEsZXl2zzJDPPcMsTi5npouEQO0RpxSQaREDMDWldmMKbhbjL5I2KkQTXlyIrcWEOJZfN0uP1eji6Qi3cnwDwW/KUjcODHp/S9wnTe9wSTbeaMFuTRIt54vGamwR//OC5jDXeQ== x-ms-office365-filtering-correlation-id: e648fc6c-0dd6-4184-d726-08d487e9a2e4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2466; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:AM5PR0701MB2466; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2466; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39450400003)(39860400002)(39410400002)(39400400002)(39840400002)(15374003)(2501003)(50986999)(6506006)(6436002)(74316002)(230783001)(102836003)(790700001)(99286003)(6116002)(33656002)(55016002)(3846002)(3660700001)(76176999)(54356999)(2906002)(3280700002)(7696004)(189998001)(229853002)(86362001)(2950100002)(66066001)(77096006)(7736002)(122556002)(53936002)(2900100001)(6246003)(38730400002)(25786009)(8676002)(5660300001)(9686003)(345774005)(8936002)(6306002)(81166006)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2466; H:AM5PR0701MB2468.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB24689635B3D926F7B223C830E51B0AM5PR0701MB2468_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 12:34:49.4046 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2466 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec/Z2Y6jydu8PakFLWylubz0QawsscI+ZLcvIzQ9tYNabpMd 81KREyrU7KJ2c4JNWqMkLNawwtsUb4VUZH5Ry/BCiYlimLcceXwT/PZ7fs//fXmel5ellXbG n003ZPEmA5ehksolFdrXCaETNXPasLvtsqiZOYc0aqwrez8VX948Q8fbbPPUMeqUfI+Oz0jP 5k07Y1Lkaa4aM8qc/IZyn038RWY034SKkQcLeBf0d/xYZjmrxC8QzLYUMqToQtDQUy0VCwm+ SUPb6LxEPKLElRR0vc0h3I1gYUojshRroNTZxojsjU+Ao+gpXYxY1gvHQV17DtEHoKrZ+T8S AaMFdZQYkeAgeDWjFrUCp0B/wSJDbo8Aq/2DRIx44Eiocm8QNcK+MPv+OSUyjf2gb+QRRXbB YGv4SBP2gbFhN0PypQj6CsKI3wLOskla3ArwLRrmm68ypHEEXg4MSknDjKDJ5loZH7AR2r/r SSYaCks7GZLppWCpY4whmUBosxwk/jED1gdTMvGAF/aHr1+KEOFA+DnQyJCpjTDy2y67g9SW NUtY1rQsK2+xHt5VjEiI3wHW+mkp4RCwV4/Tq9ztGqbWeiuS1SAfgRfO6FMjIjW8Kf2sIBgN GgOf5UDLv6fFuRj0BvX8im1FmEWqdYoU/axWyXDZQp6+FQFLq7wVh9KXlULH5V3kTcZk04UM XmhFAaxE5aeIbfqkVeJULos/z/OZvGm1S7Ee/maUIN+ubDrn4k56HS2arlnyvBEcvbEyyDPh 3nRMd0x9sm6fZXwwoHZcyLfHUa0hC/cvuxccSQETno7qRC5sG5PYfXxzbUk4C71xVZ1mX98r iUORobvnhvWK6w8b1akpp3MvTQ/13T68tW7QvjdfVp6kfnLN4S4rYTXeuj/Qv+mzSiKkceHB tEng/gGvGFFXOQMAAA== Archived-At: Subject: Re: [sipcore] Comments on 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, 20 Apr 2017 12:35:03 -0000 --_000_AM5PR0701MB24689635B3D926F7B223C830E51B0AM5PR0701MB2468_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, first of all, thank you for the review. > The short title is "Content-ID-in-SIP", whereas it seems more natural to = use > "Content-ID in SIP". Applied as suggested. > Table of Contents > > 1.1. Setting up ID value uniquely identifying body . . . . . . 2 > 1.2. Referencing the ID value uniquely identifying body . . . 3 > > This seems an awkward way of phrasing it. In particular, there seems to = be > no reason to emphasize uniqueness here. Perhaps > > 1.1. Establishing a Content-ID identifying the body > 1.2. Referencing the Content-ID value identifying the body I agree it is awkward. I made it even shorter to: ----------------- 1.1. Identifying a body part . . . . . . . . . . . . . . . . . 2 1.2. Referencing a body part . . . . . . . . . . . . . . . . . 3 ----------------- > 5.1. Header Field . . . . . . . . . . . . . . . . . . . . . . 6 > 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 > > These items capitalize later words, whereas the other items capitalize on= ly > initial words. It seems that the current RFC style heavily favors > capitalizing all the "important" words in section titles. I guess RFC editor will anyway decide whether to capitalize all words of se= ction titles or just the first one. I have slight preference for the latter= style. No strong view. > 1. Introduction > > A message-body of the SIP message can contain one body only or can > contain several body parts, as specified in [RFC3261] and [RFC5621]. > > Strictly speaking, a SIP message containing several body parts also has a > body (whose MIME type is multipart/something). I think it would be bette= r to > phrase this > > A message-body of the SIP message can be a non-multipart body or > can be a multipart body that contains several body parts, as > specified in [RFC3261] and [RFC5621]. > > I think this can be carried through to other places that use the phrase "= one > body". (Although "one body" is a close version of the phrase "unitary bo= dy", > which would be a good term for "non-multipart body", though nobody uses t= he phrase!) OK to refer to "multipart body" and "non-multipart body". However: 1) in some places, this forces split of the sentence to two sentences. 2) in other places, I rather talk about "content" where the "content" can b= e carried in (a) a body part of multipart body, or (b) in non-multipart bod= y. > 1.5. Solution > > Section 1.5 looks much like section 3.3, and I think the duplication shou= ld > be reduced. Perhaps the text in 1.5 could be reduced to > > The Content-ID header field included in header fields of a SIP > message identifies a body part consisting of the message-body of > the SIP message. The metadata provided by some additional header > fields also applies to the message body as a whole. OK to simplify. I made it even shorter to: ----------------- The Content-ID header field included in the header fields of a SIP message identifies a body part consisting of the message-body of a SIP message and metadata provided by some additional SIP header fields. ----------------- > 3.2. Syntax > > The ABNF for the Content-ID header fields is: > > Content-ID =3D "Content-ID" HCOLON msg-id > > NOTE: msg-id is specified in [RFC5322]. > > Comparing with RFC 5322, I see: > > msg-id =3D [CFWS] "<" id-left "@" id-right ">" [CFWS] > > CFWS =3D (1*([FWS] comment) [FWS]) / FWS > > comment =3D "(" *([FWS] ccontent) [FWS] ")" > > I'm sure we don't want to allow comments! > > I can see a couple of ways to avoid this. One is to annotate it: > > The ABNF for the Content-ID header fields is: > > Content-ID =3D "Content-ID" HCOLON msg-id > > NOTE: msg-id is specified in [RFC5322], but may not contain > "comment". > > But this allows RFC 5322's FWS, which is slightly broader than RFC 3261's > SWS. Probably best is to force the whitespace to be in the style of RFC = 3261: > > The ABNF for the Content-ID header fields is: > > Content-ID =3D "Content-ID" HCOLON msg-id > > msg-id =3D "<" id-left "@" id-right ">" > > NOTE: id-left and id-right are specified in [RFC5322]. > > Note that SIP header fields generally do not allow trailing whitespace. Applied as suggested. > 3.3. Semantic > > I think you want "Semantics" as the section title. > > I notice this item in the list (which is duplicated in section 1.5): > > o a Content-ID header field, if included in the header fields of the > SIP message; > > This reads awkwardly, because the beginning of the paragraph has specifie= d > that there is a Content-ID header field in the message. I think this cou= ld > be clarified by promoting this item to the top of the list and explicitly > labeling it all as metadata: > > The Content-ID header field included in header fields of a SIP > message identifies a body part consisting of the message-body of > the SIP message and the following metadata: > > o the Content-ID header field itself; > > and then continuing with "a MIME-Version header field", etc. Good idea. Minor tweak - I would prefer to state: ----------------- The Content-ID header field included in the header fields of a SIP message identifies a body part consisting of the message-body of the SIP message, and >>the metadata provided by<<: o the Content-ID header field itself; o a MIME-Version header field, if included in the header fields of the SIP message; .... ----------------- Kind regards Ivo --_000_AM5PR0701MB24689635B3D926F7B223C830E51B0AM5PR0701MB2468_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

first of all, thank you for = the review.

 

> The short title is &quo= t;Content-ID-in-SIP", whereas it seems more natural to use<= /span>

> "Content-ID in SIP= ".

 

Applied as suggested.

 

> Table of Contents<= /o:p>

> =

>    =   1.1.  Setting up ID value uniquely identifying body . . . . . .=    2

>    =   1.2.  Referencing the ID value uniquely identifying body  = . . .   3

> =

> This seems an awkward w= ay of phrasing it.  In particular, there seems to be=

> no reason to emphasize = uniqueness here.  Perhaps

> =

>    =   1.1.  Establishing a Content-ID identifying the body=

>    =   1.2.  Referencing the Content-ID value identifying the body

 

I agree it is awkward.<= /o:p>

 

I made it even shorter to:

-----------------=

     1.1= .  Identifying a body part . . . . . . . . . . . . . . . . . &nbs= p; 2

     1.2= .  Referencing a body part . . . . . . . . . . . . . . . . . &nbs= p; 3

-----------------=

 

>    =   5.1.  Header Field  . . . . . . . . . . . . . . . . . . . = . . .   6

>    6.&nb= sp; Change Log  . . . . . . . . . . . . . . . . . . . . . . . . . = ;  7

>    7.&nb= sp; Normative References  . . . . . . . . . . . . . . . . . . . . = ;  7

>    Autho= rs' Addresses  . . . . . . . . . . . . . . . . . . . . . . . &nbs= p; 8

> =

> These items capitalize = later words, whereas the other items capitalize only

> initial words.  It= seems that the current RFC style heavily favors

> capitalizing all the &q= uot;important" words in section titles.

 

I guess RFC editor will anyw= ay decide whether to capitalize all words of section titles or just the fir= st one. I have slight preference for the latter style. No strong view.=

 

> 1.  Introduction

> =

>    A mes= sage-body of the SIP message can contain one body only or can

>    conta= in several body parts, as specified in [RFC3261] and [RFC5621].<= /span>

> =

> Strictly speaking, a SI= P message containing several body parts also has a

> body (whose MIME type i= s multipart/something).  I think it would be better to

> phrase this<= /span>

> =

>    A mes= sage-body of the SIP message can be a non-multipart body or

>    can b= e a multipart body that contains several body parts, as

>    speci= fied in [RFC3261] and [RFC5621].

> =

> I think this can be car= ried through to other places that use the phrase "one

> body".  (Alth= ough "one body" is a close version of the phrase "unitary bo= dy",

> which would be a good t= erm for "non-multipart body", though nobody uses the phrase!)

 

OK to refer to "multipa= rt body" and "non-multipart body".

 

However:

1) in some places, this forc= es split of the sentence to two sentences.

2) in other places, I rather= talk about "content" where the "content" can be carrie= d in (a) a body part of multipart body, or (b) in non-multipart body.<= /o:p>

 

> 1.5.  Solution

> =

> Section 1.5 looks much = like section 3.3, and I think the duplication should

> be reduced.  Perha= ps the text in 1.5 could be reduced to

> =

>    The C= ontent-ID header field included in header fields of a SIP=

>    messa= ge identifies a body part consisting of the message-body of

>    the S= IP message.  The metadata provided by some additional header

>    field= s also applies to the message body as a whole.

 

OK to simplify.

 

I made it even shorter to:

-----------------=

   The Content-ID = header field included in the header fields of a SIP

   message identif= ies a body part consisting of the message-body of a

   SIP message and= metadata provided by some additional SIP header

   fields.

-----------------=

 

> 3.2.  Syntax<= /o:p>

> =

>    The A= BNF for the Content-ID header fields is:

> =

>    Conte= nt-ID =3D "Content-ID" HCOLON msg-id

> =

>    NOTE:= msg-id is specified in [RFC5322].

> =

> Comparing with RFC 5322= , I see:

> =

>    msg-i= d          =3D   [CF= WS] "<" id-left "@" id-right ">" [CFWS]=

> =

>    CFWS&= nbsp;           =3D =   (1*([FWS] comment) [FWS]) / FWS

> =

>    comme= nt         =3D   "(&= quot; *([FWS] ccontent) [FWS] ")"

> =

> I'm sure we don't want = to allow comments!

> =

> I can see a couple of w= ays to avoid this.  One is to annotate it:

> =

>    The A= BNF for the Content-ID header fields is:

> =

>    Conte= nt-ID =3D "Content-ID" HCOLON msg-id

> =

>    NOTE:= msg-id is specified in [RFC5322], but may not contain

>    "= ;comment".

> =

> But this allows RFC 532= 2's FWS, which is slightly broader than RFC 3261's

> SWS.  Probably bes= t is to force the whitespace to be in the style of RFC 3261:

> =

>    The A= BNF for the Content-ID header fields is:

> =

>    Conte= nt-ID =3D "Content-ID" HCOLON msg-id

> =

>    msg-i= d     =3D "<" id-left "@" id-rig= ht ">"

> =

>    NOTE:= id-left and id-right are specified in [RFC5322].

> =

> Note that SIP header fi= elds generally do not allow trailing whitespace.

 

Applied as suggested.

 

> 3.3.  Semantic

> =

> I think you want "= Semantics" as the section title.

> =

> I notice this item in t= he list (which is duplicated in section 1.5):

> =

>    o&nbs= p; a Content-ID header field, if included in the header fields of the<= /o:p>

>    =    SIP message;

> =

> This reads awkwardly, b= ecause the beginning of the paragraph has specified

> that there is a Content= -ID header field in the message.  I think this could=

> be clarified by promoti= ng this item to the top of the list and explicitly

> labeling it all as meta= data:

> =

>    The C= ontent-ID header field included in header fields of a SIP=

>    messa= ge identifies a body part consisting of the message-body of

>    the S= IP message and the following metadata:

> =

>    o&nbs= p; the Content-ID header field itself;

> =

> and then continuing wit= h "a MIME-Version header field", etc.

 

Good idea.=

 

Minor tweak - I would prefer= to state:

-----------------=

   The Content-ID = header field included in the header fields of a SIP

   message identif= ies a body part consisting of the message-body of the

   SIP message, an= d >>the metadata provided by<<:

 

   o  the Con= tent-ID header field itself;

   o  a MIME-= Version header field, if included in the header fields of=

    &nbs= p; the SIP message;

....

-----------------=

 

Kind regards

 

Ivo

--_000_AM5PR0701MB24689635B3D926F7B223C830E51B0AM5PR0701MB2468_-- From nobody Thu Apr 20 05:47: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 E8DF31294EF for ; Thu, 20 Apr 2017 05:47:12 -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, 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 YFyRKSWTxf7e for ; Thu, 20 Apr 2017 05:47:10 -0700 (PDT) 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 0A67C1294FA for ; Thu, 20 Apr 2017 05:47:08 -0700 (PDT) X-AuditID: c1b4fb30-aabff70000006667-42-58f8adcae320 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 3A.0D.26215.ACDA8F85; Thu, 20 Apr 2017 14:47:07 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0339.000; Thu, 20 Apr 2017 14:47:06 +0200 From: Christer Holmberg To: Ivo Sedlacek , "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-content-id-01 Thread-Index: AQHSskRgPN3A4rAB+kOqJk8KIGFSSqHOHvCAgAA294A= Date: Thu, 20 Apr 2017 12:47:05 +0000 Message-ID: References: <87shlgndaj.fsf@hobgoblin.ariadne.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D51E89681B58Bchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7ve7ptT8iDK7OErb4+mMTm8XLE2UO TB6T939l9liy5CdTAFMUl01Kak5mWWqRvl0CV8aHreuZC+Z9YKyY9OYZawPjrnOMXYycHBIC JhIrnj9g6WLk4hASWM8o0fZxMpSzhFFi6fMnQA4HB5uAhUT3P22QBhGBGonvHQ/ZQGxhAWeJ I23PmSHiLhLz9m9hhbCtJNqXrgarYRFQlbjX3w5m8wpYS6zqv80EMb+TUeLM9/fsIAlOgUSJ 76/3MYHYjAJiEt9PrQGzmQXEJW49mc8EcamAxJI955khbFGJl4//gS0TFdCT2PfvKxvInRIC ihLL++UgWhMk2rbOYIbYKyhxcuYTlgmMIrOQTJ2FpGwWkjKIuIHE+3PzmSFsbYllC19D2foS G7+cZYSwrSX+P/rFgqxmASPHKkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzAiDu45bfBDsaX zx0PMQpwMCrx8Cbkfo8QYk0sK67MPcQowcGsJMLbuupHhBBvSmJlVWpRfnxRaU5q8SFGaQ4W JXFex30XIoQE0hNLUrNTUwtSi2CyTBycUg2MCc6chgGJUTMuHuILnvjT8ra5ju+0uWxWTcHL jnk9bI37urXr3vWZ7VOFOPKeRO96ynNsoebs2bP16ox/32SvtJfheLciqyOfaffR0omb36um aXb1KRkcOtC2NnLP094VZ+PetfPdmMf56qVOYEnrlinXWKTYH3LXPdirvc996/cpBgy5ZqtK lViKMxINtZiLihMBv1UUXLQCAAA= Archived-At: Subject: Re: [sipcore] Comments on 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, 20 Apr 2017 12:47:13 -0000 --_000_D51E89681B58Bchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Pull request based on Ivo=92s reply: https://github.com/cdh4u/draft-content-id/pull/3 Regards, Christer From: sipcore > o= n behalf of Ivo Sedlacek > Date: Thursday 20 April 2017 at 15:34 To: Dale Worley >, "sipcore@i= etf.org" > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-content-id-01 Hello, first of all, thank you for the review. > The short title is "Content-ID-in-SIP", whereas it seems more natural to = use > "Content-ID in SIP". Applied as suggested. > Table of Contents > > 1.1. Setting up ID value uniquely identifying body . . . . . . 2 > 1.2. Referencing the ID value uniquely identifying body . . . 3 > > This seems an awkward way of phrasing it. In particular, there seems to = be > no reason to emphasize uniqueness here. Perhaps > > 1.1. Establishing a Content-ID identifying the body > 1.2. Referencing the Content-ID value identifying the body I agree it is awkward. I made it even shorter to: ----------------- 1.1. Identifying a body part . . . . . . . . . . . . . . . . . 2 1.2. Referencing a body part . . . . . . . . . . . . . . . . . 3 ----------------- > 5.1. Header Field . . . . . . . . . . . . . . . . . . . . . . 6 > 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 > > These items capitalize later words, whereas the other items capitalize on= ly > initial words. It seems that the current RFC style heavily favors > capitalizing all the "important" words in section titles. I guess RFC editor will anyway decide whether to capitalize all words of se= ction titles or just the first one. I have slight preference for the latter= style. No strong view. > 1. Introduction > > A message-body of the SIP message can contain one body only or can > contain several body parts, as specified in [RFC3261] and [RFC5621]. > > Strictly speaking, a SIP message containing several body parts also has a > body (whose MIME type is multipart/something). I think it would be bette= r to > phrase this > > A message-body of the SIP message can be a non-multipart body or > can be a multipart body that contains several body parts, as > specified in [RFC3261] and [RFC5621]. > > I think this can be carried through to other places that use the phrase "= one > body". (Although "one body" is a close version of the phrase "unitary bo= dy", > which would be a good term for "non-multipart body", though nobody uses t= he phrase!) OK to refer to "multipart body" and "non-multipart body". However: 1) in some places, this forces split of the sentence to two sentences. 2) in other places, I rather talk about "content" where the "content" can b= e carried in (a) a body part of multipart body, or (b) in non-multipart bod= y. > 1.5. Solution > > Section 1.5 looks much like section 3.3, and I think the duplication shou= ld > be reduced. Perhaps the text in 1.5 could be reduced to > > The Content-ID header field included in header fields of a SIP > message identifies a body part consisting of the message-body of > the SIP message. The metadata provided by some additional header > fields also applies to the message body as a whole. OK to simplify. I made it even shorter to: ----------------- The Content-ID header field included in the header fields of a SIP message identifies a body part consisting of the message-body of a SIP message and metadata provided by some additional SIP header fields. ----------------- > 3.2. Syntax > > The ABNF for the Content-ID header fields is: > > Content-ID =3D "Content-ID" HCOLON msg-id > > NOTE: msg-id is specified in [RFC5322]. > > Comparing with RFC 5322, I see: > > msg-id =3D [CFWS] "<" id-left "@" id-right ">" [CFWS] > > CFWS =3D (1*([FWS] comment) [FWS]) / FWS > > comment =3D "(" *([FWS] ccontent) [FWS] ")" > > I'm sure we don't want to allow comments! > > I can see a couple of ways to avoid this. One is to annotate it: > > The ABNF for the Content-ID header fields is: > > Content-ID =3D "Content-ID" HCOLON msg-id > > NOTE: msg-id is specified in [RFC5322], but may not contain > "comment". > > But this allows RFC 5322's FWS, which is slightly broader than RFC 3261's > SWS. Probably best is to force the whitespace to be in the style of RFC = 3261: > > The ABNF for the Content-ID header fields is: > > Content-ID =3D "Content-ID" HCOLON msg-id > > msg-id =3D "<" id-left "@" id-right ">" > > NOTE: id-left and id-right are specified in [RFC5322]. > > Note that SIP header fields generally do not allow trailing whitespace. Applied as suggested. > 3.3. Semantic > > I think you want "Semantics" as the section title. > > I notice this item in the list (which is duplicated in section 1.5): > > o a Content-ID header field, if included in the header fields of the > SIP message; > > This reads awkwardly, because the beginning of the paragraph has specifie= d > that there is a Content-ID header field in the message. I think this cou= ld > be clarified by promoting this item to the top of the list and explicitly > labeling it all as metadata: > > The Content-ID header field included in header fields of a SIP > message identifies a body part consisting of the message-body of > the SIP message and the following metadata: > > o the Content-ID header field itself; > > and then continuing with "a MIME-Version header field", etc. Good idea. Minor tweak - I would prefer to state: ----------------- The Content-ID header field included in the header fields of a SIP message identifies a body part consisting of the message-body of the SIP message, and >>the metadata provided by<<: o the Content-ID header field itself; o a MIME-Version header field, if included in the header fields of the SIP message; .... ----------------- Kind regards Ivo --_000_D51E89681B58Bchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5BB80D900D925A478466609E5494A664@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Pull request based on Ivo=92s reply: 


Regards,

Christer

From: sipcore <sipcore-bounces@ietf.org> on behalf of Iv= o Sedlacek <ivo.sedlacek@er= icsson.com>
Date: Thursday 20 April 2017 at 15:= 34
To: Dale Worley <worley@ariadne.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Comments on = draft-ietf-sipcore-content-id-01

Hello,

 

first of all, thank you for = the review.

 

> The short title is &quo= t;Content-ID-in-SIP", whereas it seems more natural to use<= /span>

> "Content-ID in SIP= ".

 

Applied as suggested.

 

> Table of Contents<= /o:p>

> =

>    =   1.1.  Setting up ID value uniquely identifying body . . . . . .=    2

>    =   1.2.  Referencing the ID value uniquely identifying body  = . . .   3

> =

> This seems an awkward w= ay of phrasing it.  In particular, there seems to be=

> no reason to emphasize = uniqueness here.  Perhaps

> =

>    =   1.1.  Establishing a Content-ID identifying the body=

>    =   1.2.  Referencing the Content-ID value identifying the body

 

I agree it is awkward.<= /o:p>

 

I made it even shorter to:

-----------------=

     1.1= .  Identifying a body part . . . . . . . . . . . . . . . . . &nbs= p; 2

     1.2= .  Referencing a body part . . . . . . . . . . . . . . . . . &nbs= p; 3

-----------------=

 

>    =   5.1.  Header Field  . . . . . . . . . . . . . . . . . . . = . . .   6

>    6.&nb= sp; Change Log  . . . . . . . . . . . . . . . . . . . . . . . . . = ;  7

>    7.&nb= sp; Normative References  . . . . . . . . . . . . . . . . . . . . = ;  7

>    Autho= rs' Addresses  . . . . . . . . . . . . . . . . . . . . . . . &nbs= p; 8

> =

> These items capitalize = later words, whereas the other items capitalize only

> initial words.  It= seems that the current RFC style heavily favors

> capitalizing all the &q= uot;important" words in section titles.

 

I guess RFC editor will anyw= ay decide whether to capitalize all words of section titles or just the fir= st one. I have slight preference for the latter style. No strong view.=

 

> 1.  Introduction

> =

>    A mes= sage-body of the SIP message can contain one body only or can

>    conta= in several body parts, as specified in [RFC3261] and [RFC5621].<= /span>

> =

> Strictly speaking, a SI= P message containing several body parts also has a

> body (whose MIME type i= s multipart/something).  I think it would be better to

> phrase this<= /span>

> =

>    A mes= sage-body of the SIP message can be a non-multipart body or

>    can b= e a multipart body that contains several body parts, as

>    speci= fied in [RFC3261] and [RFC5621].

> =

> I think this can be car= ried through to other places that use the phrase "one

> body".  (Alth= ough "one body" is a close version of the phrase "unitary bo= dy",

> which would be a good t= erm for "non-multipart body", though nobody uses the phrase!)

 

OK to refer to "multipa= rt body" and "non-multipart body".

 

However:

1) in some places, this forc= es split of the sentence to two sentences.

2) in other places, I rather= talk about "content" where the "content" can be carrie= d in (a) a body part of multipart body, or (b) in non-multipart body.<= /o:p>

 

> 1.5.  Solution

> =

> Section 1.5 looks much = like section 3.3, and I think the duplication should

> be reduced.  Perha= ps the text in 1.5 could be reduced to

> =

>    The C= ontent-ID header field included in header fields of a SIP=

>    messa= ge identifies a body part consisting of the message-body of

>    the S= IP message.  The metadata provided by some additional header

>    field= s also applies to the message body as a whole.

 

OK to simplify.

 

I made it even shorter to:

-----------------=

   The Content-ID = header field included in the header fields of a SIP

   message identif= ies a body part consisting of the message-body of a

   SIP message and= metadata provided by some additional SIP header

   fields.

-----------------=

 

> 3.2.  Syntax<= /o:p>

> =

>    The A= BNF for the Content-ID header fields is:

> =

>    Conte= nt-ID =3D "Content-ID" HCOLON msg-id

> =

>    NOTE:= msg-id is specified in [RFC5322].

> =

> Comparing with RFC 5322= , I see:

> =

>    msg-i= d          =3D   [CF= WS] "<" id-left "@" id-right ">" [CFWS]=

> =

>    CFWS&= nbsp;           =3D =   (1*([FWS] comment) [FWS]) / FWS

> =

>    comme= nt         =3D   "(&= quot; *([FWS] ccontent) [FWS] ")"

> =

> I'm sure we don't want = to allow comments!

> =

> I can see a couple of w= ays to avoid this.  One is to annotate it:

> =

>    The A= BNF for the Content-ID header fields is:

> =

>    Conte= nt-ID =3D "Content-ID" HCOLON msg-id

> =

>    NOTE:= msg-id is specified in [RFC5322], but may not contain

>    "= ;comment".

> =

> But this allows RFC 532= 2's FWS, which is slightly broader than RFC 3261's

> SWS.  Probably bes= t is to force the whitespace to be in the style of RFC 3261:

> =

>    The A= BNF for the Content-ID header fields is:

> =

>    Conte= nt-ID =3D "Content-ID" HCOLON msg-id

> =

>    msg-i= d     =3D "<" id-left "@" id-rig= ht ">"

> =

>    NOTE:= id-left and id-right are specified in [RFC5322].

> =

> Note that SIP header fi= elds generally do not allow trailing whitespace.

 

Applied as suggested.

 

> 3.3.  Semantic

> =

> I think you want "= Semantics" as the section title.

> =

> I notice this item in t= he list (which is duplicated in section 1.5):

> =

>    o&nbs= p; a Content-ID header field, if included in the header fields of the<= /o:p>

>    =    SIP message;

> =

> This reads awkwardly, b= ecause the beginning of the paragraph has specified

> that there is a Content= -ID header field in the message.  I think this could=

> be clarified by promoti= ng this item to the top of the list and explicitly

> labeling it all as meta= data:

> =

>    The C= ontent-ID header field included in header fields of a SIP=

>    messa= ge identifies a body part consisting of the message-body of

>    the S= IP message and the following metadata:

> =

>    o&nbs= p; the Content-ID header field itself;

> =

> and then continuing wit= h "a MIME-Version header field", etc.

 

Good idea.=

 

Minor tweak - I would prefer= to state:

-----------------=

   The Content-ID = header field included in the header fields of a SIP

   message identif= ies a body part consisting of the message-body of the

   SIP message, an= d >>the metadata provided by<<:

 

   o  the Con= tent-ID header field itself;

   o  a MIME-= Version header field, if included in the header fields of=

    &nbs= p; the SIP message;

....

-----------------=

 

Kind regards

 

Ivo

 --_000_D51E89681B58Bchristerholmbergericssoncom_-- From nobody Thu Apr 20 10:39: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 E96711314A3 for ; Thu, 20 Apr 2017 10:39:40 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" 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 EoHrofnMmuxO for ; Thu, 20 Apr 2017 10:39:40 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id DE32E129B3A for ; Thu, 20 Apr 2017 10:39:39 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 20 Apr 2017 10:41:25 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <87shlgndaj.fsf@hobgoblin.ariadne.com> References: <87shlgndaj.fsf@hobgoblin.ariadne.com> X-Mailer: Eudora for Mac OS X Date: Thu, 20 Apr 2017 10:39:37 -0700 To: sipcore@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: [sipcore] 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, 20 Apr 2017 17:39:41 -0000 (1) Section 1.1 seems overly complex: However, when the message-body of the SIP message contains one body only, there is no body part specified. Thus, there is also no defined method how to convey an ID value uniquely identifying the body part. Perhaps: However, when the message-body of the SIP message is not a multipart, there is no way to convey an ID value identifying the body part. (2) Section 1.3 seems overly complex: Since the Content-ID header field is not a defined SIP header field: o If solely one body needs to be transported in a SIP message and the UAC does not need to include in the SIP message a SIP header field referencing the body part, then the UAC sets the message- body to the body. o However, if solely one body needs to be transported in a SIP message and the UAC needs to include in the SIP message a SIP header field referencing the body part, then the UAC sets the message-body to be of the "multipart" MIME type and includes one body part and associated Content-ID header field. Perhaps: Since the Content-ID header field is not a defined SIP header field, it is not possible to reference a unitary or the top-level body part. In cases where only a single part part is included and needs to be referenced, it must be wrapped in an otherwise unnecessary multipart/mixed. (3) Section 1.4.1 seems overly complex: the UAC needs to include a message-body of "multipart/mixed" MIME type in the INVITE request, and the UAC needs to include a body part of the application/pidf+xml MIME type and associated Content-ID header field in the message-body of the "multipart/mixed" MIME type. Perhaps: the UAC needs to wrap the application/pidf+xml body part in a multipart/mixed MIME media type, in order to be able to have a Content-ID header field referencing the application/pidf+xml. (4) Section 1.4.2 seems overly complex: UAC needs to include a message-body of the "multipart/mixed" MIME type in the REFER request and the UAC needs to include a body part of the application/resource-lists+xml MIME type and associated Content- ID header field in the message-body of the "multipart/mixed" MIME type. Perhaps: the UAC needs to wrap the application/resource-lists+xml body part in a multipart/mixed MIME media type, in order to be able to have a Refer-To header field referencing the application/resource-lists+xml body part. (5) Suggested text changes in Section 1.5: OLD: To avoid the unnecessary usage of a message-body of a "multipart" MIME type when only one body needs to be included in a SIP message, this document specifies a Content-ID header field as a SIP header field. The Content-ID header field included in header fields of a SIP message identifies a body part consisting of the message-body of the SIP message and: NEW: To avoid the need to unnecessary wrap a message body in a multipart MIME type, this document specifies the Content-ID header field as a SIP header field. A Content-ID header field included in the header fields of a SIP message identifies a body part consisting of the message-body of the SIP message and: -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Ask a question and you're a fool for three minutes; do not ask a question and you're a fool for the rest of your life. --Chinese proverb From nobody Thu Apr 20 11:11:21 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 20868128E19 for ; Thu, 20 Apr 2017 11:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 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] 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 IF3LrQvem1o6 for ; Thu, 20 Apr 2017 11:11:18 -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 25880126C25 for ; Thu, 20 Apr 2017 11:11:18 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-04v.sys.comcast.net with SMTP id 1GXYdn7t9scBP1GY1doxSP; Thu, 20 Apr 2017 18:11:17 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-10v.sys.comcast.net with SMTP id 1GY0dJEb1X2Fj1GY0dbyXA; Thu, 20 Apr 2017 18:11:17 +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 v3KIBFAH017906; Thu, 20 Apr 2017 14:11:15 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v3KIBFTL017903; Thu, 20 Apr 2017 14:11:15 -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: Ivo Sedlacek Cc: sipcore@ietf.org In-Reply-To: (ivo.sedlacek@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 20 Apr 2017 14:11:15 -0400 Message-ID: <877f2f0x18.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfIC/hMKX5WDxMdZLKChYYZcOdHlRyrPtMR48wCjkw9+cU+iGGQA3pJwMzJ86FBCP4mr/I8eQdlxGMUwQqpnBVvx+hILXS5Y1cx7JkYSbySjh/kaQc8d1 rPT1FAcvNCzd2Ym7fsOQ7dRFNVKTYe/spTuObY0Y2/pvI6lmNGQon8KhnMj28Ut3JiwNF8+vnCP4HrWiDAmsdKoXus7+1kJ/QCA= Archived-At: Subject: Re: [sipcore] Comments on 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, 20 Apr 2017 18:11:19 -0000 Ivo Sedlacek writes: > However: > > 1) in some places, this forces split of the sentence to two sentences. > > 2) in other places, I rather talk about "content" where the "content" > can be carried in (a) a body part of multipart body, or (b) in > non-multipart body. Well... What exactly do you want the term to mean? I mean, there are three things I can name off the top of my head: - the body of the SIP message - a body part which is not itself a multipart - a body part which is part of a multipart Given that parts of multiparts can themselves be multiparts, there are body parts that are examples for most of the eight possible true/false combinations of these properties. As far as I know, there's no (interesting) statement one can make which requires an "A or B" description of its subject -- as long as you carefully think through what it is that you mean, and choose a phrase that accurately describes it. In your example, I suspect that you use "content" to mean "a body part which is not itself a multipart" (since the whole body is itself a body part). Dale From nobody Thu Apr 20 13:04:08 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 81682131657 for ; Thu, 20 Apr 2017 13:04:06 -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 XJrFF9K8hcVh for ; Thu, 20 Apr 2017 13:04:04 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 C8BD2131649 for ; Thu, 20 Apr 2017 13:04:04 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-06v.sys.comcast.net with SMTP id 1IIGd7Xwwl4eq1IJ9d5C2k; Thu, 20 Apr 2017 20:04:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1492718643; bh=UFuemkl2Tun0Wh1bc0kiPtByzMe5qK2FtLKGajcSvCs=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=LcKup/udaJ1P3N6aGqw6LCjT1JAHEvQWHbGRV34g1P2jz3/4U2DInZaO+NaJfFTXl oBWlLYTAQkasgheasbH1ZidK+t/DGPFsIWY4R0AsQJIWnJN39Vc+jsYTkfchdLG3xH SP7yRqRzh31zqzVBUItnM1EhURUkTtvHZsLoYdo22cRmMcFHQilFrLJZywDdVb8ijS EWEgAMGledYJUg4ga9Numk/G9tg0kxEecXRqd7nyBCUaXuYjMMGvN+McVnzA5X0zO1 okLRyk8KRawdEmMZANWS1RQItatqvBrIElNu0Roam9XpCgdptQV/BxtKDT6wBMSZiS wLDoFMsIbx2Cg== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-12v.sys.comcast.net with SMTP id 1IJ8d45y9qoNE1IJ9dSD3H; Thu, 20 Apr 2017 20:04:03 +0000 To: sipcore@ietf.org References: <877f2f0x18.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <8787b197-44e9-3602-4771-4dec432e8d72@comcast.net> Date: Thu, 20 Apr 2017 16:04:02 -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: <877f2f0x18.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfG48BHhUBVttbU/+ApHI0mrJLSP+/tJMHf1y7p3uDIiesAuYxnWHB/Pn03hrptEDSslfPlfQosBpy9nenzrtzGUjmBO0+664A6QYY3WsNxERdkFuslnP oYxvjQPBMOYLxATqx/3YK/tfaWNanNFAI2Jz8sPWdJeFBgxhXbtcwjwHAK+iaR7ZptPRQNTzNlsSIQ== Archived-At: Subject: Re: [sipcore] Comments on 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, 20 Apr 2017 20:04:06 -0000 I still think it is simpler to think of the entire sip message, with the exception of the Request-Line and Status-Line, as a mime message, with all the uniquely sip message-headers simply being mime extension headers. Then all these nomenclature issues go away. Thanks, Paul On 4/20/17 2:11 PM, Dale R. Worley wrote: > Ivo Sedlacek writes: >> However: >> >> 1) in some places, this forces split of the sentence to two sentences. >> >> 2) in other places, I rather talk about "content" where the "content" >> can be carried in (a) a body part of multipart body, or (b) in >> non-multipart body. > > Well... What exactly do you want the term to mean? I mean, there are > three things I can name off the top of my head: > > - the body of the SIP message > - a body part which is not itself a multipart > - a body part which is part of a multipart > > Given that parts of multiparts can themselves be multiparts, there are > body parts that are examples for most of the eight possible true/false > combinations of these properties. > > As far as I know, there's no (interesting) statement one can make which > requires an "A or B" description of its subject -- as long as you > carefully think through what it is that you mean, and choose a phrase > that accurately describes it. > > In your example, I suspect that you use "content" to mean "a body part > which is not itself a multipart" (since the whole body is itself a body > part). > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Apr 20 16:35: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 0DFEB129BBD; Thu, 20 Apr 2017 16:35:24 -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, 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 (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 u4kH07lFe4tQ; Thu, 20 Apr 2017 16:35:21 -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 85B11129B75; Thu, 20 Apr 2017 16:35:21 -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 v3KNZHRt005226; Thu, 20 Apr 2017 23:35:17 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0056.outbound.protection.outlook.com [23.103.198.56]) by mx0b-0024ed01.pphosted.com with ESMTP id 29wqpe9qhg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 20 Apr 2017 23:35:17 +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=cT/p4kNmjuakHzCvMpKfn/S5Lqj9tsgvVNVbESH5/Ks=; b=sXC/HsxJGuFps6k6lA3l3X0uATNMTAhJ925uNrRBtwWJN34Ted/4nCiZDn/N9Xk4xDfhgbPct4jLhNSM03iEaO/kSJJJw36jFBuDOpmUACH9hBiMI3BGPQzFmar8ubJ8uEwfRj78Km9wxOGG+DVdv1356sDXyaeXPZVi0ZEfbZo= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Thu, 20 Apr 2017 23:35:16 +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.1034.018; Thu, 20 Apr 2017 23:35:16 +0000 From: Henning Schulzrinne To: Peter Yee , "gen-art@ietf.org" CC: "sipcore@ietf.org" , "draft-ietf-sipcore-status-unwanted.all@ietf.org" Thread-Topic: Review of draft-ietf-sipcore-status-unwanted-04 Thread-Index: AQHSor6bOa15gxoBWk6pbW5i+wNrkKHPEZ67 Date: Thu, 20 Apr 2017 23:35:15 +0000 Message-ID: References: <149015426220.3518.3546300688917567228@ietfa.amsl.com> In-Reply-To: <149015426220.3518.3546300688917567228@ietfa.amsl.com> 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: [172.56.3.117] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:vg5JZ6KS8IOaAiVnZl1tsL4kesizWSXmF9+zHmRq8YY0JLMgZ4VWq5OLO0v8HvQydbobclJT3/Lxlz8v/i88EqyQiByD6yuve4QbTHYYWdgEnNH+LHtYG8/0hCto2A68Qy+YN7lxokMmQwS5tnFCK3piT0ccgtXrsv71Q3rtutWGA4nwHVrl7Qgmt97pI7BCs0TKTlGOWLTfi3N2qTuAOu2tNEU46Ok75bolM47k3fv83bvr95wxAtbB3shB+D8pcBQr2yP/yZ2I2aU3jVkYGmaJUa2v6jpo3/Ye372aUh7yfXfhcaMlueBtMITLgkV2Ihic6iWeMCZcnFj3CymHrQ== x-ms-office365-filtering-correlation-id: ada04fe3-f616-488d-207a-08d48845e616 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR09MB0636; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39840400002)(39400400002)(39450400003)(377454003)(377424004)(6436002)(7696004)(6306002)(54896002)(229853002)(8676002)(2900100001)(76176999)(81166006)(53936002)(38730400002)(345774005)(5660300001)(9686003)(7736002)(54356999)(99286003)(54906002)(74316002)(236005)(733005)(8936002)(53546009)(50986999)(6506006)(66066001)(77096006)(4326008)(25786009)(55016002)(6246003)(19627405001)(3660700001)(3280700002)(189998001)(575784001)(86362001)(2501003)(2950100002)(6116002)(33656002)(122556002)(3846002)(102836003)(6606003)(230783001)(2906002)(18265965002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634018DB677B3D60B82AF84EA1B0CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 23:35:15.8061 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-20_21:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Review of draft-ietf-sipcore-status-unwanted-04 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, 20 Apr 2017 23:35:24 -0000 --_000_CY1PR09MB0634018DB677B3D60B82AF84EA1B0CY1PR09MB0634namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for your comments. You have captured the spirit of the discussion= well [??] I will be submitting an updated version soon, including your suggestions. Henning ________________________________ From: Peter Yee Sent: Tuesday, March 21, 2017 11:44:22 PM To: gen-art@ietf.org Cc: sipcore@ietf.org; ietf@ietf.org; draft-ietf-sipcore-status-unwanted.all= @ietf.org Subject: Review of draft-ietf-sipcore-status-unwanted-04 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". --_000_CY1PR09MB0634018DB677B3D60B82AF84EA1B0CY1PR09MB0634namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


Thank you for your comments. You have captured the spirit of the discuss= ion well 3D"��"=


I will be submitting an updated version soon, including your suggestions= .


Henning

From: Peter Yee <peter= @akayla.com>
Sent: Tuesday, March 21, 2017 11:44:22 PM
To: gen-art@ietf.org
Cc: sipcore@ietf.org; ietf@ietf.org; draft-ietf-sipcore-status-unwan= ted.all@ietf.org
Subject: Review of draft-ietf-sipcore-status-unwanted-04
 
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

<https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A_= _trac.ietf.org_trac_gen_wiki_GenArtfaq&d=3DDwICaQ&c=3Dy0h0omCe0jAUG= r4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DW4wBo= 6GdFdfpAg5ssVa_1afyCooA6uWETUt3nUwbQXw&s=3DUF7qskUlKSBGGMotRXuQPGcmFLyJ= IvmjjjiMNnXFdNQ&e=3D >.

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<= br> at "based on") that doesn't fit neatly in the sequence.  Per= haps
inserting "and" before "based" would help.  Append= "as" after "well".

Page 5, Section 6, 2nd paragraph, 1st sentence: change "extract" = to
"exact".

--_000_CY1PR09MB0634018DB677B3D60B82AF84EA1B0CY1PR09MB0634namp_-- From nobody Thu Apr 20 17:55: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 7EB0C12EAB5 for ; Thu, 20 Apr 2017 17:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 y6NycuEDSQbB for ; Thu, 20 Apr 2017 17:55:26 -0700 (PDT) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (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 8A8BB12EAB2 for ; Thu, 20 Apr 2017 17:55:26 -0700 (PDT) Received: from pps.filterd (m0102172.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3L0rq1S020752; Fri, 21 Apr 2017 00:55:24 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0055.outbound.protection.outlook.com [23.103.198.55]) by mx0a-0024ed01.pphosted.com with ESMTP id 29wqpehu0q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 21 Apr 2017 00:55:24 +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=AMuZYMGtE6erP+B4PbW+x8pKNRqAk65HB5wHGi0C1Qw=; b=qKEX0C/C8m1EdK1Ty4HXiJTFeUqDxeljkQMNISwbX2+XmfScI5/TTe8DSLT/kdEMxPwDqnaIVtDUSaxarAyQv9zAIMULDzyPXqXRFyXwKpWAaXCnjAK2sUaP3RKOuLmv1Xc2ChZ3gs9VC73asAxIfQHAgG26YyaTNqLs2ALP6uo= 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_128_CBC_SHA256_P256) id 15.1.1034.10; Fri, 21 Apr 2017 00:55:21 +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.1034.018; Fri, 21 Apr 2017 00:55:21 +0000 From: Henning Schulzrinne To: Ben Campbell , "draft-ietf-sipcore-status-unwanted-04.all@ietf.org" , SIPCORE Thread-Topic: [sipcore] AD Evaluation of draft-ietf-sipcore-status-unwanted-04 Thread-Index: AQHSl5yG5euEVfQq2EaYy4li4EKtTKHPP5KD Date: Fri, 21 Apr 2017 00:55:20 +0000 Message-ID: References: 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=fcc.gov; x-originating-ip: [172.56.3.117] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 7:t/w1vqrR+WBG5cHmu4zhT8Jq8L3uhzhv1pz6Y7PelN1aB6d5RKCPU4tQT2Vpvd4AUp+Uad9caYd4YvHnhK7vepzFvnRuTqnijBfYqItyk34ApnS1VIjAyxQTTIxUHFztPecdgp7sg9wXDQkeKU2Dhuew5NgSxz58DVERz/ajuA/PeaHL9mnjx505GMxfOHeB6/VcGaFhvK+xEOS3pgd/33LELSvci5D2b054YuCxxgHXo0Ybps/L6grkXDlhRAorm9TqkmCu/bPF6DNXtaoVU29oJmh4ATQsybyn7w11Vd5az0Gp71s9WZ9+jpF+kQt5/S4up5DYtFVFmESD1YSUEg== x-ms-office365-filtering-correlation-id: 4aefa207-cd81-44ed-39a2-08d488511635 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:CY1PR09MB0634; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39410400002)(39840400002)(51914003)(377454003)(99286003)(9686003)(8676002)(55016002)(54896002)(66066001)(189998001)(3660700001)(7696004)(551934003)(6436002)(2950100002)(122556002)(3280700002)(6606003)(5660300001)(38730400002)(77096006)(7736002)(74316002)(2900100001)(8936002)(33656002)(81166006)(53546009)(6506006)(229853002)(25786009)(2906002)(50986999)(102836003)(76176999)(3846002)(86362001)(19627405001)(2501003)(6116002)(230783001)(54356999)(6246003)(53936002); 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: multipart/alternative; boundary="_000_CY1PR09MB063465DBC8C6DFF74EE3E16CEA1A0CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 00:55:20.9775 (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-04-20_22:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-status-unwanted-04 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, 21 Apr 2017 00:55:28 -0000 --_000_CY1PR09MB063465DBC8C6DFF74EE3E16CEA1A0CY1PR09MB0634namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ben, thanks for the comments. Responses inline below, split into parts. ________________________________ From: sipcore on behalf of Ben Campbell Sent: Tuesday, March 7, 2017 6:42 PM To: draft-ietf-sipcore-status-unwanted-04.all@ietf.org; SIPCORE Subject: [sipcore] AD Evaluation of draft-ietf-sipcore-status-unwanted-04 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. - 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.) I used calling and called party user agent to avoid the one-letter hamming = distance. I think I have removed all UAS reference. -- 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? I broke the sentence and paragraph into smaller, more readily-digestible, p= ieces. -- 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, ..." The service provider delivering calls or messages to the user issuing the r= esponse MAY take actions, for example, ... (without MAYs). --4, 4th paragraph: I'm not sure I believe the sentence starting with "In other words" paraphrases any previous words :-) Two thoughts got commingled. Separated into two paragraphs and no more othe= r words. --6: 2nd to last paragraph: A citation for call transfer might be nice. (Maybe the call flows RFC?) Citation added. --_000_CY1PR09MB063465DBC8C6DFF74EE3E16CEA1A0CY1PR09MB0634namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ben,


thanks for the comments. Responses inline below, split into parts.


From: sipcore <sipcore= -bounces@ietf.org> on behalf of Ben Campbell <ben@nostrum.com>
Sent: Tuesday, March 7, 2= 017 6:42 PM
To: draft-ietf-sipcore-st= atus-unwanted-04.all@ietf.org; SIPCORE
Subject: [sipcore] AD Eva= luation of draft-ietf-sipcore-status-unwanted-04
 
Hi,

This is my AD evaluation of draft-ietf-sipcore-sta= tus-unwanted-04. I
have a few substantive and and some editorial comm= ents. 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.



- Editori= al 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-in= itiating transaction (at least when a dialog is involved), but
it ends u= p with language of the form of "... when the UAS sends a BYE
request..= .". Perhaps terms like "caller UA" and "callee UA"= would be
more clea= r? (Not that I particularly those, when caller and callee or
called va= ry by a single letter.)

I used calling and called party us= er agent to avoid the one-letter hamming distance. I think I have removed all UAS reference.

-- sectio= n 1, first paragraph, sentence starting with "This document
addresses= only the last mode..."
The sente= nce is convoluted. Can it be broken into  a few simpler
sentences= ?

I broke the sentence and paragraph into smal= ler, more readily-digestible, pieces.

-- 4, 2nd= paragraph:
Please av= oid 2119 keywords (in this case MAY), in a non-exhaustive list
of exampl= es, as it implies that additional MAYs exist but are not
explicitl= y mentioned. Consider something along the lines of "...MAY
perform s= ome action based on local policy, for example, add the party to
a local b= lacklist, ..."

The service provider delivering calls or messages to= the user issuing the response MAY take actions, for example, ... (without = MAYs).


--4, 4th = paragraph: I'm not sure I believe the sentence starting with
"In = other words" paraphrases any previous words :-)

Two thoughts got com= mingled. Separated into two paragraphs and no more other words.

--6: 2nd = to last paragraph: A citation for call transfer might be nice.
(Maybe th= e call flows RFC?)

Citation added.

--_000_CY1PR09MB063465DBC8C6DFF74EE3E16CEA1A0CY1PR09MB0634namp_-- From nobody Thu Apr 20 18:01: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 BAF1712EAB3 for ; Thu, 20 Apr 2017 18:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 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, 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 76id56tO6g2i for ; Thu, 20 Apr 2017 18:01:40 -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 3F9AC12EA8C for ; Thu, 20 Apr 2017 18:01:39 -0700 (PDT) Received: from [10.0.1.63] (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 v3L11aSc073153 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 20 Apr 2017 20:01:36 -0500 (CDT) (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.63] From: Ben Campbell Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F0858F28-A19D-4968-B79B-5573FD59FE15" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 20 Apr 2017 20:01:35 -0500 In-Reply-To: Cc: "draft-ietf-sipcore-status-unwanted-04.all@ietf.org" , SIPCORE To: Henning Schulzrinne References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-status-unwanted-04 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, 21 Apr 2017 01:01:42 -0000 --Apple-Mail=_F0858F28-A19D-4968-B79B-5573FD59FE15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All sounds good, subject to seeing things in situ. Thanks! Ben. > On Apr 20, 2017, at 7:55 PM, Henning Schulzrinne = wrote: >=20 > Ben, >=20 > thanks for the comments. Responses inline below, split into parts. >=20 > From: sipcore on behalf of Ben Campbell = > Sent: Tuesday, March 7, 2017 6:42 PM > To: draft-ietf-sipcore-status-unwanted-04.all@ietf.org; SIPCORE > Subject: [sipcore] AD Evaluation of = draft-ietf-sipcore-status-unwanted-04 > =20 > Hi, >=20 > 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. >=20 >=20 >=20 > - Editorial Comments: >=20 > -- 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.) >=20 > I used calling and called party user agent to avoid the one-letter = hamming distance. I think I have removed all UAS reference. >=20 > -- 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? >=20 > I broke the sentence and paragraph into smaller, more = readily-digestible, pieces. >=20 > -- 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, ..." >=20 > The service provider delivering calls or messages to the user issuing = the response MAY take actions, for example, ... (without MAYs). >=20 >=20 > --4, 4th paragraph: I'm not sure I believe the sentence starting with > "In other words" paraphrases any previous words :-) >=20 > Two thoughts got commingled. Separated into two paragraphs and no more = other words. >=20 > --6: 2nd to last paragraph: A citation for call transfer might be = nice. > (Maybe the call flows RFC?) >=20 > Citation added. --Apple-Mail=_F0858F28-A19D-4968-B79B-5573FD59FE15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All = sounds good, subject to seeing things in = situ.

Thanks!

Ben.

On Apr 20, 2017, at 7:55 PM, Henning = Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

Ben,

thanks for the comments. = Responses inline below, split into parts.

From: sipcore <sipcore-bounces@ietf.org> on behalf of Ben Campbell = <ben@nostrum.com>
Sent: Tuesday, March 7, 2017 = 6:42 PM
To: draft-ietf-sipcore-status-unwanted-04.all@ietf.org; = SIPCORE
Subject: [sipcore] AD Evaluation of = draft-ietf-sipcore-status-unwanted-04
 
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.



- = 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.)

I used calling = and called party user agent to avoid the one-letter hamming distance. I = think I have removed all UAS reference.

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

I broke the sentence = and paragraph into smaller, more readily-digestible, pieces.

-- 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, = ..."

The service provider delivering calls = or messages to the user issuing the response MAY take actions, for = example, ... (without MAYs).


--4, 4th paragraph: I'm not sure I believe the sentence = starting with
"In other words" paraphrases any previous = words :-)

Two thoughts got commingled. = Separated into two paragraphs and no more other words.

--6: 2nd to last paragraph: A citation for call transfer = might be nice.
(Maybe the call flows RFC?)
Citation added.

= --Apple-Mail=_F0858F28-A19D-4968-B79B-5573FD59FE15-- From nobody Thu Apr 20 18:03: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 34D6D12EAB7; Thu, 20 Apr 2017 18:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 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, 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 kythsKlID0ft; Thu, 20 Apr 2017 18:03: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 6B03712EAB3; Thu, 20 Apr 2017 18:03:39 -0700 (PDT) Received: from [10.0.1.63] (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 v3L13b6u073297 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 20 Apr 2017 20:03:38 -0500 (CDT) (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.63] From: Ben Campbell Message-Id: <75FAC1A1-479A-47E7-A050-737B2E62E85D@nostrum.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4918E489-F5D7-4016-803C-49700596F760" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 20 Apr 2017 20:03:37 -0500 In-Reply-To: Cc: SIPCORE , draft-ietf-sipcore-status-unwanted.all@ietf.org To: Henning Schulzrinne References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-status-unwanted-04 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, 21 Apr 2017 01:03:41 -0000 --Apple-Mail=_4918E489-F5D7-4016-803C-49700596F760 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All sounds good, subject to seeing things in situ. Thanks! Ben. > On Apr 20, 2017, at 7:55 PM, Henning Schulzrinne = > = wrote: >=20 > Ben, >=20 > thanks for the comments. Responses inline below, split into parts. >=20 > From: sipcore > on behalf of Ben Campbell = > Sent: Tuesday, March 7, 2017 6:42 PM > To: draft-ietf-sipcore-status-unwanted-04.all@ietf.org; SIPCORE > Subject: [sipcore] AD Evaluation of = draft-ietf-sipcore-status-unwanted-04 > =20 > Hi, >=20 > 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. >=20 >=20 >=20 > - Editorial Comments: >=20 > -- 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.) >=20 > I used calling and called party user agent to avoid the one-letter = hamming distance. I think I have removed all UAS reference. >=20 > -- 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? >=20 > I broke the sentence and paragraph into smaller, more = readily-digestible, pieces. >=20 > -- 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, ..." >=20 > The service provider delivering calls or messages to the user issuing = the response MAY take actions, for example, ... (without MAYs). >=20 >=20 > --4, 4th paragraph: I'm not sure I believe the sentence starting with > "In other words" paraphrases any previous words :-) >=20 > Two thoughts got commingled. Separated into two paragraphs and no more = other words. >=20 > --6: 2nd to last paragraph: A citation for call transfer might be = nice. > (Maybe the call flows RFC?) >=20 > Citation added. --Apple-Mail=_4918E489-F5D7-4016-803C-49700596F760 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All sounds good, subject to seeing things in = situ.

Thanks!

Ben.

On Apr 20, 2017, at 7:55 PM, Henning = Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

Ben,

thanks for the comments. = Responses inline below, split into parts.

From: sipcore <sipcore-bounces@ietf.org> on behalf of Ben Campbell = <ben@nostrum.com>
Sent: Tuesday, = March 7, 2017 6:42 PM
To: draft-ietf-sipcore-status-unwanted-04.all@ietf.org; = SIPCORE
Subject: [sipcore] AD Evaluation of = draft-ietf-sipcore-status-unwanted-04
 
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.



- = 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.)

I used calling = and called party user agent to avoid the one-letter hamming distance. I = think I have removed all UAS reference.

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

I broke the sentence = and paragraph into smaller, more readily-digestible, pieces.

-- 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, = ..."

The service provider delivering calls = or messages to the user issuing the response MAY take actions, for = example, ... (without MAYs).


--4, 4th paragraph: I'm not sure I believe the sentence = starting with
"In other words" paraphrases any previous = words :-)

Two thoughts got commingled. = Separated into two paragraphs and no more other words.

--6: 2nd to last paragraph: A citation for call transfer = might be nice.
(Maybe the call flows RFC?)
Citation added.

= --Apple-Mail=_4918E489-F5D7-4016-803C-49700596F760-- From nobody Thu Apr 20 18:34: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 C196F126557 for ; Thu, 20 Apr 2017 18:34:11 -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, 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 (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 6ykvwvr5Gjcs for ; Thu, 20 Apr 2017 18:34:09 -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 4C059126DD9 for ; Thu, 20 Apr 2017 18:34:09 -0700 (PDT) Received: from pps.filterd (m0102175.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3L1XQil013986; Fri, 21 Apr 2017 01:34:08 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0049.outbound.protection.outlook.com [23.103.198.49]) by mx0b-0024ed01.pphosted.com with ESMTP id 29wqpehtqb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 21 Apr 2017 01:34:07 +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=FwI8dkVAigOmi4IftVseScWU0gTT4UDpWVn+jxsLtAU=; b=mvPiiEHCf/h5h7nVH7kRpGTsoAgfKOWghBUEaUh/XwkGsLofYth6b6ui6ZUacEY1nd0H5CqHFYyGRvOHKH68l5g5hLpLhq5gI3iKeqeYwG+dDIG6NBWroPhN1HCRUs41yn49F2KlgBygAray7/yTLA2PsGM/VRPwOEVW9Glwm68= 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_128_CBC_SHA256_P256) id 15.1.1034.10; Fri, 21 Apr 2017 01:34:06 +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.1034.018; Fri, 21 Apr 2017 01:34:06 +0000 From: Henning Schulzrinne To: Ben Campbell , "draft-ietf-sipcore-status-unwanted-04.all@ietf.org" , SIPCORE Thread-Topic: [sipcore] AD Evaluation of draft-ietf-sipcore-status-unwanted-04 Thread-Index: AQHSl5yG5euEVfQq2EaYy4li4EKtTKHPR2l8 Date: Fri, 21 Apr 2017 01:34:06 +0000 Message-ID: References: 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=fcc.gov; x-originating-ip: [172.56.3.117] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 7:gxDmsaBDoiZMJSaWvc1Gq2ijhMsdvwEf8dSbYVkg31EnzPETU/eKI3u6ZOwKROyxs3qZBvJ230TT5oU1J9rpwZ3BR2/dAA0FhXk2LT8fHavWxiPSv6GC6qjrRpTX2SCCsZ8E79ndP2stmS8pLJgKQPTOUuyPoY8rGQB2+GUhI6f1jGqKIHaXEHUzVjzSw0rfNmhxTrSYtjxN69p4tHGrGov9xTX7Nq5pE9fxRKLOkTShlXW302/2VFZ5gDYl5Lw2Eka6e3r/O1V4E+8vmwA4f6qhnLEaaxUybT0T4vjqGg9+AwRa7A8E6bVG755EWGtWcNs3oJYUAV7ZjXTpzSAHtQ== x-ms-office365-filtering-correlation-id: 8e51d474-3c52-47ab-d676-08d488568020 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR09MB0634; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39840400002)(39450400003)(39410400002)(54094003)(2501003)(102836003)(50986999)(3846002)(76176999)(19627405001)(86362001)(54356999)(53936002)(6246003)(6116002)(230783001)(6436002)(3280700002)(122556002)(2950100002)(7696004)(38730400002)(5660300001)(6606003)(55016002)(99286003)(8676002)(9686003)(3660700001)(54896002)(189998001)(66066001)(229853002)(6506006)(2906002)(25786009)(7736002)(74316002)(77096006)(81166006)(33656002)(2900100001)(8936002); 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: multipart/alternative; boundary="_000_CY1PR09MB06347DD70ADE6990F1E79D8BEA1A0CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 01:34:06.2191 (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-04-21_01:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-status-unwanted-04 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, 21 Apr 2017 01:34:12 -0000 --_000_CY1PR09MB06347DD70ADE6990F1E79D8BEA1A0CY1PR09MB0634namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ben, More inline. - 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. This is based on the list discussion, so I'm not 100% sure, but my take is = along the lines you state: A forking proxy sends the robocall INVITE. One of the branches responds wit= h an 'unwanted', triggering the forking proxy to send a CANCEL with a Reaso= n header with the 'unwanted' status, so that the other UAs will know why th= e phone stopped ringing. (They might even show some appropriate indication = in the user interface, such as "You fool just jumped out of the shower to a= nswer a call about time share condos, but fortunately somebody else in your= household already hung up on the bozo." Or something like that.) I've tweaked the wording, but let me know if this needs to be split into se= parate cases. The response code MAY also be used as the value of the "cause" parameter of= a SIP reason-value in a Reason header field , ty= pically when the called party user agent issues a BYE request terminating a= n incoming call or a forking proxy issues a CANCEL request after receiving = a 607 response from one of the branches. -- 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. This is confusing since the paragraph talks about two different things, nam= ely the general behavior of SIP elements when dealing with flagged calls, a= nd the UI that may trigger the response. I'll break this into two paragraph= s. However, I'm struggling a bit to reword this since, even if the UA uses som= e local rules to auto-trigger an 'unwanted' response, the user experience i= s indeed the same as the spam button - something may happen, but the detail= s are left to the implementation. -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. There are actually companies that track service terminations for numbers (t= hey get lists from the major mobile providers), as that matters for making = sure that any consent the previous holder of the number gave to be called i= s still valid. There have been court cases where a utility called a delinqu= ent customer repeatedly - except the number of that customer had been re-as= signed to some unlucky new person. This is obviously far beyond the scope o= f the draft, but I'll try to elaborate a bit. --_000_CY1PR09MB06347DD70ADE6990F1E79D8BEA1A0CY1PR09MB0634namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ben,


More inline.


- Substan= tive Comments:

-- sectio= n 4, first paragraph:

I'm strug= gling 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 f= orking 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 c= ase might be helpful.

This is based on the list discussion, so I'm not 100% sure,= but my take is along the lines you state:

A forking proxy sends the robocall INVITE. One of the = branches responds with an 'unwanted', triggering the forking proxy to send = a CANCEL with a Reason header with the 'unwanted' status, so that the other UAs will know why the phone stopped r= inging. (They might even show some appropriate indication in the user inter= face, such as "You fool just jumped out of the shower to answer a call= about time share condos, but fortunately somebody else in your household already hung up on the bozo." Or some= thing like that.)

I've tweaked the wording, but let me know if this need= s to be split into separate cases.

The response c= ode MAY also be used as the value of the "cause" parameter of a S= IP reason-value in a Reason header field <xref target=3D"= ;RFC3326"/>, typically when the called party user agent issues a BYE request terminatin= g an incoming call or a forking proxy issues a CANCEL request after receivi= ng a 607 response from one of the branches. 

-- Sectio= n 4, paragraph 3:
There's s= ome imprecision in whether explicit user action is expected
when deci= ding 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 dec= ide 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.

This is confusing since the paragraph talks = about two different things, namely the general behavior of SIP elements whe= n dealing with flagged calls, and the UI that may trigger the response. I'll break this into two paragraphs.=

However, I= 'm struggling a bit to reword this since, even if the UA uses some local ru= les to auto-trigger an 'unwanted' response, the user experience is indeed the same as the spam button - something may = happen, but the details are left to the implementation.


-6, 3rd p= aragraph from end:
How can o= ne reasonably know that an identity has been reassigned? I can
see the c= ase 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 o= f email, I wonder if there's any useful advice to give here.

There are actually companies that track service termination= s for numbers (they get lists from the major mobile providers), as that mat= ters for making sure that any consent the previous holder of the number gave to be called is still valid. There = have been court cases where a utility called a delinquent customer repeated= ly - except the number of that customer had been re-assigned to some unluck= y new person. This is obviously far beyond the scope of the draft, but I'll try to elaborate a bit.=


--_000_CY1PR09MB06347DD70ADE6990F1E79D8BEA1A0CY1PR09MB0634namp_-- From nobody Thu Apr 20 18:39:05 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 B784B1293EC; Thu, 20 Apr 2017 18:39:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149273874370.22236.10629947769781911054@ietfa.amsl.com> Date: Thu, 20 Apr 2017 18:39:03 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-05.txt 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: Fri, 21 Apr 2017 01:39:04 -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-05.txt Pages : 8 Date : 2017-04-20 Abstract: This document defines the 607 (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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-05 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-status-unwanted-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-status-unwanted-05 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 Thu Apr 20 23:46:11 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 62D93129462 for ; Thu, 20 Apr 2017 23:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.109 X-Spam-Level: X-Spam-Status: No, score=-4.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=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, 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=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 MHuH4kPgbjeu for ; Thu, 20 Apr 2017 23:46:07 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 F18BE129457 for ; Thu, 20 Apr 2017 23:46:06 -0700 (PDT) X-AuditID: c1b4fb3a-baef298000005492-f2-58f9aaad9633 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id EA.D2.21650.CAAA9F85; Fri, 21 Apr 2017 08:46:05 +0200 (CEST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 21 Apr 2017 08:46:04 +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=qbHk/c/oZjTX0uX1u6OSRv0cdX3c3SYyBL5QGwC8964=; b=Y/OTg1yNrkZl76Yd9o+ITXdNB4yboRczZiSK57R2tkMPID1jUafndC5jBOeAi72XtXmvbDM3iQapYl5pL6Pd/zeLlk8MmvSXWku94djpAQtW9W3cPLQTJ/OuXuBg9CssrrQhlGR/GCUiIvxE/xve2HpOPMQN+CvGaszgfL/gdSE= Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) by AM5PR0701MB2465.eurprd07.prod.outlook.com (10.169.153.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Fri, 21 Apr 2017 06:46:03 +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.1061.007; Fri, 21 Apr 2017 06:46:03 +0000 From: Ivo Sedlacek To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-content-id-01 Thread-Index: AQHSugF/2SRrl2rmbEy4SIhztfbLoqHOrn8AgACyvCA= Date: Fri, 21 Apr 2017 06:46:03 +0000 Message-ID: References: <877f2f0x18.fsf@hobgoblin.ariadne.com> <8787b197-44e9-3602-4771-4dec432e8d72@comcast.net> In-Reply-To: <8787b197-44e9-3602-4771-4dec432e8d72@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: comcast.net; dkim=none (message not signed) header.d=none;comcast.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [193.179.210.162] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2465; 7:9aAmyjW8K8Fwli1umBMFTiS5XldOL2GvIIow0nUlTi52pJw0LcnokSmBGF1XQ275VFyhKwkG5QZKpG0oHgmYPe6z1coUjohmKInSODoBbJ9UFZmB2qmwv+gn0w7ayww8ar2mJYIeHjAHDF9b2Z9zS4Jya/OENV6E07vcaEmgiq6nmD0tBShsttQz2uSi5No+WZG+f3fydcVMIXtsjdzhBM3QNyfHrBQJIcmv9LoyziQzoW0Of5Q03En+tbCov//Qh2GC72cEiwPMt7U0GdMca64grvjimm68KLuaTc82huT0n5e8/TtPOLSQIvN9u0CSo3swypXcnB5Efq6Mjrt8iw== x-ms-office365-filtering-correlation-id: a7a2f8dd-c566-4005-502d-08d488821452 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM5PR0701MB2465; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:AM5PR0701MB2465; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2465; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39850400002)(39400400002)(39450400003)(39840400002)(39860400002)(5660300001)(53936002)(8936002)(66066001)(2900100001)(99286003)(55016002)(8666007)(102836003)(122556002)(81166006)(8676002)(3846002)(54356999)(6116002)(50986999)(189998001)(6246003)(5890100001)(33656002)(2501003)(25786009)(76176999)(99936001)(38730400002)(3280700002)(561944003)(6436002)(86362001)(77096006)(74316002)(7736002)(7696004)(2950100002)(230783001)(3660700001)(2906002)(6506006)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2465; H:AM5PR0701MB2468.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_AM5PR0701MB2468D1DAA7723B3E0B863616E51A0AM5PR0701MB2468_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 06:46:03.3666 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2465 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Tf0xTVxTHd+/70Qex5q4tcNIRF6uLripOZzI1i3M/3Fj2w2UhSFyi1vEm zbC4PuZw848uzG0Qu0CFdTxAqyILKsjqEwQExi9/FCcdbksgGpmIzHWJ4rK2aGR77926+N/n nO/53nvueecJjOmOwSo4XYWi2+XIt/HJbFVO67oljUenc54ZriMrx+JefuU/8SC/FmfuG69B mXV10/gdvDH5+Vwx37lTdC9dsyU5b7J4EO844UdFzUMHOQ+a/BKVoiQByAqI1LcYSlGyYCIn EHTVdWIanEfwY/s9RgtY4mVgNNrBUKUaw235cCK4iOBMU0g/jCcZUK70cxpbSBa0Tg+oLAhm 8jK0DHxC06/A/m5FT1vIaugY+UBLs+Qp8A1UsRobyRYITUX1E01kG8zELhk0TiIvQEzxYo0R SYVY6LjODEmD0RsHMH2OBX7/eZCnnAK3xmc4rU1EyhFcvnaNocI8UHy39f6BfMNAQ8TLUuEt aGmY5qigOvzhbxNCARxq+CvBdvi6X8a0aAxDY5+X0Z4DJB0mpzYnzBwM1k7ofZiJFa7+UoIo p8MfVzo52rcTOv0VhjK0QH7kGfIjkqyP43G4UHWDpfnFEOi4y1NeBPUHIwzldDhZWYJk9W6G 7EEQv3qEk+knxTDmDzM0qMDQtrdNt5hIJQZP71YqnMfwhVJmoIEq9IQmEpZmBPJMF6KWIxiG R96lvA9BQ42TFjWpw71+hqfBZdXxXXci+EG95Kcew/9nBYd8HPWfU8dbm06FGgzBrzwJyyCC P0dl/caHCyXrm/M0fB89pc/ETF6DvmMTPM1nwvCD31jK2XAp0o1ojR1qzxbr9SyZD5Vt9VhO rFe//x6mXUQxlLZnaTyLrILPz/qZAFp/FKVIoiRt37Z8eYbodr4vSQWuDJdYGETqv9ej3F99 GvVMvtiLiIBss4xjXfEcE+fYKe3a3ovmq/O/3nwsjKysq8Al2ixGb6sqG3Mduz4V3QWb3R/n i1IvekJgbWnGtV3hHHXDHYXih6K4Q3Q/VLGQZPUgZ2zkQeilx9oW2odmBz56I/9fX82bG+xZ 2St2d/89VxnZ8/b+9jT7k9VXqudxsyum4o0HsqVfUwvXlb767M2yOZ73uMh4gJ+zJjUWzLvv S7lZfs64qm9xa0okZL5YnDu0VJm7cZMtlBltCuPnTgaK7uxeuMi012ouuXvLA0uUos8sr9tY Kc+xzM64Jcd/61vVyoMEAAA= Archived-At: Subject: Re: [sipcore] Comments on 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: Fri, 21 Apr 2017 06:46:09 -0000 --_002_AM5PR0701MB2468D1DAA7723B3E0B863616E51A0AM5PR0701MB2468_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, > I still think it is simpler to think of the entire sip message, with the = exception of the Request-Line and Status-Line, as a mime message, with all = the uniquely sip message-headers simply being mime extension headers. Then = all these nomenclature issues go away. I commented on this proposal already - see response to Comment-3 in the att= ached mail. Kind regards Ivo Sedlacek --_002_AM5PR0701MB2468D1DAA7723B3E0B863616E51A0AM5PR0701MB2468_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Fri, 21 Apr 2017 06:46:02 GMT"; modification-date="Fri, 21 Apr 2017 06:46:02 GMT" Received: from DB6PR0701MB2472.eurprd07.prod.outlook.com (10.168.76.8) 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 via Mailbox Transport; Wed, 1 Mar 2017 08:22:12 +0000 Received: from VI1PR07MB1087.eurprd07.prod.outlook.com (10.163.168.23) by DB6PR0701MB2472.eurprd07.prod.outlook.com (10.168.76.8) 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:22:12 +0000 Received: from VI1PR07CA0007.eurprd07.prod.outlook.com (10.163.160.145) by VI1PR07MB1087.eurprd07.prod.outlook.com (10.163.168.23) 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:22:10 +0000 Received: from AM5EUR02FT055.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::209) by VI1PR07CA0007.outlook.office365.com (2a01:111:e400:533d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2 via Frontend Transport; Wed, 1 Mar 2017 08:22:11 +0000 Received: from oa.msg.ericsson.com (192.176.1.74) by AM5EUR02FT055.mail.protection.outlook.com (10.152.9.191) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.933.11 via Frontend Transport; Wed, 1 Mar 2017 08:22:10 +0000 Received: from sesbmg14.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.88) with Microsoft SMTP Server id 14.3.319.2; Wed, 1 Mar 2017 09:21:42 +0100 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by sesbmg14.ericsson.net (Symantec Mail Security) with SMTP id 66.7E.04614.69486B85; Wed, 1 Mar 2017 09:21:42 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFC21294CD; Wed, 1 Mar 2017 00:21:40 -0800 (PST) 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) 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) 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 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" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-content-id-00.txt Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-content-id-00.txt Thread-Index: AQHSe0i3OcxEApvMsUa8nZTAZChHJKFTOfcAgAIsEpCAAIkmgIABR2kAgABbb4CAKD0EgA== Sender: sipcore 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> List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthSource: ESESSHC023.ericsson.se X-MS-Has-Attach: yes X-Auto-Response-Suppress: All X-MS-Exchange-Organization-Network-Message-Id: 322073cc-365d-4ab8-d802-08d4607c0ed1 X-MS-TNEF-Correlator: x-originating-ip: [193.179.210.162] authentication-results: symauth.service.identifier x-auditid: c1b4fb3c-b89ff70000001206-73-58b684955236 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== received-spf: Fail (protection.outlook.com: domain of ietf.org does not designate 192.176.1.74 as permitted sender) receiver=protection.outlook.com; client-ip=192.176.1.74; helo=oa.msg.ericsson.com; x-virus-scanned: amavisd-new at amsl.com 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= errors-to: sipcore-bounces@ietf.org list-archive: x-mailman-version: 2.1.17 list-post: x-beenthere: sipcore@ietf.org list-id: SIP Core Working Group x-spam-flag: NO 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 x-spam-score: -4.219 x-spam-level: delivered-to: sipcore@ietfa.amsl.com x-original-to: sipcore@ietfa.amsl.com X-Microsoft-Exchange-Diagnostics: 1;AM5PR0701MB2468;27:JmHQt2YEdELhEkPB6YRFlJ2wNTGr0xVoiOD0Rm9T4tlpCT17FKEYCAglTUHtcoDeUE7ssbhNW3Exa9sqmtFPrlU2/AMBAXF+4tlX0AIvSLAYFJgFtanGlRQMF1E/lb0siS9jh/ZWPxMmsoqylRu2bg== Content-Type: multipart/mixed; boundary="_004_AM5PR0701MB24686B27CFE00E14E97D20FAE5290AM5PR0701MB2468_" MIME-Version: 1.0 --_004_AM5PR0701MB24686B27CFE00E14E97D20FAE5290AM5PR0701MB2468_ X-Microsoft-Exchange-Diagnostics: 1;AM5PR0701MB2468;27:JmHQt2YEdELhEkPB6YRFlJ2wNTGr0xVoiOD0Rm9T4tlpCT17FKEYCAglTUHtcoDeUE7ssbhNW3Exa9sqmtFPrlU2/AMBAXF+4tlX0AIvSLAYFJgFtanGlRQMF1E/lb0siS9jh/ZWPxMmsoqylRu2bg== Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB24686B27CFE00E14E97D20FAE5290AM5PR0701MB2468_" --_000_AM5PR0701MB24686B27CFE00E14E97D20FAE5290AM5PR0701MB2468_ X-Microsoft-Exchange-Diagnostics: 1;AM5PR0701MB2468;27:JmHQt2YEdELhEkPB6YRFlJ2wNTGr0xVoiOD0Rm9T4tlpCT17FKEYCAglTUHtcoDeUE7ssbhNW3Exa9sqmtFPrlU2/AMBAXF+4tlX0AIvSLAYFJgFtanGlRQMF1E/lb0siS9jh/ZWPxMmsoqylRu2bg== 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_ X-Microsoft-Exchange-Diagnostics: 1;AM5PR0701MB2468;27:JmHQt2YEdELhEkPB6YRFlJ2wNTGr0xVoiOD0Rm9T4tlpCT17FKEYCAglTUHtcoDeUE7ssbhNW3Exa9sqmtFPrlU2/AMBAXF+4tlX0AIvSLAYFJgFtanGlRQMF1E/lb0siS9jh/ZWPxMmsoqylRu2bg== Content-Type: text/html; charset="us-ascii" Content-ID: <0A3642BFA93F854EAB757DE6E2650F36@eurprd07.prod.outlook.com> 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_-- --_004_AM5PR0701MB24686B27CFE00E14E97D20FAE5290AM5PR0701MB2468_ X-Microsoft-Exchange-Diagnostics: 1;AM5PR0701MB2468;27:JmHQt2YEdELhEkPB6YRFlJ2wNTGr0xVoiOD0Rm9T4tlpCT17FKEYCAglTUHtcoDeUE7ssbhNW3Exa9sqmtFPrlU2/AMBAXF+4tlX0AIvSLAYFJgFtanGlRQMF1E/lb0siS9jh/ZWPxMmsoqylRu2bg== Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=136; creation-date="Wed, 01 Mar 2017 08:22:12 GMT"; modification-date="Wed, 01 Mar 2017 08:22:12 GMT" Content-ID: <8A1B59C1BFCAC14B890DB69095838635@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUg bWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== --_004_AM5PR0701MB24686B27CFE00E14E97D20FAE5290AM5PR0701MB2468_-- --_002_AM5PR0701MB2468D1DAA7723B3E0B863616E51A0AM5PR0701MB2468_-- From nobody Fri Apr 21 00:01:13 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 D779D129412 for ; Fri, 21 Apr 2017 00:01:10 -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 WA_30eifhaOV for ; Fri, 21 Apr 2017 00:01:09 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 C9FCA12869B for ; Fri, 21 Apr 2017 00:01:08 -0700 (PDT) X-AuditID: c1b4fb3a-baef298000005492-69-58f9ae32cf41 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 10.66.21650.23EA9F85; Fri, 21 Apr 2017 09:01:07 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0339.000; Fri, 21 Apr 2017 09:01:05 +0200 From: Christer Holmberg To: Ivo Sedlacek , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-content-id-01 Thread-Index: AQHSugF/PN3A4rAB+kOqJk8KIGFSSqHOjPgAgACzYYCAADe+AA== Date: Fri, 21 Apr 2017 07:01:04 +0000 Message-ID: References: <877f2f0x18.fsf@hobgoblin.ariadne.com> <8787b197-44e9-3602-4771-4dec432e8d72@comcast.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7B6AB4177012E64383B624024B7FC321@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7iq7xup8RBgdmclo8+NHLZvH1xyY2 ByaPyY/nMHosWfKTKYApissmJTUnsyy1SN8ugStj48ST7AW9bBXLJnxgb2B8w9LFyMEhIWAi se90cRcjF4eQwHpGiUltl1ghnCWMEju3fmUGKWITsJDo/qfdxcjJISJQJ3Hn2D5WEFtYwFni SNtzZoi4i8S8/VtYIWwniY4Z99lAbBYBVYm2hafZQWxeAWuJ/kt7mSDm72OUeHnnCyPIfE6B RIlbewpBahgFxCS+n1rDBGIzC4hL3HoyH8yWEBCQWLLnPDOELSrx8vE/sF2iAnoS+/59ZYOI K0pcnb4cqldP4sbUKWwQtrXEz2lvoeLaEssWvmaGuEdQ4uTMJywTGMVmIVk3C0n7LCTts5C0 z0LSvoCRdRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYFQd3PLbagfjweeOhxgFOBiVeHgf 7PsRIcSaWFZcmXuIUYKDWUmEt3c7UIg3JbGyKrUoP76oNCe1+BCjNAeLkjivw74LEUIC6Ykl qdmpqQWpRTBZJg5OqQbGtZbu+WsZz7r0VjrOEnQP+ng3vPjPyq634qsDNS/95pk5/bWfR6Gc X/qbuiLLF80KG2ct5vtm97Xx0lKJBWa39kev+C8sfP9q0QJv7xOpXc+PzaruFll0rKTkclNy Z8XZHX9bCyJStdK35IpfFpTg1jhy86Dx5fJY1QLnSxYHw95qL3+1aKOrEktxRqKhFnNRcSIA CWXgUKYCAAA= Archived-At: Subject: Re: [sipcore] Comments on 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: Fri, 21 Apr 2017 07:01:11 -0000 Hi, I REALLY don=B9t think we shall make this more complicated than it has to be. Let=B9s leave that for 3261bis... The purpose of the work is to register Content-ID as a SIP header field. Regards, Christer On 21/04/17 09:46, "sipcore on behalf of Ivo Sedlacek" wrote: >Hello, > >> I still think it is simpler to think of the entire sip message, with >>the exception of the Request-Line and Status-Line, as a mime message, >>with all the uniquely sip message-headers simply being mime extension >>headers. Then all these nomenclature issues go away. > >I commented on this proposal already - see response to Comment-3 in the >attached mail. > >Kind regards > >Ivo Sedlacek > From nobody Fri Apr 21 00:16: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 BF1DA129482 for ; Fri, 21 Apr 2017 00:16:34 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 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 DJmT3gp6ZiSM for ; Fri, 21 Apr 2017 00:16:33 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 5C47C12946A for ; Fri, 21 Apr 2017 00:16:31 -0700 (PDT) X-AuditID: c1b4fb2d-c616898000004c5d-eb-58f9b1cd2286 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 0E.6B.19549.DC1B9F85; Fri, 21 Apr 2017 09:16:29 +0200 (CEST) Received: from EUR02-AM5-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.339.0; Fri, 21 Apr 2017 09:16:29 +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=jEQtIbs7ATrbPcS7TVkfaPAEBPnCsN2gq3npJUJVluk=; b=A6CxIKeFWdVGwZirTWHMfzPQBRmTTjAk/1TnKBDUX7vm7169MM1LFm5jLFO10qKjUQNxWnpFoDsO0FMPEe31r8RlCxgzgR+jnie3STkPXJxhjlSO5Ms3HwhSW9E01Tx3+ITuxIYDH+fV1Mkv7I6+sXFiln0owcH1xBFet6iOabA= Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) by AM5PR0701MB2467.eurprd07.prod.outlook.com (10.169.153.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Fri, 21 Apr 2017 07:16:28 +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.1061.007; Fri, 21 Apr 2017 07:16:28 +0000 From: Ivo Sedlacek To: "Dale R. Worley" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-content-id-01 Thread-Index: AQHSugF/2SRrl2rmbEy4SIhztfbLoqHPYfAQ Date: Fri, 21 Apr 2017 07:16:28 +0000 Message-ID: References: (ivo.sedlacek@ericsson.com) <877f2f0x18.fsf@hobgoblin.ariadne.com> In-Reply-To: <877f2f0x18.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ariadne.com; dkim=none (message not signed) header.d=none;ariadne.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [193.179.210.162] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2467; 7:gN7s3KRvlZwbYLO6LIaNJbF/lGKWWoWMxdAUfxp8A5PHEUfAN+bPuvnBgytnpRHoCGl8hO77aOLoKhg3qLIie01RfTuSjJMdYaW554yfTXa7LYM2CsJ5ZGNKKJJw5CdW37wWsdaaxDP1wb+QddvSwZ4BtuyMNICtPbNNZFqof2ZOiV45UGq8RwHix8nJ/rX5JyIcMgpAUKFr26PQ21Nh0hygpWTZt96eE3d1r/ZbKCz9cCUEcq3PAa5P5KJJ741zMPXWji/6KJE3B9uIo3UeAr8MZG13RbFpmlM6+i0PP6cUFyPKhPI1+G4KsuQlJetsC08E3+kw2Fy57XSGKOajTw== x-ms-office365-filtering-correlation-id: 69203c6e-d9e6-4dbc-c413-08d488865402 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2467; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123562025)(20161123558048)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406101)(6072148); SRVR:AM5PR0701MB2467; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2467; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39840400002)(39860400002)(39850400002)(39450400003)(39410400002)(54356999)(76176999)(50986999)(38730400002)(66066001)(81166006)(8676002)(74316002)(3280700002)(7736002)(3846002)(6116002)(102836003)(305945005)(3660700001)(6916009)(2906002)(2950100002)(230783001)(5660300001)(110136004)(2900100001)(4326008)(122556002)(25786009)(7696004)(6246003)(6436002)(33656002)(8936002)(53936002)(55016002)(189998001)(6506006)(77096006)(99286003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2467; H:AM5PR0701MB2468.eurprd07.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-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 07:16:28.1204 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2467 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee69s+to8Ph+Wia0GKHlMu3FSEpJSsGoD0LiFx1506FusmtL y0iFYplGFpWuUIuZlIo1RybpxDHJhmaiGYxCMvEly6VmTYba7h6Dvv3O//8/nHMeHpb2LxdJ WZW6kNOqlXkyHzFTm9ZxNHLwxUpaVO/H/bHLLpNP7Gy/Lp5KutOzTCcZjSvUaSpdHJfF5al0 nHbPkUxxjntplS6YkhT9HLYwpWhcXIF8WcD7YLj2HS2wP25DMO84V4HEHu5H0NfUJRIKBlfR MORsEhGnjoKR8ns0KQYQ1JTZGKHfByug2mzzpFg2EIeDviFPkGkPTnR2U4IcgI/By74LghyI E6GuxywiHA1lU2OMEGGwHBa6QZAlOBMmZlo3kUmNCFzGZW/GF8fA/bUiIYNwMPyxt1BkUgg4 JuspchgGY9cQTTgIZr+uiUi+GoGjLIroO8B82+m9BPBNGlxdjQwxTkLbiJ4hRimC6bvNm4ih gTrr940JEaC3GSgS+k1Bv/OH90jAoTC9kEF0NwNrgy4kNARgKXwevb7BoTDzqVt0C4Ub/tuc 8G5oeL3oQ3gXPHk0Rxu8r+EHb2snmQbEPENBPMfz+dnRMQpOqzrL8xq1Qs0VmpDnZ/Sa3ZGv UPNcghVhFsk2S75YXGn+IqWOL863ImBpWaCkqsMjSbKUxRc5rSZDez6P461oK8vIQiTxlvdp /jhbWcjlclwBp/3nUqyvtBRFBYct/nojP5OSqPFDh8u3XKlcUm2TB6Lt7KrdOlsUkPLBJo3S h+osrQcfto2mh1WaV3cuJbfI21OX5gtye67NuTplsvWSA/YTCTeuBplMGveqzP748kzJ4KGn qe3Vp2wa90C+03SJCV7PQfXj48lxivoHjnxDjXyMPq54/k3G8DnKvRG0llf+BR6ecakVAwAA Archived-At: Subject: Re: [sipcore] Comments on 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: Fri, 21 Apr 2017 07:16:35 -0000 Hello, > > 2) in other places, I rather talk about "content" where the "content" > > can be carried in (a) a body part of multipart body, or (b) in=20 > > non-multipart body. >=20 > Well... What exactly do you want the term to mean? =20 By content, I intend to refer to a pieces of information.=20 One example of the content is an XML text of application/pidf+xml MIME type= . Another example of the content is a JPEG picture. Another example of the content is an unstructed text. The content can be transported by SIP (using various methods, as indicated = by you below), can be transported by other protocol (e.g. HTTP), or e.g. ca= n be stored in a file in a computer. > I mean, there are three=20 > things I can name off the top of my head: > - the body of the SIP message > - a body part which is not itself a multipart > - a body part which is part of a multipart The above are several methods how to transport the content in SIP. > Given that parts of multiparts can themselves be multiparts, there are bo= dy=20 > parts that are examples for most of the eight possible true/false=20 > combinations of these properties. >=20 > As far as I know, there's no (interesting) statement one can make which=20 > requires an "A or B" description of its subject -- as long as you careful= ly=20 > think through what it is that you mean, and choose a phrase that accurate= ly=20 > describes it. >=20 > In your example, I suspect that you use "content" to mean "a body part wh= ich=20 > is not itself a multipart" (since the whole body is itself a body part). No.=20 The content is a piece of information. The body part which is not itself a multipart is a method to transport the = content. Kind regards Ivo From nobody Fri Apr 21 00:42: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 78954129494 for ; Fri, 21 Apr 2017 00:42:36 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 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 56MoKuPzrwBH for ; Fri, 21 Apr 2017 00:42:35 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 A0C0012948E for ; Fri, 21 Apr 2017 00:42:34 -0700 (PDT) X-AuditID: c1b4fb2d-c616898000004c5d-70-58f9b7e8e52f Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 93.51.19549.8E7B9F85; Fri, 21 Apr 2017 09:42:32 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 21 Apr 2017 09:42:31 +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=70nN57xAvkG1XJCuynBSiQtlkBOfRggHyFzhpf7AfIs=; b=ToPnkaFj+3MW2GjdZ59dlULILxh6934Iob+cr2y+A+AYORtm50/N5FgOgIOcSPut6KpwVTBrI/1UQqoHoRStbcdWyarRzdVH+3+L13yGpZwnL0Bvc0MQSrs2IlHmRtzvH9gIRPiGzWUo791ERswCRAy39Ur2ZE+M9lRlSCT3TaU= Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) by AM5PR0701MB2467.eurprd07.prod.outlook.com (10.169.153.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Fri, 21 Apr 2017 07:42:30 +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.1061.007; Fri, 21 Apr 2017 07:42:30 +0000 From: Ivo Sedlacek To: Randall Gellens , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-content-id-01 Thread-Index: AQHSuf0zK3SThPx5YkqkaIU+nwgwvaHPa6xw Date: Fri, 21 Apr 2017 07:42:30 +0000 Message-ID: References: <87shlgndaj.fsf@hobgoblin.ariadne.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: randy.pensive.org; dkim=none (message not signed) header.d=none;randy.pensive.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [193.179.210.162] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2467; 7:PCWLxnQNx4VFTKQfgNVMwCGZk6uIpCs20Dwg3Q5jS7iPSD/P8j9YCHGQxIIz9a9d2ZhB6d79GMWsftNU2gIfBsPtkrBIy7nlj43HZmJh2ZUczmSt/eJJJ5v4vXDJQgaKn4rHFEK4WvjMgxeWMIPtgrDEDy9thb5IxCA531Eyj9r4HnrSaaBh4nRTnJpxNuhCFkzx5OYsqVP3JKnExL+AoIYeVYZu6yPkVxtp0rWZj2ehBlJ/t5cCMjKupH+jXZk1B64xZj/P1co0oHv9ZO9kPeWT+krMjWcrS+06owcEeywccVV5YjJykn910z0Xi0tX9VTtIoH2Fs+SlIRbY/TjDA== x-ms-office365-filtering-correlation-id: 43518589-91fa-4d3f-c84a-08d48889f75c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2467; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123562025)(20161123558048)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406101)(6072148); SRVR:AM5PR0701MB2467; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2467; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39860400002)(39840400002)(39850400002)(39450400003)(39410400002)(52314003)(54356999)(76176999)(50986999)(38730400002)(66066001)(81166006)(8676002)(74316002)(3280700002)(7736002)(3846002)(6116002)(102836003)(345774005)(305945005)(3660700001)(2906002)(2950100002)(230783001)(5660300001)(2900100001)(122556002)(25786009)(7696004)(6246003)(2501003)(6436002)(33656002)(8936002)(53936002)(55016002)(6506006)(189998001)(77096006)(99286003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2467; H:AM5PR0701MB2468.eurprd07.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-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 07:42:30.6801 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2467 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGO/febXfLC6fl9MUWxCKK/MivcEXF+isxBDGiJYKOvKipU3dV UopEE2nptEJIhVyhSWlFfrREc7hE/ET/KIlhiWhstVIMP2amtO0Y+N/vfZ73PLwPHJaWl4mC 2Ex9AW/Q67JVYhlTr7WcCnVaNrThxhm1et1hROpVd4dYQ8U2N29Qsd0z80wClSQ7k8ZnZxbx hhPnUmUZ2+NrorxXwTfufLKiUrR1yIikLOBoGKp9wxiRjJXj1wimn7dTZBhGYJ9aEXsHBlfT sNX/gSbOYwpml60i73s5HkfQMhjuZTEOg/tdgz7dH2vBtfqN8fJ+HAOOqikJ0dXwY2jIwxIP R8K03Ksy+AjM1g144lmWw6lgrzhKwpPh88BDX6DUc2jNossXgnAArI9675SyNA4E+0ITRcpg aO6bpAkr4Pv8tojsNyGoGUsg+mHoerC0s2OiYazyLOF4qB0c8XUHXIrAUdcmIUYurNkXdx6c BnezWUKW1igYXvpFeY8GrATHcgrR/zLQN2emSfUg+PLxLiKsBOfMexG5OgTMvb/FtehYw64S DbsswsHw7ImL9jKH98FI/QJjRswLpBB4QchJj4wK4w2Z1wQhVx+m5ws6kOdnDHRthr5Dba7z NoRZpPLj5vrdWrlIVyQU59gQsLTKn6u2eCQuTVdcwhtyUwyF2bxgQwdYRhXIafqntHKcrivg s3g+jzf8dylWGlSKGkNKLMl++W2MqWc6cfPKy8kV5dvC208rW50XO9dLGjXcaM3E5YWoMLui XGnpnJDOOSfbWjWJVxm9yV0htyY+Sv3zs+e6OOBSXKBtwTQbreik5i+U9Vbd1GRlxheVRLSk KvNPxvFxt6pGYmTdrSvt1qS99w5ml3/lLm9Mdi/uUTFChi7iOG0QdP8A7OVtWhUDAAA= Archived-At: Subject: Re: [sipcore] 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: Fri, 21 Apr 2017 07:42:36 -0000 Hello, thank you for the review and let me respond to your comments. > (1) Section 1.1 seems overly complex: > However, when the message-body of the SIP message contains one body > only, there is no body part specified. Thus, there is also no > defined method how to convey an ID value uniquely identifying the > body part. >=20 > Perhaps: > However, when the message-body of the SIP message is not a multipart, > there is no way to convey an ID value identifying the body part. The original text identified two problems (Problem-1, Problem-2) while the = text identifies only one (Problem-2). Problem-1: RFC2045 defines a body part as follows.=20 ---------------- The term "body part" refers to an entity inside of a multipart entity. ---------------- Thus, today, by definition, message-body which is not multipart is not a b= ody part.=20 Problem-2: there is no way to refer from a SIP header field to a message-bo= dy which is not multipart. Anyway, the text above has already been updated in the proposed new version= of the draft shared yesterday. Does the updated version resolve the commen= t? > (2) Section 1.3 seems overly complex: > Since the Content-ID header field is not a defined SIP header field: >=20 > o If solely one body needs to be transported in a SIP message and > the UAC does not need to include in the SIP message a SIP header > field referencing the body part, then the UAC sets the message- > body to the body. > o However, if solely one body needs to be transported in a SIP > message and the UAC needs to include in the SIP message a SIP > header field referencing the body part, then the UAC sets the > message-body to be of the "multipart" MIME type and includes one > body part and associated Content-ID header field. >=20 > Perhaps: > Since the Content-ID header field is not a defined SIP header field, > it is not possible to reference a unitary or the top-level body part. > In cases where only a single part part is included and needs to be > referenced, it must be wrapped in an otherwise unnecessary > multipart/mixed. RFC2045 defines body part as follows: ---------------- The term "body part" refers to an entity inside of a multipart entity. ---------------- So, given the definition above, "a unitary or the top-level body part" cann= ot exist. Again, the text above has already been updated in the proposed new version = of the draft shared yesterday. Does the updated version resolve the comment= ? > (3) Section 1.4.1 seems overly complex: > the UAC needs to include a message-body of "multipart/mixed" MIME > type in the INVITE request, and the UAC needs to include a body part > of the application/pidf+xml MIME type and associated Content-ID > header field in the message-body of the "multipart/mixed" MIME type. >=20 > Perhaps: > the UAC needs to wrap the application/pidf+xml body part in a > multipart/mixed MIME media type, in order to be able to have a > Content-ID header field referencing the application/pidf+xml. Is there a formal definition of wrapping a body part to a multipart/mixed M= IME media type? Based on Dale's suggestion, I updated the text to: ------------- the UAC needs to set the message-body of the INVITE request to a multipart body, and the UAC needs to include a body part with a content of the application/pidf+xml MIME type and with an associated Content-ID header field in the multipart body. ------------- Does this resolve the comment? > (4) Section 1.4.2 seems overly complex: > UAC needs to include a message-body of the "multipart/mixed" MIME > type in the REFER request and the UAC needs to include a body part of > the application/resource-lists+xml MIME type and associated Content- > ID header field in the message-body of the "multipart/mixed" MIME > type. >=20 > Perhaps: > the UAC needs to wrap the application/resource-lists+xml body part in > a multipart/mixed MIME media type, in order to be able to have a > Refer-To header field referencing the application/resource-lists+xml > body part. Same as for (3) above. > (5) Suggested text changes in Section 1.5: >=20 > OLD: > To avoid the unnecessary usage of a message-body of a "multipart" > MIME type when only one body needs to be included in a SIP message, > this document specifies a Content-ID header field as a SIP header > field. >=20 > The Content-ID header field included in header fields of a SIP > message identifies a body part consisting of the message-body of the > SIP message and: >=20 > NEW: > To avoid the need to unnecessary wrap a message body in a multipart M= IME > type, this document specifies the Content-ID header field as a SIP he= ader > field. >=20 > A Content-ID header field included in the header fields of a SIP mess= age > identifies a body part consisting of the message-body of the SIP mess= age and: I simplified it even more based on Dale's comment to state: --------------- 1.5. Solution The Content-ID header field included in the header fields of a SIP message identifies a body part consisting of the message-body of a SIP message and metadata provided by some additional SIP header fields. --------------- Kind regards Ivo Sedlacek From nobody Fri Apr 21 06:26: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 8336E126BF7 for ; Fri, 21 Apr 2017 06:26:33 -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 IHOl8u6rs4zf for ; Fri, 21 Apr 2017 06:26:31 -0700 (PDT) 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 8E016120454 for ; Fri, 21 Apr 2017 06:26:31 -0700 (PDT) X-AuditID: c1b4fb30-abffb70000006667-c6-58fa08856105 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id FE.C7.26215.5880AF85; Fri, 21 Apr 2017 15:26:29 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0339.000; Fri, 21 Apr 2017 15:26:29 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-content-id-01 Thread-Index: AQHSugF/PN3A4rAB+kOqJk8KIGFSSqHPSNgAgACa7IA= Date: Fri, 21 Apr 2017 13:26:28 +0000 Message-ID: References: <877f2f0x18.fsf@hobgoblin.ariadne.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <00B414D6B3B01D4797F1390676025FC1@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGbFdUbeV41eEwafP+hZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvyu7ewFLWIVzw5OZ29g3C/YxcjJISFgInFx7mLGLkYuDiGB 9YwSs5eeZYZwljBKXHjWCuRwcLAJWEh0/9MGaRAR0JRY/m0rO4gtLOAscaTtOTNE3EVi3v4t rBC2lcTG2W/B4iwCqhI/1swFi/MKWEu0tn5ngZj/gFHi2oUbTCAJToFEiXeN+8AaGAXEJL6f WgMWZxYQl7j1ZD4TxKUCEkv2nGeGsEUlXj7+BzZUVEBPYt+/r2wQcUWJq9OXQ/XqSdyYOoUN wraW2NL1nhHC1pZYtvA1M8RBghInZz5hmcAoNgvJullI2mchaZ+FpH0WkvYFjKyrGEWLU4uT ctONjPRSizKTi4vz8/TyUks2MQKj6OCW3wY7GF8+dzzEKMDBqMTD+2Dfjwgh1sSy4srcQ4wS HMxKIrzOn35GCPGmJFZWpRblxxeV5qQWH2KU5mBREud13HchQkggPbEkNTs1tSC1CCbLxMEp 1cBYd8Ny8/41U+dMU/Q9uV5pjm2d27MTGslb89exfNwYelJ9/bfEyjs/9po1bAqNiLusExq2 2+fNrUn8EYV3TxsudlxsMf3mPiaJFvkT3Vv5r4sxnu779plnyQRPz8Winb93GUStmTKNg/vv zFtVLpcyzqfbqfyTcRC+pSn2ufW2+W2HQ80W17a9UWIpzkg01GIuKk4EAOcYX5yeAgAA Archived-At: Subject: Re: [sipcore] Comments on 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: Fri, 21 Apr 2017 13:26:33 -0000 Hi, I=B9ve had a chat with Ivo, and we have updated the text in the pull reques= t. Most changes are in the Introduction, but some alignment changes have also been done elsewhere. The idea was to only use terminology already defined elsewhere. Note that we have added a =B3Update to RFC 2045 and RFC 5632=B2 section, wh= ere we still need to add some text, basically saying that the CID URL is can also be used with message-bodies (currently the RFCs only talk about body parts). We do NOT intend to make a OLD-TEXT-NEW-TEXT change, but simply add a statement. The XML changes, and TXT file based on the latest changes, can be seen here: https://github.com/cdh4u/draft-content-id/pull/3/files Regards Christer On 21/04/17 10:16, "sipcore on behalf of Ivo Sedlacek" wrote: >Hello, > >> > 2) in other places, I rather talk about "content" where the "content" >> > can be carried in (a) a body part of multipart body, or (b) in >> > non-multipart body. >>=20 >> Well... What exactly do you want the term to mean? > >By content, I intend to refer to a pieces of information. >One example of the content is an XML text of application/pidf+xml MIME >type. >Another example of the content is a JPEG picture. >Another example of the content is an unstructed text. > >The content can be transported by SIP (using various methods, as >indicated by you below), can be transported by other protocol (e.g. >HTTP), or e.g. can be stored in a file in a computer. > >> I mean, there are three >> things I can name off the top of my head: >> - the body of the SIP message >> - a body part which is not itself a multipart >> - a body part which is part of a multipart > >The above are several methods how to transport the content in SIP. > >> Given that parts of multiparts can themselves be multiparts, there are >>body=20 >> parts that are examples for most of the eight possible true/false >> combinations of these properties. >>=20 >> As far as I know, there's no (interesting) statement one can make which >> requires an "A or B" description of its subject -- as long as you >>carefully=20 >> think through what it is that you mean, and choose a phrase that >>accurately=20 >> describes it. >>=20 >> In your example, I suspect that you use "content" to mean "a body part >>which=20 >> is not itself a multipart" (since the whole body is itself a body part). > >No.=20 > >The content is a piece of information. >The body part which is not itself a multipart is a method to transport >the content. > >Kind regards > >Ivo > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Apr 21 11:32: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 DF55512EACB for ; Fri, 21 Apr 2017 11:32:26 -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 AyczpKt7LBWj for ; Fri, 21 Apr 2017 11:32:26 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 3B4DD127F0E for ; Fri, 21 Apr 2017 11:32:26 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-06v.sys.comcast.net with SMTP id 1dL6d90NKl4eq1dM1d88yX; Fri, 21 Apr 2017 18:32:25 +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 1dM0d3DPrngy31dM0dZdWZ; Fri, 21 Apr 2017 18:32: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 v3LIWNsp021536; Fri, 21 Apr 2017 14:32:23 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v3LIWN2j021533; Fri, 21 Apr 2017 14:32: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: Ivo Sedlacek Cc: paul.kyzivat@comcast.net, sipcore@ietf.org In-Reply-To: (ivo.sedlacek@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 21 Apr 2017 14:32:23 -0400 Message-ID: <87shl1y5l4.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfE7BLN8+crhrCAveJQLeBvo+AV7AUOD9dZ3KjCRI8GpMW8ushMIjqhSL2c81NypLZ/xmXbX+pmwRA5ecbty7hDJNIoav/nvqo0P/dUMa1Zfv4Etxx2AX OUcajruGBIZLEctoxpFnWNCOIELlbKKKMwYq1zNINfwOZE60Xnl3F/N0fX9LmadX7QT7XA94JrNSuupy22pvhJF+aOiMUViz5CLWhiqeaFNY9pVMXUYSE6y5 Archived-At: Subject: Re: [sipcore] Comments on 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: Fri, 21 Apr 2017 18:32:27 -0000 Ivo Sedlacek writes: > > 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: ... > - 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 from the > SIP "History-Info" header field. That's an interesting point, because we *do* need to ensure that nothing is registered as a "MIME header" that already exists as either an e-mail header, an HTTP header, or a SIP header. Dale From nobody Sat Apr 22 12:00: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 69812129B21 for ; Sat, 22 Apr 2017 12:00:17 -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 Fh3YYJmnSAeL for ; Sat, 22 Apr 2017 12:00:15 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 243B7129ADD for ; Sat, 22 Apr 2017 12:00:13 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-10v.sys.comcast.net with SMTP id 20GId17Qd61D920GSdl9DA; Sat, 22 Apr 2017 19:00:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1492887612; bh=xPP00oWcwK5ux8rUDrxQVTI0h4fvmSJ/M6Ycz+3o1lY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=aWNGITv9HmJWFg7i05jFTOLdSpo4BLlwYEfmyn356g+RT21BnSE/APc4LIUzIGcBa uIRwjy9+HoiSNIpkeKJqVfkannY3MHM702oV1j5vWwGWrJTLUVgHtvBupplYLfh9A3 qOQUzditsA417DfhhsUP6pia+pZhZZIiCcXHrTftSbtvt94sud063jQoC3Z/VIL4z7 PqDdjxsCIXsgj9FzRnbrSNMn6TCTATPAlff/7epHwMTRx0AaK4+nLUBn56MSf6smy4 bT6bjEO6lZvJ1b6I7xjp+Sf2B4r2ew3pw8voiwvOPp0qmjJrhkotPMGjumE5jRvASd P6EZkmPGoxKyQ== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-12v.sys.comcast.net with SMTP id 20GRdEhnzqoNE20GRdWlf2; Sat, 22 Apr 2017 19:00:12 +0000 To: Henning Schulzrinne References: <149273874370.22236.10629947769781911054@ietfa.amsl.com> From: Paul Kyzivat Cc: sipcore@ietf.org Message-ID: <45b9eaee-ccaa-89b1-80de-d3dd00023485@comcast.net> Date: Sat, 22 Apr 2017 15:00: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: <149273874370.22236.10629947769781911054@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfHYOHEgQav5Uur1dGXgl8wLe39iS66/VC7c0WkJ5YNUKg1I43FHx6LbXgPbeaxr8MaasxYDSvZtgEEC16a705Wwp/vXQypiK6xmZGezJhqIjh/vAzKgF Oiixd+6QzNCmPYqgbVLEgnOd8gNr88732Qt9OHNni23dQvsb/eaHe9FecCZ64AVMamjDM58J3e0BeuNd8BBGthJkDQ+1ASuB88s= Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-05.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, 22 Apr 2017 19:00:17 -0000 I find the following from section 4 to be a bit odd/confusing: Call handling for unwanted calls is likely to involve a combination of heuristics, analytics, and machine learning. These may use call characteristics such as call duration and call volumes for a particular caller, as well changes in those metrics over time, as well as user feedback. Implementations will have to make appropriate trade-offs between falsely labeling a caller as unwanted and delivering unwanted calls. Is this intending to discuss automated behavior of the called party UA, or behavior of the called party, or something else? ISTM that "heuristics, analytics, and machine learning" are more likely to be applied by a middle box than the called UA. In a middle box those will be used to trigger coding per the callinfo-spam draft, which is outside the scope of this document. Presumably the called UA may use some techniques to decide to automatically generate a 607 response. The most likely I can think of is for it to remember a 607 was previously generated for this caller and to repeat it automatically for future calls from the same caller. Perhaps simply changing "Call handling for unwanted calls" to "Automatic recognition of unwanted calls". But that may be too simplistic. Otherwise this version seems good to me. Thanks, Paul From nobody Sat Apr 22 15:20: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 3B29412702E for ; Sat, 22 Apr 2017 15:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-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 l9-HVT9YpkAN for ; Sat, 22 Apr 2017 15:20:00 -0700 (PDT) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (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 B332D126C0F for ; Sat, 22 Apr 2017 15:20:00 -0700 (PDT) Received: from pps.filterd (m0102172.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3MMJs0g001313; Sat, 22 Apr 2017 22:19:54 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0020.outbound.protection.outlook.com [23.103.198.20]) by mx0a-0024ed01.pphosted.com with ESMTP id 2a00b00dnm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 22 Apr 2017 22:19:54 +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=zhT12UYL65bcsSchbhrMP66NXq80VXBnoxnLsQiGVy8=; b=kTbYzBR0RR5eFex61+uWwlvie56NECyFVKI8z+Y7Y1zRUgQhbqAMpT+oq79m7KlviaItzBlCkbO+ghneufPF3YfL/Sy3Eawy3IiFqa+76uUR27a2IrFH1+EQ2Ex3bIb727aXIY6zP0/Z6iZPY6URaGiDyNwSXaTeeorVLt9yYHw= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0635.namprd09.prod.outlook.com (10.160.151.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Sat, 22 Apr 2017 22:19:51 +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.1047.018; Sat, 22 Apr 2017 22:19:51 +0000 From: Henning Schulzrinne To: Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-05.txt Thread-Index: AQHSukAUkg9qRMRTfkG9avaG8VZkKqHRwNWAgAA3DDI= Date: Sat, 22 Apr 2017 22:19:51 +0000 Message-ID: References: <149273874370.22236.10629947769781911054@ietfa.amsl.com>, <45b9eaee-ccaa-89b1-80de-d3dd00023485@comcast.net> In-Reply-To: <45b9eaee-ccaa-89b1-80de-d3dd00023485@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: comcast.net; dkim=none (message not signed) header.d=none;comcast.net; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [100.8.248.19] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 7:rXhU+hUvnF+hEkTZHt5Y1xr5FCteH7XVSJx4bFU8f+yYz1VGP3x6BP7qrag+qI2nL320nTlwYCRu8J3UM8EZ8Zo8lx184M2MpdFMdCMTRSuvWjZWeMIMj+0W9IY8354/P+p5OS8NH5ZZjHTuwKTZY5VeF15SpazJKv07WqsYklqi20PPjcH9rX8Zw2Gv27+EBEeXPufL03GjXS7iUZKM1j+EdvGLS96qeomUSsGEfnndlCZNhjKowKs5Va9S2PXV0ZqGBArivKkVGG7s1I1pWzTP2CR/MrnVQJzO7fDbpE1znitrUSFgM4+k8o/qWxeJQ6O5x43pxJD2eNJPztnw9g== x-ms-office365-filtering-correlation-id: 2e554b32-dfe2-4aa2-f5c7-08d489cdb1fd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR09MB0635; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(68173958961439); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39840400002)(39410400002)(39450400003)(377454003)(102836003)(2906002)(9686003)(54896002)(2900100001)(66066001)(6116002)(76176999)(54356999)(86362001)(3846002)(53936002)(189998001)(50986999)(6436002)(110136004)(3660700001)(122556002)(6506006)(8936002)(77096006)(99286003)(8666007)(55016002)(33656002)(5660300001)(3280700002)(8676002)(6246003)(38730400002)(81166006)(229853002)(25786009)(230783001)(2950100002)(7696004)(74316002)(53546009)(6916009)(4326008)(7736002)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634A25978B3C09249A428D3EA1D0CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2017 22:19:51.1632 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-22_21:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-05.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, 22 Apr 2017 22:20:03 -0000 --_000_CY1PR09MB0634A25978B3C09249A428D3EA1D0CY1PR09MB0634namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is meant to be a general description, not specific to the SIP response= or the UA. The idea, I think, was that people wanted to emphasize that the= 'unwanted' response was just one of several inputs. But this context got l= ost in the editing. Would prefixing this with "The mechanism described here is only one of many= inputs likely to be used for dealing with unwanted calls." address the amb= iguity? Henning ________________________________ From: Paul Kyzivat Sent: Saturday, April 22, 2017 3:00:11 PM To: Henning Schulzrinne Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-05.tx= t I find the following from section 4 to be a bit odd/confusing: Call handling for unwanted calls is likely to involve a combination of heuristics, analytics, and machine learning. These may use call characteristics such as call duration and call volumes for a particular caller, as well changes in those metrics over time, as well as user feedback. Implementations will have to make appropriate trade-offs between falsely labeling a caller as unwanted and delivering unwanted calls. Is this intending to discuss automated behavior of the called party UA, or behavior of the called party, or something else? ISTM that "heuristics, analytics, and machine learning" are more likely to be applied by a middle box than the called UA. In a middle box those will be used to trigger coding per the callinfo-spam draft, which is outside the scope of this document. Presumably the called UA may use some techniques to decide to automatically generate a 607 response. The most likely I can think of is for it to remember a 607 was previously generated for this caller and to repeat it automatically for future calls from the same caller. Perhaps simply changing "Call handling for unwanted calls" to "Automatic recognition of unwanted calls". But that may be too simplistic. Otherwise this version seems good to me. Thanks, Paul --_000_CY1PR09MB0634A25978B3C09249A428D3EA1D0CY1PR09MB0634namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

This is meant to be a general description, not specific to the SIP respo= nse or the UA. The idea, I think, was that people wanted to emphasize that = the 'unwanted' response was just one of several inputs. But this context go= t lost in the editing.


Would prefixing this with "The mechanism described here is only one= of many inputs likely to be used for dealing with unwanted calls." ad= dress the ambiguity?


Henning

From: Paul Kyzivat <pa= ul.kyzivat@comcast.net>
Sent: Saturday, April 22, 2017 3:00:11 PM
To: Henning Schulzrinne
Cc: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwante= d-05.txt
 
I find the following from section 4 to be a bit od= d/confusing:

    Call handling for unwanted calls is likely to involve a = combination
    of heuristics, analytics, and machine learning.  Th= ese may use call
    characteristics such as call duration and call volumes f= or a
    particular caller, as well changes in those metrics over= time, as
    well as user feedback.  Implementations will have t= o make appropriate
    trade-offs between falsely labeling a caller as unwanted= and
    delivering unwanted calls.

Is this intending to discuss automated behavior of the called party UA, or behavior of the called party, or something else?

ISTM that "heuristics, analytics, and machine learning" are more = likely
to be applied by a middle box than the called UA. In a middle box those will be used to trigger coding per the callinfo-spam draft, which is
outside the scope of this document.

Presumably the called UA may use some techniques to decide to
automatically generate a 607 response. The most likely I can think of is for it to remember a 607 was previously generated for this caller and to repeat it automatically for future calls from the same caller.

Perhaps simply changing "Call handling for unwanted calls" to &qu= ot;Automatic
recognition of unwanted calls". But that may be too simplistic.

Otherwise this version seems good to me.

        Thanks,
        Paul
 --_000_CY1PR09MB0634A25978B3C09249A428D3EA1D0CY1PR09MB0634namp_-- From nobody Sun Apr 23 11:52: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 915E9129506 for ; Sun, 23 Apr 2017 11:52:20 -0700 (PDT) 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 2U6vYDpaKHAC for ; Sun, 23 Apr 2017 11:52:18 -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 B2AA11294EF for ; Sun, 23 Apr 2017 11:52:17 -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=0gbvniW0HP644h3Mg8Uiu2MbF9jb/pbbKAFBZdPaKKU=; b=f3dmgNynkVCLbH6kJmZnJMzOtfTKJl6Quu+6sALYXe7wxhcuXAFiGDDfCuTRyZ4KR9/GPriGegRxWtUOQavPmNDZ+7LJZJtaAwY+AIdBk6nbYU+aG9qX9/R2O62SksMvEUsVb+e9tJx3ILMg5BXyzApdwvE7g8dDYnx4aGwoLb8= Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03lp0049.outbound.protection.outlook.com [216.32.180.49]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-25-DjdBgGIjOYmH3tSXDzHwUg-1; Sun, 23 Apr 2017 14:52:13 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Sun, 23 Apr 2017 18:52:10 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1047.019; Sun, 23 Apr 2017 18:52:10 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-05.txt Thread-Index: AQHSukAaktDpmIhRFk+kXAxKqSFuXKHRwNWAgAA3yYCAAVZXcA== Date: Sun, 23 Apr 2017 18:52:09 +0000 Message-ID: References: <149273874370.22236.10629947769781911054@ietfa.amsl.com>, <45b9eaee-ccaa-89b1-80de-d3dd00023485@comcast.net> 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-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 7:waIUzWl0eu5+hSCgL2wpDfQnH8mV71oKMxk/63lzMZTlaM10f0hQapP3N0xp48DFFvSb90iOZvjePsMxlyFZ1rM9ZbfPqwsWC5vfXXuPkncORFO6zpe/VaNn7gbAOZnTVyuPcPnVq0exnwz3q3p+rTMeW70zGXH0GhQ8qY0qSqrubRkoB9pgZj3tsK8+WlMkgTQuxm+7EEUK8Ln76G7NcRRTdmQOxBEQi4OrRpXOGTjG80E1MPV3I6H/yh0/CtvxDyzwsTOEJrvkqddlSLlR7aS2uEQjM1MHY1L01suqRjiqLQfDp2B2F4I5xFeSAsZ79zvdc5qU+G/B6BBapzgbmA==; 20:HTSf0EQhSsQHUANlx3yzf4EQyYkggMeTscOCxYg2WKV0S9x01aoZH64BxMsv00Kebr3Pjsfu5QSWrl786VWSAtwLRXR9svADL8typjVKCQO0QA4j9EUuB4DtnJbDkNDQgNketjZzUb85m3sfR6hfmDGBulW5vQ/lwbeiSNiNxvY= x-ms-office365-filtering-correlation-id: 6e85c498-0302-419d-7dfa-08d48a79d8ff x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN2PR03MB2349; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(68173958961439)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2349; x-forefront-prvs: 0286D7B531 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39400400002)(39450400003)(51444003)(377454003)(50986999)(54356999)(76176999)(230783001)(33656002)(8936002)(6246003)(2950100002)(81166006)(122556002)(8676002)(8666007)(54896002)(6306002)(9686003)(236005)(99286003)(102836003)(3280700002)(790700001)(5660300001)(7736002)(55016002)(3660700001)(3846002)(6116002)(77096006)(53936002)(38730400002)(189998001)(25786009)(7696004)(53546009)(74316002)(229853002)(2900100001)(2906002)(4326008)(86362001)(66066001)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.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: 23 Apr 2017 18:52:10.0109 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 X-MC-Unique: DjdBgGIjOYmH3tSXDzHwUg-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB23503053E00436FC67DEBCE2B21C0SN2PR03MB2350namp_" Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-05.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: Sun, 23 Apr 2017 18:52:21 -0000 --_000_SN2PR03MB23503053E00436FC67DEBCE2B21C0SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I think that would be useful indeed. Maybe adding a few words about the ent= ity performing this could be even more attractive: "The mechanism described here is only one of many inputs likely to be used = by network analytics logic for dealing with unwanted calls." Thanks, Tolga From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Henning Schulz= rinne Sent: Saturday, April 22, 2017 6:20 PM To: Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-05.tx= t This is meant to be a general description, not specific to the SIP response= or the UA. The idea, I think, was that people wanted to emphasize that the= 'unwanted' response was just one of several inputs. But this context got l= ost in the editing. Would prefixing this with "The mechanism described here is only one of many= inputs likely to be used for dealing with unwanted calls." address the amb= iguity? Henning ________________________________ From: Paul Kyzivat > Sent: Saturday, April 22, 2017 3:00:11 PM To: Henning Schulzrinne Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-05.tx= t I find the following from section 4 to be a bit odd/confusing: Call handling for unwanted calls is likely to involve a combination of heuristics, analytics, and machine learning. These may use call characteristics such as call duration and call volumes for a particular caller, as well changes in those metrics over time, as well as user feedback. Implementations will have to make appropriate trade-offs between falsely labeling a caller as unwanted and delivering unwanted calls. Is this intending to discuss automated behavior of the called party UA, or behavior of the called party, or something else? ISTM that "heuristics, analytics, and machine learning" are more likely to be applied by a middle box than the called UA. In a middle box those will be used to trigger coding per the callinfo-spam draft, which is outside the scope of this document. Presumably the called UA may use some techniques to decide to automatically generate a 607 response. The most likely I can think of is for it to remember a 607 was previously generated for this caller and to repeat it automatically for future calls from the same caller. Perhaps simply changing "Call handling for unwanted calls" to "Automatic recognition of unwanted calls". But that may be too simplistic. Otherwise this version seems good to me. Thanks, Paul --_000_SN2PR03MB23503053E00436FC67DEBCE2B21C0SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

I think that would be useful indeed. Maybe adding a= few words about the entity performing this could be even more attractive:

 

“The mechanism described here is only one of = many inputs likely to be used by network analytics logic for dealing with u= nwanted calls.”

 

 

Thanks,

Tolga

 

From: sipcore [mailto:sipcore-bounce= s@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Saturday, April 22, 2017 6:20 PM
To: Paul Kyzivat <paul.kyzivat@comcast.net>
Cc: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwante= d-05.txt

 

T= his is meant to be a general description, not specific to the SIP response = or the UA. The idea, I think, was that people wanted to emphasize that the = 'unwanted' response was just one of several inputs. But this context got lost in the editing.

<= o:p> 

W= ould prefixing this with "The mechanism described here is only one of = many inputs likely to be used for dealing with unwanted calls." addres= s the ambiguity?

<= o:p> 

H= enning

From: Paul K= yzivat <paul.kyzivat@comcast= .net>
Sent: Saturday, April 22, 2017 3:00:11 PM
To: Henning Schulzrinne
Cc: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwante= d-05.txt

 

I find the followin= g from section 4 to be a bit odd/confusing:

    Call handling for unwanted calls is likely to involve a = combination
    of heuristics, analytics, and machine learning.  Th= ese may use call
    characteristics such as call duration and call volumes f= or a
    particular caller, as well changes in those metrics over= time, as
    well as user feedback.  Implementations will have t= o make appropriate
    trade-offs between falsely labeling a caller as unwanted= and
    delivering unwanted calls.

Is this intending to discuss automated behavior of the called party UA, or behavior of the called party, or something else?

ISTM that "heuristics, analytics, and machine learning" are more = likely
to be applied by a middle box than the called UA. In a middle box those will be used to trigger coding per the callinfo-spam draft, which is
outside the scope of this document.

Presumably the called UA may use some techniques to decide to
automatically generate a 607 response. The most likely I can think of is for it to remember a 607 was previously generated for this caller and to repeat it automatically for future calls from the same caller.

Perhaps simply changing "Call handling for unwanted calls" to &qu= ot;Automatic
recognition of unwanted calls". But that may be too simplistic.

Otherwise this version seems good to me.

        Thanks,
        Paul

--_000_SN2PR03MB23503053E00436FC67DEBCE2B21C0SN2PR03MB2350namp_-- From nobody Mon Apr 24 04:14:25 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 BFE34131453; Mon, 24 Apr 2017 04:14:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-sipcore-status-unwanted@ietf.org, Adam Roach , sipcore-chairs@ietf.org, adam@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149303246277.25889.4535549169926039230.idtracker@ietfa.amsl.com> Date: Mon, 24 Apr 2017 04:14:22 -0700 Archived-At: Subject: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-sipcore-status-unwanted-05=3A_=28with_COMMENT=29?= 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: Mon, 24 Apr 2017 11:14:23 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-sipcore-status-unwanted-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I actually have one mostly technical question: It is not fully clear to me if the Unwanted response code always indicates a user action or if the same code is used when an automated system declines the call? My understanding is that the idea is that this could also be automated if the user has some kind of control of the system (which is probably hard to verify). Or would it make sense to distinct between the cases where the user actively rejects a call or an automated system is generating the response code (on behalf of the user)? From nobody Mon Apr 24 05:36: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 D3F6B1314FF for ; Mon, 24 Apr 2017 05:36:01 -0700 (PDT) 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 WWp5CHb9jo-4 for ; Mon, 24 Apr 2017 05:36:00 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 126501314E6 for ; Mon, 24 Apr 2017 05:35:59 -0700 (PDT) X-AuditID: c1b4fb2d-c616898000004c5d-20-58fdf12e6d23 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 8C.A7.19549.E21FDF85; Mon, 24 Apr 2017 14:35:58 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0339.000; Mon, 24 Apr 2017 14:34:03 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-content-id-01 Thread-Index: AQHSugF/PN3A4rAB+kOqJk8KIGFSSqHPSNgAgACa7ICABKhjAA== Date: Mon, 24 Apr 2017 12:34:02 +0000 Message-ID: References: <877f2f0x18.fsf@hobgoblin.ariadne.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="euc-kr" Content-ID: <73A92AC69043984FACB7DC70A0D3D798@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbHdUlfv498Ig+kPZCy+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN79v9kKDqhUzJncytzAeEK5i5GTQ0LARKLrzlG2LkYuDiGB 9YwSE6/uZwRJCAksYZRY/8K6i5GDg03AQqL7nzZIWERAU2L5t63sILawgLPEkbbnzBBxF4l5 +7ewQthOEvff/WIDsVkEVCV2738NNpJXwFqi7+1mFohdk5gkPr9eBpbgFLCRuD3nDZjNKCAm 8f3UGiYQm1lAXOLWk/lMEIcKSCzZc54ZwhaVePn4H9gyUQE9iX3/vrJBxJUkfmy4xALRqyXx 5cc+NgjbWmJmbyc7hK0oMaX7ITvEQYISJ2c+YZnAKDYLybpZSNpnIWmfhaR9FpL2BYysqxhF i1OLi3PTjYz1Uosyk4uL8/P08lJLNjECY+jglt+6OxhXv3Y8xCjAwajEw/tA+W+EEGtiWXFl 7iFGCQ5mJRHePzxAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwO+y5ECAmkJ5akZqemFqQWwWSZ ODilGhjZlqRu9p7/9Wt5yJWaE/fDpI0SA6P/BnfWlmxP7s+RM9971P6CgeuKW627fz14FGS8 o7qwcOn2S3N8d6hnGDAemGVv+MQl6LZunYzAzO+u61Q4Fhz8+M/9soWW8f5djsoqJh9jPq85 en/t3PZC/b+Zyn0c736+v3qagTshed+CV6k3FW9MKhFWYinOSDTUYi4qTgQAftNocp0CAAA= Archived-At: Subject: Re: [sipcore] Comments on 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: Mon, 24 Apr 2017 12:36:02 -0000 SGksDQoNCkkgaGF2ZSB1cGRhdGVkIHRoZSBwdWxsIHJlcXVlc3QsIGFuZCB0aGVyZSBpcyBub3cg YW4gdXBkYXRlIHRvIFJGQyA1NjIxLg0KDQpJIGludGVuZCB0byBzdWJtaXQgYSBuZXcgdmVyc2lv biBzb29uLCBzbyBwbGVhc2UgdGFrZSBhIGxvb2suDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0 dS9kcmFmdC1jb250ZW50LWlkL3B1bGwvMy9maWxlcw0KDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCg0KDQpPbiAyMS8wNC8xNyAxNjoyNiwgInNpcGNvcmUgb24gYmVoYWxmIG9mIENocmlzdGVy IEhvbG1iZXJnIg0KPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0Kd3JvdGU6DQoNCj5IaSwNCj4NCj5JqfZ2ZSBoYWQg YSBjaGF0IHdpdGggSXZvLCBhbmQgd2UgaGF2ZSB1cGRhdGVkIHRoZSB0ZXh0IGluIHRoZSBwdWxs DQo+cmVxdWVzdC4NCj4NCj5Nb3N0IGNoYW5nZXMgYXJlIGluIHRoZSBJbnRyb2R1Y3Rpb24sIGJ1 dCBzb21lIGFsaWdubWVudCBjaGFuZ2VzIGhhdmUgYWxzbw0KPmJlZW4gZG9uZSBlbHNld2hlcmUu IFRoZSBpZGVhIHdhcyB0byBvbmx5IHVzZSB0ZXJtaW5vbG9neSBhbHJlYWR5IGRlZmluZWQNCj5l bHNld2hlcmUuDQo+DQo+Tm90ZSB0aGF0IHdlIGhhdmUgYWRkZWQgYSCp+FVwZGF0ZSB0byBSRkMg MjA0NSBhbmQgUkZDIDU2MzKp9yBzZWN0aW9uLCB3aGVyZQ0KPndlIHN0aWxsIG5lZWQgdG8gYWRk IHNvbWUgdGV4dCwgYmFzaWNhbGx5IHNheWluZyB0aGF0IHRoZSBDSUQgVVJMIGlzIGNhbg0KPmFs c28gYmUgdXNlZCB3aXRoIG1lc3NhZ2UtYm9kaWVzIChjdXJyZW50bHkgdGhlIFJGQ3Mgb25seSB0 YWxrIGFib3V0IGJvZHkNCj5wYXJ0cykuIFdlIGRvIE5PVCBpbnRlbmQgdG8gbWFrZSBhIE9MRC1U RVhULU5FVy1URVhUIGNoYW5nZSwgYnV0IHNpbXBseQ0KPmFkZCBhIHN0YXRlbWVudC4NCj4NCj5U aGUgWE1MIGNoYW5nZXMsIGFuZCBUWFQgZmlsZSBiYXNlZCBvbiB0aGUgbGF0ZXN0IGNoYW5nZXMs IGNhbiBiZSBzZWVuDQo+aGVyZToNCj4NCj5odHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQt Y29udGVudC1pZC9wdWxsLzMvZmlsZXMNCj4NCj4NCj5SZWdhcmRzDQo+DQo+Q2hyaXN0ZXINCj4N Cj4NCj4NCj4NCj4NCj4NCj4NCj5PbiAyMS8wNC8xNyAxMDoxNiwgInNpcGNvcmUgb24gYmVoYWxm IG9mIEl2byBTZWRsYWNlayINCj48c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBpdm8uc2VkbGFjZWtAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4NCj4+SGVsbG8sDQo+Pg0KPj4+ ID4gMikgaW4gb3RoZXIgcGxhY2VzLCBJIHJhdGhlciB0YWxrIGFib3V0ICJjb250ZW50IiB3aGVy ZSB0aGUgImNvbnRlbnQiDQo+Pj4gPiBjYW4gYmUgY2FycmllZCBpbiAoYSkgYSBib2R5IHBhcnQg b2YgbXVsdGlwYXJ0IGJvZHksIG9yIChiKSBpbg0KPj4+ID4gbm9uLW11bHRpcGFydCBib2R5Lg0K Pj4+IA0KPj4+IFdlbGwuLi4gIFdoYXQgZXhhY3RseSBkbyB5b3Ugd2FudCB0aGUgdGVybSB0byBt ZWFuPw0KPj4NCj4+QnkgY29udGVudCwgSSBpbnRlbmQgdG8gcmVmZXIgdG8gYSBwaWVjZXMgb2Yg aW5mb3JtYXRpb24uDQo+Pk9uZSBleGFtcGxlIG9mIHRoZSBjb250ZW50IGlzIGFuIFhNTCB0ZXh0 IG9mIGFwcGxpY2F0aW9uL3BpZGYreG1sIE1JTUUNCj4+dHlwZS4NCj4+QW5vdGhlciBleGFtcGxl IG9mIHRoZSBjb250ZW50IGlzIGEgSlBFRyBwaWN0dXJlLg0KPj5Bbm90aGVyIGV4YW1wbGUgb2Yg dGhlIGNvbnRlbnQgaXMgYW4gdW5zdHJ1Y3RlZCB0ZXh0Lg0KPj4NCj4+VGhlIGNvbnRlbnQgY2Fu IGJlIHRyYW5zcG9ydGVkIGJ5IFNJUCAodXNpbmcgdmFyaW91cyBtZXRob2RzLCBhcw0KPj5pbmRp Y2F0ZWQgYnkgeW91IGJlbG93KSwgY2FuIGJlIHRyYW5zcG9ydGVkIGJ5IG90aGVyIHByb3RvY29s IChlLmcuDQo+PkhUVFApLCBvciBlLmcuIGNhbiBiZSBzdG9yZWQgaW4gYSBmaWxlIGluIGEgY29t cHV0ZXIuDQo+Pg0KPj4+IEkgbWVhbiwgdGhlcmUgYXJlIHRocmVlDQo+Pj4gdGhpbmdzIEkgY2Fu IG5hbWUgb2ZmIHRoZSB0b3Agb2YgbXkgaGVhZDoNCj4+PiAtIHRoZSBib2R5IG9mIHRoZSBTSVAg bWVzc2FnZQ0KPj4+IC0gYSBib2R5IHBhcnQgd2hpY2ggaXMgbm90IGl0c2VsZiBhIG11bHRpcGFy dA0KPj4+IC0gYSBib2R5IHBhcnQgd2hpY2ggaXMgcGFydCBvZiBhIG11bHRpcGFydA0KPj4NCj4+ VGhlIGFib3ZlIGFyZSBzZXZlcmFsIG1ldGhvZHMgaG93IHRvIHRyYW5zcG9ydCB0aGUgY29udGVu dCBpbiBTSVAuDQo+Pg0KPj4+IEdpdmVuIHRoYXQgcGFydHMgb2YgbXVsdGlwYXJ0cyBjYW4gdGhl bXNlbHZlcyBiZSBtdWx0aXBhcnRzLCB0aGVyZSBhcmUNCj4+PmJvZHkgDQo+Pj4gcGFydHMgdGhh dCBhcmUgZXhhbXBsZXMgZm9yIG1vc3Qgb2YgdGhlIGVpZ2h0IHBvc3NpYmxlIHRydWUvZmFsc2UN Cj4+PiBjb21iaW5hdGlvbnMgb2YgdGhlc2UgcHJvcGVydGllcy4NCj4+PiANCj4+PiBBcyBmYXIg YXMgSSBrbm93LCB0aGVyZSdzIG5vIChpbnRlcmVzdGluZykgc3RhdGVtZW50IG9uZSBjYW4gbWFr ZSB3aGljaA0KPj4+IHJlcXVpcmVzIGFuICJBIG9yIEIiIGRlc2NyaXB0aW9uIG9mIGl0cyBzdWJq ZWN0IC0tIGFzIGxvbmcgYXMgeW91DQo+Pj5jYXJlZnVsbHkgDQo+Pj4gdGhpbmsgdGhyb3VnaCB3 aGF0IGl0IGlzIHRoYXQgeW91IG1lYW4sIGFuZCBjaG9vc2UgYSBwaHJhc2UgdGhhdA0KPj4+YWNj dXJhdGVseSANCj4+PiBkZXNjcmliZXMgaXQuDQo+Pj4gDQo+Pj4gSW4geW91ciBleGFtcGxlLCBJ IHN1c3BlY3QgdGhhdCB5b3UgdXNlICJjb250ZW50IiB0byBtZWFuICJhIGJvZHkgcGFydA0KPj4+ d2hpY2ggDQo+Pj4gaXMgbm90IGl0c2VsZiBhIG11bHRpcGFydCIgKHNpbmNlIHRoZSB3aG9sZSBi b2R5IGlzIGl0c2VsZiBhIGJvZHkNCj4+PnBhcnQpLg0KPj4NCj4+Tm8uIA0KPj4NCj4+VGhlIGNv bnRlbnQgaXMgYSBwaWVjZSBvZiBpbmZvcm1hdGlvbi4NCj4+VGhlIGJvZHkgcGFydCB3aGljaCBp cyBub3QgaXRzZWxmIGEgbXVsdGlwYXJ0IGlzIGEgbWV0aG9kIHRvIHRyYW5zcG9ydA0KPj50aGUg Y29udGVudC4NCj4+DQo+PktpbmQgcmVnYXJkcw0KPj4NCj4+SXZvDQo+Pg0KPj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5zaXBjb3JlIG1haWxpbmcg bGlzdA0KPj5zaXBjb3JlQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwY29yZQ0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+c2lwY29yZSBtYWlsaW5nIGxpc3QNCj5zaXBjb3JlQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCg== From nobody Mon Apr 24 07:30:13 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 61935131547; Mon, 24 Apr 2017 07:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 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] 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 ZLddzrc8p0Yn; Mon, 24 Apr 2017 07:30:01 -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 C6E6913153E; Mon, 24 Apr 2017 07:29:58 -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 v3OETGOF004188; Mon, 24 Apr 2017 14:29:57 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0019.outbound.protection.outlook.com [23.103.198.19]) by mx0b-0024ed01.pphosted.com with ESMTP id 2a00besddf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 24 Apr 2017 14:29:57 +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=X9jDEOLJBw7a8yPgMaxV97bsTJdlYtn9t3r82+cS8D8=; b=DK4kHPCStSFr7QgJF6X0RLHPeJmlw8CoeWjGAyXrTIVZPbGTO0kZmtxG4g7PpP3VRGOm3W7ev762XUh5DVx6ZTzaicaLjto6+5yne76QqnWHLKDALHscBZDwRuioDKAiGG3oteaCSXqCm6pO5sS7MwtMDrEbz8cdnwbRQd93yII= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0635.namprd09.prod.outlook.com (10.160.151.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Mon, 24 Apr 2017 14:29:55 +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.1047.019; Mon, 24 Apr 2017 14:29:55 +0000 From: Henning Schulzrinne To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "draft-ietf-sipcore-status-unwanted@ietf.org" , Adam Roach , "sipcore-chairs@ietf.org" , "adam@nostrum.com" , "sipcore@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-sipcore-status-unwanted-05:_(with_COMMENT)?= Thread-Index: AQHSvOvw1py7aDhMjEyD7coW+O+7oqHUkcnQ Date: Mon, 24 Apr 2017 14:29:55 +0000 Message-ID: References: <149303246277.25889.4535549169926039230.idtracker@ietfa.amsl.com> In-Reply-To: <149303246277.25889.4535549169926039230.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kuehlewind.net; dkim=none (message not signed) header.d=none;kuehlewind.net; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [192.104.54.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 7:91+B25Xfu4sUjwIzj+y9rHoLBOwmHCoIWBK1TPT00STT6fcdEc+649+m83tA0e7Vgr+fZVzaIxun6dbhY6B5DJOwqpfAFq9IeQuS9QmSOyevqvuanRGrx8uLwXmS2sYIZRz1S0WHFJXT9jn9D26/KzyrMf/oMhYrX/PnIGv1zSq8UP7oQtxa4/mxNEwe3S+Zh4leFaYKS35vbUDhzui2KNbZq35pxY5GK2aTbRg/eD6ch1jT1OdQ+5HD/WtV5mdyOX9LyvRlZYXGBsjzsyp7rWEVQoMn6MxUWsAzq0rzJS2rAJMUgta6zxpBbQ579zXeJj3SBQykut/K/nl8BGc9YQ== x-ms-office365-filtering-correlation-id: 753a4d16-8b39-4cd3-58c3-08d48b1e6111 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR09MB0635; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39840400002)(39400400002)(13464003)(377454003)(54356999)(76176999)(50986999)(25786009)(5660300001)(122556002)(53546009)(3846002)(102836003)(6116002)(3280700002)(7736002)(3660700001)(305945005)(229853002)(6246003)(74316002)(66066001)(38730400002)(2900100001)(2950100002)(6436002)(53936002)(54906002)(81166006)(6506006)(99286003)(55016002)(224303003)(4326008)(86362001)(224313004)(2906002)(575784001)(33656002)(189998001)(7696004)(9686003)(6306002)(8936002)(77096006)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2017 14:29:55.8407 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-24_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-sipcore-status-unwanted-05=3A_=28with_COMMENT=29?= 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, 24 Apr 2017 14:30:04 -0000 VGhlcmUgd2FzIGFuIGV4dGVuc2l2ZSBkaXNjdXNzaW9uIG9uIHRoZSAid2hvIGlzIHJlc3BvbnNp YmxlIiBpc3N1ZSBvbiB0aGUgbGlzdC4gTXkgdGFrZSBpcyB0aGF0IHRoZXJlJ3MganVzdCBubyBn b29kIHdheSB0byBrbm93IHdoZXRoZXIgdGhlICd1bndhbnRlZCcgcmVzcG9uc2Ugd2FzIGdlbmVy YXRlZCBieSBhIGJ1dHRvbiBwcmVzcyBvciBzb21ldGhpbmcgc2VtaS1hdXRvbWF0ZWQgKGUuZy4s IHRoZSBzeXN0ZW0gcG9wcyB1cCBhICJ5b3UgaHVuZyB1cCB2ZXJ5IHF1aWNrbHkuIFdhcyB0aGlz IGEgc3BhbSBjYWxsPyIgZGlhbG9nIGJveCkgb3IgYXV0b21hdGVkIGZhbmN5LW1hY2hpbmUtbGVh cm5pbmcgYWxnb3JpdGhtIGltcGxlbWVudGVkIG9uIHRoZSBlbmQgc3lzdGVtLiBNeSBndWVzcyBp cyB0aGF0IG1hbnVhbCB3aWxsIGJlLCBieSBmYXIsIHRoZSBtb3N0IGNvbW1vbiB1c2FnZS4gSWYg SSBpbXBsZW1lbnQgTUwgb24gdGhlIGVuZCBzeXN0ZW0gZm9yIGNhbGwgY2xhc3NpZmljYXRpb24s IEkgcHJvYmFibHkgd2FudCB0byBjb250cm9sIHRoZSBleHBlcmllbmNlIGFuZCB0aHVzIG5vdCBt dWRkeSB0aGUgd2F0ZXJzIGJ5IGhhdmluZyB0aGUgbmV0d29yayBmaWx0ZXIsIHRvby4NCg0KUHJh Y3RpY2FsbHktc3BlYWtpbmcsIEkgZG9uJ3Qgc2VlIGEgZ29vZCB3YXkgdG8gZW5mb3JjZSBhbnkg ZGlzdGluY3Rpb24sIGV2ZW4gbGVhdmluZyBhc2lkZSB0aGUgcG9zc2liaWxpdGllcyBiZXR3ZWVu IGEgZnVsbHktbWFudWFsIGFuZCBpbnZpc2libHktYXV0b21hdGljIG1lY2hhbmlzbS4gSXQgaXMg YWxzbyBub3QgY2xlYXIgaG93IHRoZSBuZXR3b3JrIHdvdWxkIG1ha2UgdXNlIG9mIHN1Y2ggYSBk aXN0aW5jdGlvbiAtIGJvdGggaHVtYW5zIGFuZCBtYWNoaW5lcyBtYWtlIG1pc3Rha2VzLg0KDQpU aHVzLCBJIHRoaW5rIHRoZSBpbnRlbnQgaXMgdG8gdXNlIGl0IGZvciBodW1hbiBmZWVkYmFjaywg YnV0IHdpdGhvdXQgdHJ5aW5nIHRvIGJlIG92ZXJseSBwcmVzY3JpcHRpdmUuDQoNClRoYXQgc2Fp ZCwgdGhlIGNhbGwtaW5mbyBkcmFmdCBtYXkgbmVlZCBhbiBleHRlbnNpb24gZm9yIHRoZSBraW5k IG9mICJiYWNrd2FyZCIgaW5kaWNhdGlvbiBzbyB0aGF0IGFuIGF1dG9tYXRlZCBjYWxsIHJlY2lw aWVudCBjYW4gdGVsbCB0aGUgbmV0d29yayBob3cgaXQgY2xhc3NpZmllZCB0aGUgY2FsbC4NCg0K SGVubmluZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWlyamEgS8O8aGxl d2luZCBbbWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXRdIA0KU2VudDogTW9uZGF5LCBBcHJpbCAy NCwgMjAxNyA3OjE0IEFNDQpUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogZHJhZnQt aWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZEBpZXRmLm9yZzsgQWRhbSBSb2FjaCA8YWRhbUBu b3N0cnVtLmNvbT47IHNpcGNvcmUtY2hhaXJzQGlldGYub3JnOyBhZGFtQG5vc3RydW0uY29tOyBz aXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBNaXJqYSBLw7xobGV3aW5kJ3MgTm8gT2JqZWN0aW9u IG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDU6ICh3aXRoIENPTU1FTlQp DQoNCk1pcmphIEvDvGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9z aXRpb24gZm9yDQpkcmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVzLXVud2FudGVkLTA1OiBObyBPYmpl Y3Rpb24NCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGlu dGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8g YW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3Jh cGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19pZXNnX3N0YXRlbWVu dF9kaXNjdXNzLTJEY3JpdGVyaWEuaHRtbCZkPUR3SURhUSZjPXkwaDBvbUNlMGpBVUdyNGdBUTAy Rncmcj1GSmNWb0RrV001RWlWY1YwUmVYOGxEVTFYZUhJWVJIZmFycGs0TUs1OVJFJm09cHh1TzNu dzZrdzl3TzJKM1ZNYU9uOTZXc2NXNlhmeDByZXpYQlZyQjZNQSZzPU1HLTUwLXNtRnhVNTRRWWwx S05yblJhb3M1blZBRm9ES3BNX0ZtMmwyRHMmZT0NCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0 IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBh bG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJh Y2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEc2lwY29yZS0yRHN0YXR1cy0yRHVud2Fu dGVkXyZkPUR3SURhUSZjPXkwaDBvbUNlMGpBVUdyNGdBUTAyRncmcj1GSmNWb0RrV001RWlWY1Yw UmVYOGxEVTFYZUhJWVJIZmFycGs0TUs1OVJFJm09cHh1TzNudzZrdzl3TzJKM1ZNYU9uOTZXc2NX NlhmeDByZXpYQlZyQjZNQSZzPXdVX3BuS1d1bndLcFE4N0VKbzYydGdiNkR1T2JmMk5zS1hteDFT TUU2TjgmZT0gDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQpJIGFjdHVhbGx5IGhhdmUgb25lIG1vc3RseSB0ZWNobmljYWwgcXVlc3Rpb246IEl0IGlzIG5v dCBmdWxseSBjbGVhciB0bw0KbWUgaWYgdGhlIFVud2FudGVkIHJlc3BvbnNlIGNvZGUgYWx3YXlz IGluZGljYXRlcyBhIHVzZXIgYWN0aW9uIG9yIGlmIHRoZQ0Kc2FtZSBjb2RlIGlzIHVzZWQgd2hl biBhbiBhdXRvbWF0ZWQgc3lzdGVtIGRlY2xpbmVzIHRoZSBjYWxsPyBNeQ0KdW5kZXJzdGFuZGlu ZyBpcyB0aGF0IHRoZSBpZGVhIGlzIHRoYXQgdGhpcyBjb3VsZCBhbHNvIGJlIGF1dG9tYXRlZCBp Zg0KdGhlIHVzZXIgaGFzIHNvbWUga2luZCBvZiBjb250cm9sIG9mIHRoZSBzeXN0ZW0gKHdoaWNo IGlzIHByb2JhYmx5IGhhcmQNCnRvIHZlcmlmeSkuIE9yIHdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8g ZGlzdGluY3QgYmV0d2VlbiB0aGUgY2FzZXMgd2hlcmUNCnRoZSB1c2VyIGFjdGl2ZWx5IHJlamVj dHMgYSBjYWxsIG9yIGFuIGF1dG9tYXRlZCBzeXN0ZW0gaXMgZ2VuZXJhdGluZyB0aGUNCnJlc3Bv bnNlIGNvZGUgKG9uIGJlaGFsZiBvZiB0aGUgdXNlcik/DQoNCg0K From nobody Mon Apr 24 12:18:46 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 BED42128C82; Mon, 24 Apr 2017 12:18:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-sipcore-status-unwanted@ietf.org, Adam Roach , sipcore-chairs@ietf.org, adam@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149306151877.25786.8897126754896409687.idtracker@ietfa.amsl.com> Date: Mon, 24 Apr 2017 12:18:38 -0700 Archived-At: Subject: [sipcore] Eric Rescorla's No Objection on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) 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: Mon, 24 Apr 2017 19:18:39 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-sipcore-status-unwanted-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It seems like the security considerations here probably need to cover what's needed to prevent forged 607 responses. This seems like an issue for on-path attackers, who could block the real response and inject a 607. This isn't usually that great an attack, but if you can use it in a sort of bounce attack to really gag a sender, that would be bad. Probably what's needed here is text about only accepting 607s over TLS (and filtering at the other endpoint). It's also worth mentioning that in a post-STIR world, you could send the PASSporT object as proof of the existence of the call (though not of its unwantedness). From nobody Mon Apr 24 13:10:34 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 71FA1131915; Mon, 24 Apr 2017 13:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 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] 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 NJEuHzXqbMEf; Mon, 24 Apr 2017 13:10:16 -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 7281A129ADD; Mon, 24 Apr 2017 13:10:16 -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 v3OK9W1s007148; Mon, 24 Apr 2017 20:10:15 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0021.outbound.protection.outlook.com [23.103.198.21]) by mx0b-0024ed01.pphosted.com with ESMTP id 2a00besnb1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 24 Apr 2017 20:10: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=nhPFW0/9S0TR1h9wBBSMCSB1CTINNGyZNJogwIJUe8k=; b=kozOSvsljhCj3rehhJtOqavO1+brQheoDgpG3KS01jpmeZlHigPRq4mYaxpbW6kjmLNrNK63QbW8Yd0C7MxqtvSsrH59not3R8xOsZHS41cSu9MAhuOdiqVJsZrAkV+NPhdWn4J6EiVde0UAxzkMhqUvZcIqNuGGNKMbNl2kUVE= 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_128_CBC_SHA256_P256) id 15.1.1047.13; Mon, 24 Apr 2017 20:10:13 +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.1047.019; Mon, 24 Apr 2017 20:10:13 +0000 From: Henning Schulzrinne To: Eric Rescorla , The IESG CC: "draft-ietf-sipcore-status-unwanted@ietf.org" , Adam Roach , "sipcore-chairs@ietf.org" , "adam@nostrum.com" , "sipcore@ietf.org" Thread-Topic: Eric Rescorla's No Objection on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) Thread-Index: AQHSvS+WgSEe4GfDlEqdLIPNbNa6sKHU8NZw Date: Mon, 24 Apr 2017 20:10:13 +0000 Message-ID: References: <149306151877.25786.8897126754896409687.idtracker@ietfa.amsl.com> In-Reply-To: <149306151877.25786.8897126754896409687.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [192.104.54.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 7:lX7IUGZ6vfVlbWmVYhZq1NJgV/zvISyys19/LEnKX923oGRJ0LY/uEMp93NSYO50XYj1rt+HI5yafI0LLIW91d9t/FcYVnOKkA+DD0Hwo5TRN7eB0B1QZzx0ATvCOXi8wim1ZSNpQFeUIjo4dsNZ59/94OM+/tscEg+hE2qESFaFwwAa++gnctye6UiLIT0gMQO4aeHpAS6EXTH7bCu0WrUqxjyAT6bJwAXXFeqNwrsshAx93pN1Cpwqh9F7UJLCSb05bYFWxVe3Jda1Bfp4XZHL2JLl7QRq+p9buEtrOd1Q9h4BCGfrnVmqxcTjWsiYXktPdQla2SeSjsR3k8x3tg== x-ms-office365-filtering-correlation-id: b4f7da89-39d0-42a3-87fa-08d48b4deaa3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:CY1PR09MB0634; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39400400002)(39410400002)(13464003)(377454003)(189998001)(38730400002)(7736002)(74316002)(7696004)(305945005)(3280700002)(230783001)(54906002)(99286003)(9686003)(6306002)(55016002)(76176999)(2906002)(86362001)(8676002)(54356999)(575784001)(50986999)(53936002)(33656002)(25786009)(6436002)(6116002)(102836003)(8936002)(122556002)(229853002)(66066001)(6246003)(81166006)(3846002)(77096006)(4326008)(2950100002)(5660300001)(3660700001)(6506006)(2900100001)(53546009)(26123001); 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2017 20:10:13.0600 (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-04-24_16:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Eric Rescorla's No Objection on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) 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, 24 Apr 2017 20:10:20 -0000 SW4gb3JkZXIgdG8gYmUgZWZmZWN0aXZlLCB5b3UnZCBoYXZlIHRvIGJlIGFibGUgdG8gaW50ZXJj ZXB0IGxvdHMgb2YgZGVzdGluYXRpb25zIChzaW5jZSB0aGUgc3BhbW1lciBpcyBsaWtlbHkgbm90 IHJlYWNoaW5nIGFsbCBkZXN0aW5hdGlvbnMgdGhhdCB0aGUgYXR0YWNrZXIgbWF5IGhhdmUgYWNj ZXNzIHRvKS4gSWYgdGhlIGF0dGFja2VyIGhhcyB0aGF0IGtpbmQgb2YgaW4tYmFuZCBhY2Nlc3Ms IHdoeSBub3QganVzdCBibG9jayB0aGUgY2FsbHMgZGlyZWN0bHkgd2l0aCBhbnkgNHh4LzV4eC82 eHggcmVzcG9uc2U/DQoNCkZvciBtb3N0IGNvbW1lcmNpYWwgVm9JUCBuZXR3b3JrcyAoc2F5LCBy ZXNpZGVudGlhbCBjYWJsZSBuZXR3b3JrcyBvciBMVEUpLCB0aGUgYXR0YWNrZXIgd291bGQgaGF2 ZSB0byBjb21wcm9taXNlIHRoZSBsaW5rLWxldmVsIGVuY3J5cHRpb24gb3IgaW5zdGFsbCBpdHNl bGYgb24gdGhlIGVuZCBzeXN0ZW0uIChJbiB0aGUgbGF0dGVyIGNhc2UsIGdhbWUgb3ZlciwgZXZl biB3aXRoIFRMUy4pDQoNCk9idmlvdXNseSwgVExTIGlzIGEgZ29vZCBpZGVhLCBidXQgSSBzdXNw ZWN0IHRoYXQgbWFraW5nIGl0IE1VU1Qgc3RyZW5ndGggd291bGQgZXNzZW50aWFsbHkgcHJlY2x1 ZGUgdGhlIGRlcGxveW1lbnQgb2YgdGhlIG1lY2hhbmlzbSBpbiBtb3N0IGNvbW1lcmNpYWwgbmV0 d29ya3MuDQoNCkkgZG8gYmVsaWV2ZSB0aGF0IHBvaW50aW5nIG91dCB0aGUgcG90ZW50aWFsIGlz c3VlIGlzIHdvcnRod2hpbGUuIEFueSB0ZXh0IHN1Z2dlc3Rpb25zIHdvdWxkIGJlIGhlbHBmdWwu DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBFcmljIFJlc2NvcmxhIFttYWls dG86ZWtyQHJ0Zm0uY29tXSANClNlbnQ6IE1vbmRheSwgQXByaWwgMjQsIDIwMTcgMzoxOSBQTQ0K VG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0 dXMtdW53YW50ZWRAaWV0Zi5vcmc7IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+OyBzaXBj b3JlLWNoYWlyc0BpZXRmLm9yZzsgYWRhbUBub3N0cnVtLmNvbTsgc2lwY29yZUBpZXRmLm9yZw0K U3ViamVjdDogRXJpYyBSZXNjb3JsYSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLXNpcGNv cmUtc3RhdHVzLXVud2FudGVkLTA1OiAod2l0aCBDT01NRU5UKQ0KDQpFcmljIFJlc2NvcmxhIGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1z aXBjb3JlLXN0YXR1cy11bndhbnRlZC0wNTogTm8gT2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGlu ZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBl bWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJl ZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVh c2UgcmVmZXIgdG8gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfaWVzZ19zdGF0ZW1lbnRfZGlzY3Vzcy0yRGNyaXRlcmlhLmh0 bWwmZD1Ed0lDYVEmYz15MGgwb21DZTBqQVVHcjRnQVEwMkZ3JnI9RkpjVm9Ea1dNNUVpVmNWMFJl WDhsRFUxWGVISVlSSGZhcnBrNE1LNTlSRSZtPVItRXhiQ2pOMkllei1tWkxjV0ZXSDdjdE55a1JY OVFUOFM5c3Jjc0lSV2cmcz1mYkFfZzd0MTh6dUpRSVYtczlrZXdsTFNjTGwxaGgzcTdka2RJcjJL bi1vJmU9DQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1F TlQgcG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3Qg cG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0 LTJEaWV0Zi0yRHNpcGNvcmUtMkRzdGF0dXMtMkR1bndhbnRlZF8mZD1Ed0lDYVEmYz15MGgwb21D ZTBqQVVHcjRnQVEwMkZ3JnI9RkpjVm9Ea1dNNUVpVmNWMFJlWDhsRFUxWGVISVlSSGZhcnBrNE1L NTlSRSZtPVItRXhiQ2pOMkllei1tWkxjV0ZXSDdjdE55a1JYOVFUOFM5c3Jjc0lSV2cmcz13Q21E VDlnWGJvSkFuaVhCMUFlaWFEbWtFS0E0U2IzREh0N0NYRGhJZ1VNJmU9IA0KDQoNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KSXQgc2VlbXMgbGlrZSB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgaGVyZSBwcm9iYWJseSBuZWVkDQp0byBjb3ZlciB3aGF0J3Mg bmVlZGVkIHRvIHByZXZlbnQgZm9yZ2VkIDYwNyByZXNwb25zZXMuIFRoaXMNCnNlZW1zIGxpa2Ug YW4gaXNzdWUgZm9yIG9uLXBhdGggYXR0YWNrZXJzLCB3aG8gY291bGQgYmxvY2sNCnRoZSByZWFs IHJlc3BvbnNlIGFuZCBpbmplY3QgYSA2MDcuIFRoaXMgaXNuJ3QgdXN1YWxseQ0KdGhhdCBncmVh dCBhbiBhdHRhY2ssIGJ1dCBpZiB5b3UgY2FuIHVzZSBpdCBpbiBhIHNvcnQgb2YNCmJvdW5jZSBh dHRhY2sgdG8gcmVhbGx5IGdhZyBhIHNlbmRlciwgdGhhdCB3b3VsZCBiZSBiYWQuDQoNClByb2Jh Ymx5IHdoYXQncyBuZWVkZWQgaGVyZSBpcyB0ZXh0IGFib3V0IG9ubHkgYWNjZXB0aW5nDQo2MDdz IG92ZXIgVExTIChhbmQgZmlsdGVyaW5nIGF0IHRoZSBvdGhlciBlbmRwb2ludCkuIEl0J3MNCmFs c28gd29ydGggbWVudGlvbmluZyB0aGF0IGluIGEgcG9zdC1TVElSIHdvcmxkLCB5b3UgY291bGQN CnNlbmQgdGhlIFBBU1Nwb3JUIG9iamVjdCBhcyBwcm9vZiBvZiB0aGUgZXhpc3RlbmNlIG9mDQp0 aGUgY2FsbCAodGhvdWdoIG5vdCBvZiBpdHMgdW53YW50ZWRuZXNzKS4NCg0KDQo= From nobody Mon Apr 24 13:18: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 C809F131906 for ; Mon, 24 Apr 2017 13:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 zTxZXOdVlEfF for ; Mon, 24 Apr 2017 13:18:28 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 2424D13162A for ; Mon, 24 Apr 2017 13:18:28 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id 11so59673606ybw.1 for ; Mon, 24 Apr 2017 13:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qFZJ3smI5kJFwWaCteT6Z41OE4mqQapcYcrNES7eszk=; b=ZDxXNiFfuvXrXqdVn7c6MuGr7mO1KFVEINxuDafyX7wsapptqzuFmPs9AhO0faEoqI reluaNkPLt8VMrZGPu5UqYJcfhgDNTFqVNU4Rdgq13GVGhB0NE6W6mdiezXrNDUGNDer qiJiue3i5Pzaarr5QAaVG/K0H/qmBjuuvy/OKw6OttTzgb9paSaOJKVRX/ONGL+ncAcC Em3DxUJKJUfg61cJ4V0i8I8zLNiStPK5gPh9Iu7Ie190vlve8b2CPa7/rZLzG7s4unqf RdxaomitW9uaLaz2CLJyL/GFCiioHrqYzbjtKRkJC0dTbfbW6rWntzzCxWLhfDuyrofq 0XVw== 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=qFZJ3smI5kJFwWaCteT6Z41OE4mqQapcYcrNES7eszk=; b=WxiX0ExrnflQZ7DUvXsbl+9EOYPLx/sbl/y/mjBTaVo1mi5vQ1TZfpYqcn/znNuKTh PUGFCNWkjuRBXkoK3gxKB8XVjZm73V55xsHJ3a/t4tBF6VXc4dnwYnRcTr5jdgkpKt5b /G7SapD9DDmegevPp8OpxZi67F7GqlcUC5qp7EtVtn6GrqZh4m4kdF1ZoaJwwvIBQAD6 ntE9y/JvtiTZU/ezld5mtxrJog57z8Trpvk5XRrFA+OTxgif4KlR1narqOZ/ki2eTzNp u2FC6q1jtci5EtlZbK+gAlPXn353cglQMBvMrweSrbHZR1b+Mgy8pIJWDXViS68jhPQc Wy7Q== X-Gm-Message-State: AN3rC/5q/OWK5ry+Wrb7x8HYtDBdydnl5k52R/IA+vWhpakr3ODnToBr eLHs1ryLzlhvJOp+WMf7Ss0rfffBmA== X-Received: by 10.37.170.169 with SMTP id t38mr6208602ybi.105.1493065107397; Mon, 24 Apr 2017 13:18:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Mon, 24 Apr 2017 13:17:46 -0700 (PDT) In-Reply-To: References: <149306151877.25786.8897126754896409687.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Mon, 24 Apr 2017 13:17:46 -0700 Message-ID: To: Henning Schulzrinne Cc: The IESG , "draft-ietf-sipcore-status-unwanted@ietf.org" , "sipcore-chairs@ietf.org" , "adam@nostrum.com" , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0877165a6d8e054def4f60 Archived-At: Subject: Re: [sipcore] Eric Rescorla's No Objection on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) 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, 24 Apr 2017 20:18:32 -0000 --94eb2c0877165a6d8e054def4f60 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 24, 2017 at 1:10 PM, Henning Schulzrinne < Henning.Schulzrinne@fcc.gov> wrote: > In order to be effective, you'd have to be able to intercept lots of > destinations (since the spammer is likely not reaching all destinations > that the attacker may have access to). If the attacker has that kind of > in-band access, why not just block the calls directly with any 4xx/5xx/6xx > response? > Because it's a one-time attack that has persistent effects. My model here is you have some situation where there are a lot of legit robocalls (e.g., for political polling) and the attacker controls some of the networks and so forges a lot of 607s. This gets pushed back to the carrier for the robocaller and they get gagged. You don't need all the networks to have a negative impact. For most commercial VoIP networks (say, residential cable networks or LTE), > the attacker would have to compromise the link-level encryption or install > itself on the end system. (In the latter case, game over, even with TLS.) > > Obviously, TLS is a good idea, but I suspect that making it MUST strength > would essentially preclude the deployment of the mechanism in most > commercial networks. > Well, TLS or not, it's actually a pretty terrible idea to accept 607s unless you are receiving them over a secure network. Regardless of whether there is 2119 normative text, the document should make clear the consequences of it, which are bad. -Ekr I do believe that pointing out the potential issue is worthwhile. Any text > suggestions would be helpful. > > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: Monday, April 24, 2017 3:19 PM > To: The IESG > Cc: draft-ietf-sipcore-status-unwanted@ietf.org; Adam Roach < > adam@nostrum.com>; sipcore-chairs@ietf.org; adam@nostrum.com; > sipcore@ietf.org > Subject: Eric Rescorla's No Objection on draft-ietf-sipcore-status-unwanted-05: > (with COMMENT) > > Eric Rescorla has entered the following ballot position for > draft-ietf-sipcore-status-unwanted-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://urldefense.proofpoint.com/v2/url?u=https-3A__www. > ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICaQ&c= > y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYR > Hfarpk4MK59RE&m=R-ExbCjN2Iez-mZLcWFWH7ctNykRX9QT8S9srcsIRWg > &s=fbA_g7t18zuJQIV-s9kewlLScLl1hh3q7dkdIr2Kn-o&e= > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://urldefense.proofpoint.com/v2/url?u=https-3A__ > datatracker.ietf.org_doc_draft-2Dietf-2Dsipcore- > 2Dstatus-2Dunwanted_&d=DwICaQ&c=y0h0omCe0jAUGr4gAQ02Fw&r= > FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=R-ExbCjN2Iez- > mZLcWFWH7ctNykRX9QT8S9srcsIRWg&s=wCmDT9gXboJAniXB1AeiaDmkEKA4Sb > 3DHt7CXDhIgUM&e= > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > It seems like the security considerations here probably need > to cover what's needed to prevent forged 607 responses. This > seems like an issue for on-path attackers, who could block > the real response and inject a 607. This isn't usually > that great an attack, but if you can use it in a sort of > bounce attack to really gag a sender, that would be bad. > > Probably what's needed here is text about only accepting > 607s over TLS (and filtering at the other endpoint). It's > also worth mentioning that in a post-STIR world, you could > send the PASSporT object as proof of the existence of > the call (though not of its unwantedness). > > > --94eb2c0877165a6d8e054def4f60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 24, 2017 at 1:10 PM, Henning Schulzrinne = <Hennin= g.Schulzrinne@fcc.gov> wrote:
In order to be effective, you'd have to be able to intercept lots of= destinations (since the spammer is likely not reaching all destinations th= at the attacker may have access to). If the attacker has that kind of in-ba= nd access, why not just block the calls directly with any 4xx/5xx/6xx respo= nse?

Because it's a one-time attack= that has persistent effects.

My model here is you= have some situation where there are a lot of legit robocalls
(e.= g., for political polling) and the attacker controls some of the networks a= nd
so forges a lot of 607s. This gets pushed back to the carrier = for the robocaller
and they get gagged. You don't need all th= e networks to have a negative impact.


For most commercial VoIP networks (say, residential cable networks or LTE),= the attacker would have to compromise the link-level encryption or install= itself on the end system. (In the latter case, game over, even with TLS.)<= br>
Obviously, TLS is a good idea, but I suspect that making it MUST strength w= ould essentially preclude the deployment of the mechanism in most commercia= l networks.

Well, TLS or not, it's = actually a pretty terrible idea to accept 607s unless you are receiving the= m over a secure network. Regardless of whether there is 2119 normative text= , the document should make clear the consequences of it, which are bad.

-Ekr



I do believe that pointing out the potential issue is worthwhile. Any text = suggestions would be helpful.

-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Monday, April 24, 2017 3:19 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ie= tf-sipcore-status-unwanted@ietf.org; Adam Roach <adam@nostrum.com>; sipcore-chairs@ietf.org; adam@nostrum.com; sipcore@iet= f.org
Subject: Eric Rescorla's No Objection on draft-ietf-sipcore-status-unwanted-05: (with COMMENT)

Eric Rescorla has entered the following ballot position for
draft-ietf-sipcore-status-unwanted-05: No Objection

When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.)


Please refer to https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=3D= DwICaQ&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX= 8lDU1XeHIYRHfarpk4MK59RE&m=3DR-ExbCjN2Iez-mZLcWFWH7ctNykRX9QT= 8S9srcsIRWg&s=3DfbA_g7t18zuJQIV-s9kewlLScLl1hh3q7dkdIr2Kn-o&a= mp;e=3D
for more information about IESG DISCUSS and COMMENT positi= ons.


The document, along with other ballot positions, can be found here:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A_= _datatracker.ietf.org_doc_draft-2Dietf-2Dsipcore-2Dstatus-2D= unwanted_&d=3DDwICaQ&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DF= JcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DR-ExbCjN2Iez-m= ZLcWFWH7ctNykRX9QT8S9srcsIRWg&s=3DwCmDT9gXboJAniXB1AeiaDmkEKA= 4Sb3DHt7CXDhIgUM&e=3D



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

It seems like the security considerations here probably need
to cover what's needed to prevent forged 607 responses. This
seems like an issue for on-path attackers, who could block
the real response and inject a 607. This isn't usually
that great an attack, but if you can use it in a sort of
bounce attack to really gag a sender, that would be bad.

Probably what's needed here is text about only accepting
607s over TLS (and filtering at the other endpoint). It's
also worth mentioning that in a post-STIR world, you could
send the PASSporT object as proof of the existence of
the call (though not of its unwantedness).



--94eb2c0877165a6d8e054def4f60-- From nobody Mon Apr 24 14:21:33 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 4E3AC13193F for ; Mon, 24 Apr 2017 14:21:31 -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 Jbyb_SXK7Hzo for ; Mon, 24 Apr 2017 14:21:30 -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 043031294A6 for ; Mon, 24 Apr 2017 14:21:29 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-08v.sys.comcast.net with SMTP id 2lPKdt3mmAfZs2lQHdhSAI; Mon, 24 Apr 2017 21:21:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1493068889; bh=QCu0hiMCks0OrwOcPQsudVHFKz5YBCronwFPXiwPkGY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ZQGEBCKgRyuwoY8VeJXGPKpZOBCg5WGbwYxcQwwg/yhC+jge0a3NfYZQZ1r5DGZ4/ 2LZHl6uDOSw+LOwD0SABlf7u+7egy7ZJfuOsAjpMKo6MW5AwLQa790h0SFfllojM3V qbgaheUOXvvws2fjHhLBk85wfhuUPvc1T7FQ50SzI+Ld+QxxSAL6+0/gd7090tvy7M usrvIKJDWFxFQNdoBauOicQxwGBpDUEwkXgXyqb1je0aOnCTTtiCt69gs1Gg4VG8f/ egv0eBEDhjVtqJIr0Czxh3ARj0LaEuu+C2n0iozfna6IxbO07jt6hjBYiqA639Hpk4 GniY41TGtfIhA== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-06v.sys.comcast.net with SMTP id 2lQGdmXg8eyvG2lQGdAnVg; Mon, 24 Apr 2017 21:21:29 +0000 To: sipcore@ietf.org References: <149273874370.22236.10629947769781911054@ietfa.amsl.com> <45b9eaee-ccaa-89b1-80de-d3dd00023485@comcast.net> From: Paul Kyzivat Message-ID: <02f8d1d1-5f1b-bb6a-d00e-78ea0048ca13@comcast.net> Date: Mon, 24 Apr 2017 17:21:28 -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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfKyWTLwbPzl1yZkpJIlWCbjdDbgD9bZ96JrHmxvx8DuXCb3kzzAd5dausNIWJm9cNKPEtEmJNu4+bItmv6CGGwyv3vJ8lyW1SSJLLQsRixKyGjabBq2B ELkzqjEf+0bK8SZZzqyLe3Q4nSiOghBRiFL53R6+1rPxL28s5/JjN5CzgXD5QSBSmYI3UbphBEpQRw== Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-05.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, 24 Apr 2017 21:21:31 -0000 On 4/22/17 6:19 PM, Henning Schulzrinne wrote: > This is meant to be a general description, not specific to the SIP > response or the UA. The idea, I think, was that people wanted to > emphasize that the 'unwanted' response was just one of several inputs. > But this context got lost in the editing. > > > Would prefixing this with "The mechanism described here is only one of > many inputs likely to be used for dealing with unwanted calls." address > the ambiguity? That would help. I think what is missing is any mention that the 607 responses are expected to be used as input to a process for *predicting* when *future* calls will be unwanted. Thanks, Paul > Henning > > ------------------------------------------------------------------------ > *From:* Paul Kyzivat > *Sent:* Saturday, April 22, 2017 3:00:11 PM > *To:* Henning Schulzrinne > *Cc:* sipcore@ietf.org > *Subject:* Re: [sipcore] I-D Action: > draft-ietf-sipcore-status-unwanted-05.txt > > I find the following from section 4 to be a bit odd/confusing: > > Call handling for unwanted calls is likely to involve a combination > of heuristics, analytics, and machine learning. These may use call > characteristics such as call duration and call volumes for a > particular caller, as well changes in those metrics over time, as > well as user feedback. Implementations will have to make appropriate > trade-offs between falsely labeling a caller as unwanted and > delivering unwanted calls. > > Is this intending to discuss automated behavior of the called party UA, > or behavior of the called party, or something else? > > ISTM that "heuristics, analytics, and machine learning" are more likely > to be applied by a middle box than the called UA. In a middle box those > will be used to trigger coding per the callinfo-spam draft, which is > outside the scope of this document. > > Presumably the called UA may use some techniques to decide to > automatically generate a 607 response. The most likely I can think of is > for it to remember a 607 was previously generated for this caller and to > repeat it automatically for future calls from the same caller. > > Perhaps simply changing "Call handling for unwanted calls" to "Automatic > recognition of unwanted calls". But that may be too simplistic. > > Otherwise this version seems good to me. > > Thanks, > Paul > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Apr 25 04:16:03 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 CCAAF12EBE5; Tue, 25 Apr 2017 04:15:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149311895378.5963.11691071118079657190@ietfa.amsl.com> Date: Tue, 25 Apr 2017 04:15:53 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-content-id-02.txt 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: Tue, 25 Apr 2017 11:15:54 -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-02.txt Pages : 8 Date : 2017-04-25 Abstract: This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP). The document also updates RFC 5621, to enable a Content-ID URL to refer a complete message-body and metadata provided by some additional SIP header fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-content-id/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-content-id-02 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-content-id-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-content-id-02 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 Apr 25 04:20: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 2126812EBFA for ; Tue, 25 Apr 2017 04:20:42 -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, 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 bi1KW8jk5fup for ; Tue, 25 Apr 2017 04:20:41 -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 A9B1112EBF9 for ; Tue, 25 Apr 2017 04:20:40 -0700 (PDT) X-AuditID: c1b4fb25-2b64e98000004efc-12-58ff310614ba Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id E5.59.20220.6013FF85; Tue, 25 Apr 2017 13:20:38 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0339.000; Tue, 25 Apr 2017 13:18:49 +0200 From: Christer Holmberg To: "sipcore@ietf.org" CC: SIPCORE Chairs Thread-Topic: Draft new version: draft-content-id-02 Thread-Index: AQHSvbW2ejJQH2w6TEuooK5kbTsKXA== Date: Tue, 25 Apr 2017 11:18:48 +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.2.170228 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D5250C611BA80christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7pS6b4f8Ig7YFGhanXp1mtvj6YxOb A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJXRucW74Chfxc33F5gaGNfwdDFyckgImEgs aLvD2MXIxSEksJ5R4nX7eRYIZwmjxKzlK1m7GDk42AQsJLr/aYM0iAhoSiz/tpUdxGYWMJJY cO8DE4gtLKAvMffoNnaIGhOJtjnbWCBsPYkfS7ezgtgsAqoSG282gdXwClhLvO7tZwOxGQXE JL6fWsMEMVNc4taT+UwQxwlILNlznhnCFpV4+fgf2BxRoJn7/n1lg4grSfzYcIkFojdBYsWt LWwQ8wUlTs58wjKBUXgWkrGzkJTNQlIGETeQeH9uPjOErS2xbOFrKFtfYuOXs4wQtrXE/PaP LMhqFjByrGIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjKqDW36r7mC8/MbxEKMAB6MSD+8D ln8RQqyJZcWVuYcYJTiYlUR4L4GEeFMSK6tSi/Lji0pzUosPMUpzsCiJ8zruuxAhJJCeWJKa nZpakFoEk2Xi4JRqYDQwnSiXHnVSbLdCqU77l0NLV/14dDJr4r3ApGftH/0f3nnqtf103/qd 9w8qp7oLVS7f9sBUe9W2Gg8jp0n7Hu/kFHEO49uydL8P35JTTjuiOx6eDTj1jzOgdestI+ao S5enKhnNXdv/bnt0/YSYiqrjXk7Vh4R7EnKON0q/uWQ704cz+cqlrTVKLMUZiYZazEXFiQCL drMzpgIAAA== Archived-At: Subject: [sipcore] Draft new version: draft-content-id-02 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, 25 Apr 2017 11:20:42 -0000 --_000_D5250C611BA80christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Based on the comments and feedback, we=92ve submitted a new version (-02) o= f draft-content-id. We believe the comments given by different people have now been addressed i= n some form (please let us know if we=92ve missed something), and that the = draft is ready to move forward. Regarding Paul=92s suggestion to register everything as mime extension head= ers, we believe that would be a much bigger task, way outside the scope of = THIS work. Regards, Christer --_000_D5250C611BA80christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <66C3C831AF9C074A997DE3926E1FD8A1@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Based on the comments and feedback, we=92ve submitted a new version (-= 02) of draft-content-id.

We believe the comments given by different people have now been addres= sed in some form (please let us know if we=92ve missed something), and that= the draft is ready to move forward. 

Regarding Paul=92s suggestion to register everything as mime extension= headers, we believe that would be a much bigger task, way outside the scop= e of THIS work.

Regards,

Christer
--_000_D5250C611BA80christerholmbergericssoncom_-- From nobody Tue Apr 25 04:36: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 75C0112EBD6 for ; Tue, 25 Apr 2017 04:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.498 X-Spam-Level: X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.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 VUktU27SMa_w for ; Tue, 25 Apr 2017 04:36:08 -0700 (PDT) Received: from mx0a-001d8301.pphosted.com (mx0a-001d8301.pphosted.com [67.231.149.199]) (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 C668D1296CF for ; Tue, 25 Apr 2017 04:29:43 -0700 (PDT) Received: from pps.filterd (m0103510.ppops.net [127.0.0.1]) by mx0a-001d8301.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v3PBOFbI017113 for ; Tue, 25 Apr 2017 07:29:41 -0400 Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) by mx0a-001d8301.pphosted.com with ESMTP id 2a03wvafvr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 25 Apr 2017 07:29:41 -0400 Received: by mail-lf0-f70.google.com with SMTP id j142so27126771lfg.8 for ; Tue, 25 Apr 2017 04:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to; bh=a0kUjdVI5wSx6OzQyVf8NYP46+27dO1oeQiticBuKkk=; b=sN0AdKB38sk6ULxZqMAXYp9+oXw8H6GbAA9t3HxcUKkqS3txwbh5mtWk2X8fy07fMZ g/3DVMCazO8yMFDQg9wkF3H5O8xBzTQK+A8X4xWLSeivwyHpKt94vIgjhaNtzlMhyVUh yJHpr9AkGUKOhGPhk438+4nNaPhwejC+03lM3Xw85lwrmCsu/RvK9ir5foPd2y+4ZBfa t5MctCSo6OO29ods1+l81U1drKI20DDOhmLE4eDTLcSSXbpKE7dg5EKAIo67c8Q4ER+L Qg3mL5O0QODile+b03euANhKhFoGp44BGWFQhAnW3vocWLfIZ5lHxNvnIZufIBLD43Lg Wjcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to; bh=a0kUjdVI5wSx6OzQyVf8NYP46+27dO1oeQiticBuKkk=; b=ROQr3YhKbHjv1HcAhmtlPO8L508S4JpaXGu5F/C2w/2t5MQ/gYUp5zizJ5DQaeWDvO cvXbOD2uWfBG4HwClDBfwbD6HqLH0JPKWU2gQ/4YY/g9+YCZHPyc3PbqloYsCb/8p1/b XKcKH4clGSu7Uw/C0LwWZf/ndz034ChRLCWqLrw1tyK91hWbA64YJfwKZp/zcWeH10B8 Q0G7LBkXscu99pp8PL3rup2iRibiSiJlj8qlRpRwn9dbwJv7G3VpDbRj07sNIoft5w0f 8eKFfXbCPDPrxaLQJxh+l2lf2Z3CpW8FKW2yJ8Ow1SoGnnrc4HT8NZJAN5/KruMbX0R1 0Ppw== X-Gm-Message-State: AN3rC/73X9is/J9oEaFnsJ8OSSXybNpXUnmia+toRyzaAhZ5jsJAW70v kyocDugY0hLfy37Pl56F9irwlCac17r7XJAjUhyV/vSNrDGl2zCEv1H1Go2UPwt7AlwYvOaf8ws usY0xaEDV+whA X-Received: by 10.46.84.5 with SMTP id i5mr11050664ljb.76.1493119778918; Tue, 25 Apr 2017 04:29:38 -0700 (PDT) X-Received: by 10.46.84.5 with SMTP id i5mr11050658ljb.76.1493119778660; Tue, 25 Apr 2017 04:29:38 -0700 (PDT) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdK9txZKvgsHFxXWQt+PqXgjqsM01g== Date: Tue, 25 Apr 2017 07:29:37 -0400 Message-ID: To: sipcore@ietf.org, draft-ietf-sipcore-status-unwanted@ietf.org Content-Type: text/plain; charset=UTF-8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-25_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [sipcore] draft-ietf-sipcore-status-unwanted-05: comment 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, 25 Apr 2017 11:36:09 -0000 Hi, Concerning draft-ietf-sipcore-status-unwanted-05 section 6, the RFC3665 reference should likely be replaced by another RFC (such as RFC 5359 or RFC 5589) since RFC 3665 does not mention call transfer. Thanks, Brett From nobody Tue Apr 25 08:20:16 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 1CC9C131567; Tue, 25 Apr 2017 08:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 I3Duas_Soloh; Tue, 25 Apr 2017 08:20:12 -0700 (PDT) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (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 E0FA2131576; Tue, 25 Apr 2017 08:20:12 -0700 (PDT) Received: from pps.filterd (m0102172.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3PFJuXr023544; Tue, 25 Apr 2017 15:20:09 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0018.outbound.protection.outlook.com [23.103.198.18]) by mx0a-0024ed01.pphosted.com with ESMTP id 2a00b02bvn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 25 Apr 2017 15:20:09 +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=lo9TH5yXOQYxEjo/t0SVH/H94azka62ivkXPb9d8hVY=; b=pK+RnIeFhplgrdD1asidy5NWeX7T+36lST2mZz2VtlEplhRv6eXWNQdAnTg8SA3HEEMm0WBN2u802Kh3i8gbaGTHnV2gVffLVVXBNt9WX+MnlY3ggTZsPTQbzShynnyzTX2fJy80LSuQYNsBF/Vx+Isv6+P3/hfDLPlgW52XpFQ= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0633.namprd09.prod.outlook.com (10.160.151.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Tue, 25 Apr 2017 15:20:08 +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.1047.019; Tue, 25 Apr 2017 15:20:08 +0000 From: Henning Schulzrinne To: Brett Tate , "sipcore@ietf.org" , "draft-ietf-sipcore-status-unwanted@ietf.org" Thread-Topic: draft-ietf-sipcore-status-unwanted-05: comment Thread-Index: AdK9txZKvgsHFxXWQt+PqXgjqsM01gAIErob Date: Tue, 25 Apr 2017 15:20:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: broadsoft.com; dkim=none (message not signed) header.d=none;broadsoft.com; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [128.59.13.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 7:0lOc2fL18IaubFfizvbPj6ZVl8DMT7YZ0nLf+ibfq7PraUBPuzruazFf7d71ZOUlWClVwpBM9AEkEiFkv8EuAAyX8xpprQggTiFwA/YSoB0nTCnzWuw3b22djpm4zxTiOSRcdFF8Z3/2y4bugIRIH0P7sqZL3X4pmfAsOh6i2rltWw1SWlFg0Q04qIf8utiAC5Oadvdh8NO/mkKvCCRJqkhTiWxt1ic+ObzZOlc1lEMstQrTAdWb4DRh7TX/IxupZOTRS+7xKkK8zLLzSBWPrDxcNIP1qXq9lyRVAKBTyaa1xmy48j5hH1ik6edNQxbTd4JOSoGxjmHp9fpfTmGjyw== x-ms-office365-filtering-correlation-id: be79f440-8f74-4793-bc8a-08d48bee8f0a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR09MB0633; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39410400002)(39400400002)(377454003)(122556002)(7696004)(7736002)(25786009)(50986999)(76176999)(2900100001)(77096006)(54356999)(74316002)(6506006)(53546009)(2906002)(230783001)(189998001)(33656002)(6116002)(2950100002)(102836003)(3846002)(229853002)(3280700002)(38730400002)(3660700001)(99286003)(81166006)(66066001)(8676002)(2201001)(8936002)(55016002)(9686003)(54896002)(2501003)(6436002)(86362001)(5660300001)(6246003)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634BF9F2E40784F22E0E9C1EA1E0CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2017 15:20:08.1232 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-25_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-05: comment 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, 25 Apr 2017 15:20:15 -0000 --_000_CY1PR09MB0634BF9F2E40784F22E0E9C1EA1E0CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll be replacing RFC 3665 with RFC 5359. ________________________________ From: Brett Tate Sent: Tuesday, April 25, 2017 7:29:37 AM To: sipcore@ietf.org; draft-ietf-sipcore-status-unwanted@ietf.org Subject: draft-ietf-sipcore-status-unwanted-05: comment Hi, Concerning draft-ietf-sipcore-status-unwanted-05 section 6, the RFC3665 reference should likely be replaced by another RFC (such as RFC 5359 or RFC 5589) since RFC 3665 does not mention call transfer. Thanks, Brett --_000_CY1PR09MB0634BF9F2E40784F22E0E9C1EA1E0CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I'll be replacing RFC 3665 with RFC 5359.

From: Brett Tate <bret= t@broadsoft.com>
Sent: Tuesday, April 25, 2017 7:29:37 AM
To: sipcore@ietf.org; draft-ietf-sipcore-status-unwanted@ietf.org Subject: draft-ietf-sipcore-status-unwanted-05: comment
 
Hi,

Concerning draft-ietf-sipcore-status-unwanted-05 section 6, the RFC3665
reference should likely be replaced by another RFC (such as RFC 5359 or
RFC 5589) since RFC 3665 does not mention call transfer.

Thanks,
Brett
 --_000_CY1PR09MB0634BF9F2E40784F22E0E9C1EA1E0CY1PR09MB0634namp_-- From nobody Tue Apr 25 10:21: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 CC7901316DF for ; Tue, 25 Apr 2017 10:21:00 -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 5RHTrIusKPf3 for ; Tue, 25 Apr 2017 10:20:59 -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 8B5AA131709 for ; Tue, 25 Apr 2017 10:20:01 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-08v.sys.comcast.net with SMTP id 347yduMX5AfZs3488djoaE; Tue, 25 Apr 2017 17:20:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1493140800; bh=IA1wOJvioe2OoaPxfTJSm17CE/SWyFLhYeGSQGDOyhk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=B+35psFarqwhLXDicP5IYisi/meVfSiuLA3xunchwosnw3Q+WfM2jFYYl1w2g3pEM NfAslhAFtl64T9GSZO4fvkyIpp2QLve++YyVFD5xHEBKqicgU5QsdSnAygLKJJ45Zh 1nx8IW94ZgJqOZ50coyu6bOiOgS8fPebUgzqOt93QjwaOjUYT7EVUNDkustVZq90mr PxZilRpaoTWHK1F9nDg3oTuhUEglnDuz4rll+OhkbDnZFCNboIotvryU8oZsXienGR n633cJDVK4d2dcay3hZYFKHQXLmSwMYvf92kronodsmkm6Y7hZqccqGnh0o3u6wOBN uZhPPdwEJmwyg== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-02v.sys.comcast.net with SMTP id 3487dFtuzgFBH3488dVrgH; Tue, 25 Apr 2017 17:20:00 +0000 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: Date: Tue, 25 Apr 2017 13:19:59 -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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfATigTToy9wbcAWLz0zAKLh2Kq2XzGCXUcYv2+fYvmbMCPsccqp0PbwJvG5bp3cI/vv5FoA1llflWLsx/4K0j0KVZ7fXZ6u/8amm/QhzGTZK+g+l7BoJ L66zHtX3k/TqIPbs2LntJVo6P/n8rvBMpuVBGyp70OPr4EOMEZNqxTi92XCnt4TsIqGI8pgbpNXkLA== Archived-At: Subject: Re: [sipcore] Draft new version: draft-content-id-02 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, 25 Apr 2017 17:21:01 -0000 I'm generally ok with this now. Just a couple of things: General: Widely within the document the use of "refer" is a little off wrt English usage. I suggest replacing it with "reference". Section 3.3: ISTM it would be better to say the content-id identifies all the metadata identified by any header fields beginning with "Content-" as well as header fields identified by the compact names "e", "l", and "c". (I don't expect any Content-* header fields defined in the future will get compact names.) This is future-proof, and is consistent with the mime definition of Content-* headers. Thanks, Paul From nobody Tue Apr 25 12:33: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 9F4CD1317A2 for ; Tue, 25 Apr 2017 12:33:25 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.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 ZzFC8gU3hdSC for ; Tue, 25 Apr 2017 12:33:24 -0700 (PDT) Received: from mx0a-001d8301.pphosted.com (mx0b-001d8301.pphosted.com [67.231.157.183]) (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 D8F961317A1 for ; Tue, 25 Apr 2017 12:33:23 -0700 (PDT) Received: from pps.filterd (m0085114.ppops.net [127.0.0.1]) by mx0b-001d8301.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v3PJUYGu024842 for ; Tue, 25 Apr 2017 15:33:21 -0400 Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com [209.85.215.69]) by mx0b-001d8301.pphosted.com with ESMTP id 29yyw1wfgc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 25 Apr 2017 15:33:21 -0400 Received: by mail-lf0-f69.google.com with SMTP id l9so30718927lfb.1 for ; Tue, 25 Apr 2017 12:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to; bh=4YTHfP/8vs4BcQy/EeaJnOFLuIHDaJlfEEkqjrypZlk=; b=UL7n2yenrR0ij//sysioBAZxRg/Yr8KbdOclZ2TKA2nadLNtXMijh+lTkaSFYwraPW J4kYSatPJXVNcxhLN70kUlMaJvBcCYRGlJwiVfBzRE6WkvO7lB8C9uLD313U+YNPxRg6 ECnw6oTe9q5/ont2UpUx4SuM9Cwh4E1Js6sAYy6+TaUOw4LN28N23yXGM8LPu2AB6OA0 1BnHTj+mhy2iwgu38JP3PZBa3FK7TS38dcuyFjYU95fsgOsfDVAl3J28pARORPZZ5sjP fZkTLvJHL4slOTDSFHiSKmOCYsFcl8xEcObveESZK4TzkIMQmv6Zq+TwR2qPCUSo1KdU dj+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to; bh=4YTHfP/8vs4BcQy/EeaJnOFLuIHDaJlfEEkqjrypZlk=; b=Sb5/2ajkUD4Zh994phrVC6/vSsFVES8aSRZHBH8aI5UZFbWLsmOWMUOkTSPviccMx6 fD48Q6NVjhBHqqpK8xXV8Yj+jtk1ICHU0DVwWvV32we2+GGTX0VcXxvazJZ167XfBLp7 W2ewuDgQYWrVnXF03MP6qD0Rku3AkRyDSihcObOuGUXNIdNLMPq+lxjyVJLBhHWyddBt 7seY6kYS66wA9GZtXYGxi+vZclX/Gp1Q12W4nU7G6148hQB++9dNFpR2xNiBC5tYsTzj sE17622ibG1IgrP3pfQy689XPrY0fOtCzME4jJZqGXcKbSWCaAnnYwxtMnaC7ew8wMtK HpEA== X-Gm-Message-State: AN3rC/5pNptGvW/fermO/ndsA/7SVppIUat/pGqhdZL4i8Rteq5GJt8c CRtqpjuuAByJFZWzDWRfFev4Kp1lRrfi1t81v3yRjRrPNd1GmzGV/RUZmJpaVEqBUG+dEdYuPQi NHas8T0EhQmxd X-Received: by 10.46.80.29 with SMTP id e29mr11599489ljb.36.1493148798810; Tue, 25 Apr 2017 12:33:18 -0700 (PDT) X-Received: by 10.46.80.29 with SMTP id e29mr11599481ljb.36.1493148798627; Tue, 25 Apr 2017 12:33:18 -0700 (PDT) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdK9+qkXZF95MvKRQxK/fAYRJCFpow== Date: Tue, 25 Apr 2017 15:33:17 -0400 Message-ID: <15265e4326cc76e50d306f8062585fcf@mail.gmail.com> To: sipcore@ietf.org, draft-ietf-sipcore-status-unwanted@ietf.org Content-Type: text/plain; charset=UTF-8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-25_12:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [sipcore] draft-ietf-sipcore-status-unwanted-05: comment about 666 removal 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, 25 Apr 2017 19:33:25 -0000 Hi, Concerning draft-ietf-sipcore-status-unwanted-05 section 3, the following sentence should potentially be removed since seems more relevant to 666 instead of 607. "The particular response code number was chosen to reflect the distaste felt by many upon receiving such calls." Thanks, Brett From nobody Tue Apr 25 20:00:01 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 7C89A1204DA; Tue, 25 Apr 2017 19:59:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-sipcore-status-unwanted@ietf.org, Adam Roach , sipcore-chairs@ietf.org, adam@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149317559950.28339.16596615531058180395.idtracker@ietfa.amsl.com> Date: Tue, 25 Apr 2017 19:59:59 -0700 Archived-At: Subject: [sipcore] Kathleen Moriarty's No Objection on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) 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, 26 Apr 2017 02:59:59 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-sipcore-status-unwanted-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with EKR's comment and would like to see additional security considerations that spell out the dangers of not sending this over secure network or without mutual authentication (MiTM attack he describes). I was glad to see the explanation for this draft in the shepherd report and ballot text, but think the explanation should be in the draft as well. I was curious about implementations as there is the potential for trouble with this option. It seems like it should be experimental first, but I guess we could always make it historic later if unforeseen problems arise. From nobody Tue Apr 25 20:09: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 96BAB1204DA; Tue, 25 Apr 2017 20:09:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-sipcore-status-unwanted@ietf.org, Adam Roach , sipcore-chairs@ietf.org, adam@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149317616760.24864.481092935925849196.idtracker@ietfa.amsl.com> Date: Tue, 25 Apr 2017 20:09:27 -0700 Archived-At: Subject: [sipcore] Kathleen Moriarty's No Objection on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) 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, 26 Apr 2017 03:09:28 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-sipcore-status-unwanted-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with EKR's comment and would like to see additional security considerations that spell out the dangers of not sending this over secure network or without mutual authentication (MiTM attack he describes). I just noticed the text called out by the SecDir review and would like to know if the following change could be made since it is just part of a list of examples: OLD: or report the calling party identity to consumer complaint databases operated by government authorities. NEW: or report the calling party identity to consumer complaint databases. It doesn't seem necessary to call out government authorities here and there is the potential for abuse with such databases (government or otherwise managed). I was glad to see the explanation for the existence of this draft in the shepherd report and ballot text, but think the explanation should be in the draft as well. I was curious about implementations as there is the potential for trouble with this option. It seems like it should be experimental first, but I guess we could always make it historic later if unforeseen problems arise. From nobody Wed Apr 26 00:03:08 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 C6530131938 for ; Wed, 26 Apr 2017 00:03:06 -0700 (PDT) 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 v1CZkCVhz4Au for ; Wed, 26 Apr 2017 00:03:05 -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 89BAB13192A for ; Wed, 26 Apr 2017 00:02:50 -0700 (PDT) X-AuditID: c1b4fb25-32b6098000005e4a-6c-59004618de75 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id C8.7D.24138.81640095; Wed, 26 Apr 2017 09:02:48 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0339.000; Wed, 26 Apr 2017 09:02:46 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new version: draft-content-id-02 Thread-Index: AQHSvbW2ejJQH2w6TEuooK5kbTsKXKHWM2KAgAEZfIA= Date: Wed, 26 Apr 2017 07:02:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7rq6EG0OkwZElRhYPfvSyWXz9sYnN gclj8uM5jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4f+wSY8Ft9or3/04wNjD2s3UxcnJICJhI zFz+kr2LkYtDSGA9o8SZpVuZIZwljBIHNx5n6mLk4GATsJDo/qcN0iAiECKx/edRVpCwsICt xOT1lhBhO4mv004zg4RFBKwkVswzBAmzCKhKHNi6jQXE5hWwlvjce54VxBYSKJC42tXBCGJz CthLHLjxFcxmFBCT+H5qDROIzSwgLnHryXwmiDMFJJbsOc8MYYtKvHz8D2yOqICexL5/X6Fe UZRof9rACNGrI7Fg9yc2kHOYgfZemawKEdaWWLbwNTPEOYISJ2c+YZnAKDYLybZZSLpnIXTP QtI9C0n3AkbWVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiB8XRwy2/VHYyX3zgeYhTgYFTi 4U0I+x8hxJpYVlyZe4hRgoNZSYQ3XIMhUog3JbGyKrUoP76oNCe1+BCjNAeLkjiv474LEUIC 6YklqdmpqQWpRTBZJg5OqQbG1ovXFNaeKJJ/+u/CZbe9TdUb/1vYTH/7PeBX/D8blYgXM1sC T4jfilh5eJZcd/PiqZWP2cS6P5jfMQ6YtYfNr7bSNFk3TUh6orDCi3R13afZj648Nsw64Lz8 pP/Dpzv3XWX8PuFe8XvOTSy8L5WZNmlkWzoHHyzgFfMI3vk5rsyqTD9IK99QiaU4I9FQi7mo OBEAbrFHJqMCAAA= Archived-At: Subject: Re: [sipcore] Draft new version: draft-content-id-02 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, 26 Apr 2017 07:03:07 -0000 Hi Paul, Thanks for your comments! See inline. >General: > >Widely within the document the use of "refer" is a little off wrt >English usage. I suggest replacing it with "reference". Will fix as suggested. >Section 3.3: > >ISTM it would be better to say the content-id identifies all the >metadata identified by any header fields beginning with "Content-" as >well as header fields identified by the compact names "e", "l", and "c". >(I don't expect any Content-* header fields defined in the future will >get compact names.) This is future-proof, and is consistent with the >mime definition of Content-* headers. I am ok with your suggestion, but in addition to any Content-* header field, I believe we also need to mention the MIME-Version header field. Not sure if we need to mention the compact names - they represent Content-* header fields. We shall talk about the name of the header fields - not how they are encoded. Regards, Christer From nobody Wed Apr 26 01:40: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 88A7B131D6A for ; Wed, 26 Apr 2017 01:40:53 -0700 (PDT) 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 KSSxoF_HZzKG for ; Wed, 26 Apr 2017 01:40:51 -0700 (PDT) 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 743CB131D69 for ; Wed, 26 Apr 2017 01:40:51 -0700 (PDT) X-AuditID: c1b4fb30-af94d9a000001047-01-59005d119e8f Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 83.BD.04167.11D50095; Wed, 26 Apr 2017 10:40:49 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0339.000; Wed, 26 Apr 2017 10:40:48 +0200 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new version: draft-content-id-02 - Paul's comments Thread-Index: AQHSvmjNKMGBh5tjm0a4Pt/k9GGZDw== Date: Wed, 26 Apr 2017 08:40:47 +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.2.170228 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8CD18A7493065A46AE7FE75295C8EACC@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2J7lK5gLEOkwdZPEhYPfvSyWXz9sYnN gclj8uM5jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo49O0RS8ES7oodWw+xNTDO5Oxi5OSQEDCR aDp+kamLkYtDSOAIo8StC4fZIZwljBLXz+1m62Lk4GATsJDo/qcNEhcR6GCUaDx7jB2kW1gg UGLz/C4WEFtEIEji04xWRghbT+LGmaVsIDaLgKrEl6OTweK8AtYS/RMmsYLYjAJiEt9PrWEC sZkFxCVuPZnPBHGRgMSSPeeZIWxRiZeP/4HViwLN3PfvK9g9EgJKEtO2pkG0Aq2aOoUNwraW eHf8IguErS2xbOFrZoi1ghInZz5hmcAoMgvJtllI2mchaZ+FpH0WkvYFjKyrGEWLU4uTctON jPRSizKTi4vz8/TyUks2MQLj5OCW3wY7GF8+dzzEKMDBqMTDmxD2P0KINbGsuDL3EKMEB7OS CO8fX4ZIId6UxMqq1KL8+KLSnNTiQ4zSHCxK4ryO+y5ECAmkJ5akZqemFqQWwWSZODilGhid rlZNtwxNjWPTPXJt1ka2//PPLr/yK/OE/K8r6u8ZnqaJrXtvsinRehV/+nTNvbsL48sUDOuZ F4trPbHdf3LCFccgGZ9NzyewMb9cfP1sRdz3QPluH/YeUQs2/8cyv5Rfzo4vv/+6eg3zQq9t ya+WH35xYqvlgaLIqdufNch2sfjrmZw4qSiixFKckWioxVxUnAgAkqdEuo8CAAA= Archived-At: Subject: Re: [sipcore] Draft new version: draft-content-id-02 - Paul's comments 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, 26 Apr 2017 08:40:53 -0000 Hi, Pull request based on Paul=B9s comments: https://github.com/cdh4u/draft-content-id/pull/4/files Regards, Christer On 26/04/17 10:02, "sipcore on behalf of Christer Holmberg" wrote: >Hi Paul, > >Thanks for your comments! See inline. > >>General: >> >>Widely within the document the use of "refer" is a little off wrt >>English usage. I suggest replacing it with "reference". > >Will fix as suggested. > >>Section 3.3: >> >>ISTM it would be better to say the content-id identifies all the >>metadata identified by any header fields beginning with "Content-" as >>well as header fields identified by the compact names "e", "l", and "c". >>(I don't expect any Content-* header fields defined in the future will >>get compact names.) This is future-proof, and is consistent with the >>mime definition of Content-* headers. > >I am ok with your suggestion, but in addition to any Content-* header >field, I believe we also need to mention the MIME-Version header field. > >Not sure if we need to mention the compact names - they represent >Content-* header fields. We shall talk about the name of the header fields >- not how they are encoded. > > >Regards, > >Christer > > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Apr 26 08:20: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 7ACFD12F255 for ; Wed, 26 Apr 2017 08:20:52 -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 tLzvgAH0mDMi for ; Wed, 26 Apr 2017 08:20:47 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 C461912EE8D for ; Wed, 26 Apr 2017 08:20:42 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-06v.sys.comcast.net with SMTP id 3OiGdG7yOl4eq3OkEdLG2s; Wed, 26 Apr 2017 15:20:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1493220042; bh=8VOus+RtEMsoEFR2c+FQSme8bGnUslHApI2XfTJummg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=WZ5razV+rFDJW3MMRUEiOujRBrIWmKwHLqWbuPng98ZyNOvfYwIi1w6eNdPvJH9Pv OF6rJUaHWtWvJiKyuxZCdn40eBRCf2g2dQWX8qzebOq5Gc1uP7WyLmZ/uFWZHjc6Zf yGy56DzqQ+ROCxfq590QeUHAwM5klYPg6Crjpr6UOtEEAZX0dja8VbVnnoUuBLZ/Oj XtNk+u6JWmgTqm25hAMLt93u6xyrUoVhiqaP/mPuzMxLLMeksaoiJueir6uS9meYvw n0KpWHZZVVhkYQhYHW0BZ3pdjZ92PDWMsG8IXj4K8lOhxJpz+7LVze/poRDmSwKG5e PR4jT6RZZ5Waw== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-09v.sys.comcast.net with SMTP id 3OkCdnLsljCS03OkDdVklG; Wed, 26 Apr 2017 15:20:41 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: From: Paul Kyzivat Message-ID: Date: Wed, 26 Apr 2017 11:20:40 -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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfOAAnMBlbtMNDoNQ05BDgi/xgmMqOKN8Ykh73D0FvcyupJnvFqwtNb+R6g4958jg90mTgNhnYgQ4pDJ0ceNWbuRSUHPAsFiq2qZCEm1ty/KvwFlaGhr8 x7Wv7eoUmq4Rr4SYpmIqgkxaSOrTNyE7E0ocnXy46tT2H/xfg9mCbeiHAPeI7DEWxCPP8AN1jG+MAYp344BAgUfz4tBJugLMAv62+wmcJ1flqQ6yR8AD5yTL Archived-At: Subject: Re: [sipcore] Draft new version: draft-content-id-02 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, 26 Apr 2017 15:20:52 -0000 On 4/26/17 3:02 AM, Christer Holmberg wrote: > Hi Paul, > > Thanks for your comments! See inline. > >> General: >> >> Widely within the document the use of "refer" is a little off wrt >> English usage. I suggest replacing it with "reference". > > Will fix as suggested. > >> Section 3.3: >> >> ISTM it would be better to say the content-id identifies all the >> metadata identified by any header fields beginning with "Content-" as >> well as header fields identified by the compact names "e", "l", and "c". >> (I don't expect any Content-* header fields defined in the future will >> get compact names.) This is future-proof, and is consistent with the >> mime definition of Content-* headers. > > I am ok with your suggestion, but in addition to any Content-* header > field, I believe we also need to mention the MIME-Version header field. > > Not sure if we need to mention the compact names - they represent > Content-* header fields. We shall talk about the name of the header fields > - not how they are encoded. I was just concerned that when describing header fields whose names begin with "Content-" we are indeed talking about how they are represented. Clearly a header field encoded as "e" doesn't begin with "Content-". But maybe there is a generic way to talk about this. Thanks, Paul From nobody Wed Apr 26 08:29: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 BD25C12EC14 for ; Wed, 26 Apr 2017 08:29:00 -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 imdNgyTe_aXc for ; Wed, 26 Apr 2017 08:28:59 -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 88A7612FC16 for ; Wed, 26 Apr 2017 08:28:56 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-03v.sys.comcast.net with SMTP id 3Oofd47QofuM33OsBdO0pr; Wed, 26 Apr 2017 15:28:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1493220535; bh=XHqksZaBh1F0LdioNKSWMfW2NRwQjjK2BmCFqs41sHo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=XWxzA9mUGacXhPWMZL4K+jAwcXVw8h++LPZxTaqtT8Pr5zkAlNlEx5mgaIcWsc5gP 06+dR8PM+tI/HOoUfTDWRF0ZPIl4DXpCthvmdEglZ2fiCQB6roo60qh3KOY+DM7921 3P0o/1hwZw6gM90wI4/BJJkzrkfEW0Z+zJuxmflX94/n3awaElsIzlA4WzhDkMTMj0 63yqMaHBeEU5bs+QTWwUMLplG3xJ990wVSfGsS2fleblz98gODVXFrrFGWDghVkCNl LLuUkzH5rDFagtH2N/3w9lch9XmtpDh2xv4yKsFTxwvi0aqv2gq6ZbWQdnB1L73ztU hCsd6zKpr9GfQ== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-16v.sys.comcast.net with SMTP id 3OsAdQxkA9isy3OsAdP1S8; Wed, 26 Apr 2017 15:28:55 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: From: Paul Kyzivat Message-ID: <440df8b4-b22d-f796-692d-95131ce90b39@comcast.net> Date: Wed, 26 Apr 2017 11:28:53 -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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfCmFXJKKRGmnyng4mf27N/8ISgbCjaD9GBHs9h8WOlQ8F3hNPtCs14UqeCs6uKLEhgbPNtl0m/B5nM2kRPTsBxJhamgYZF/PCBbtDftkxuV7tbEC9N03 TJ/mozWVhaq3Isb7GOOxjEkynR3wXW1hZDW1sSJ1aJVVrEfzyAPZwo7ynBr2FPxR2qjXRnkK2xMox6kDfwgpK3+vwVhwwc3MLMGREpkRntusXX+EXdEbZfZ9 Archived-At: Subject: Re: [sipcore] Draft new version: draft-content-id-02 - Paul's comments 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, 26 Apr 2017 15:29:01 -0000 On 4/26/17 4:40 AM, Christer Holmberg wrote: > > Hi, > > Pull request based on Paul¹s comments: > > https://github.com/cdh4u/draft-content-id/pull/4/files There are still a bunch of instances of "refer" (or variants such as referred, referring) that ought to get the same treatment, including the title line of section 1.2. Note that either "reference" or "refer to" will work. Thanks, Paul From nobody Wed Apr 26 08:56: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 BED4F131480; Wed, 26 Apr 2017 08:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 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] 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 dhXom76VGGXl; Wed, 26 Apr 2017 08:55:45 -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 47F7B13148F; Wed, 26 Apr 2017 08:55:33 -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 v3QFt6Dt011758; Wed, 26 Apr 2017 15:55:28 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 2a2ebbgktv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 26 Apr 2017 15:55:28 +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=L87M8PbHqFmpGwBaqSpm2BZeJdR/UmQXcdMuwX6JmSA=; b=EfM0xT2JYf8JDkXdcbnuebz4OPzHOnwuNwpjqmA/CxmU0sTMz3GlqmqHbjh65bsgvenEY8JZGQOyumq2Mvi/1YiL9tOSLYZEmwaJzSOsSOlHlz7Uf4011PUJZHlyqNK2Co33OHaQzJdBcFpWrVzCHYjdiggsWdtcmwaGDlzJ50M= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0633.namprd09.prod.outlook.com (10.160.151.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Wed, 26 Apr 2017 15:55:27 +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.1047.019; Wed, 26 Apr 2017 15:55:27 +0000 From: Henning Schulzrinne To: Kathleen Moriarty , The IESG CC: "draft-ietf-sipcore-status-unwanted@ietf.org" , Adam Roach , "sipcore-chairs@ietf.org" , "adam@nostrum.com" , "sipcore@ietf.org" Thread-Topic: Kathleen Moriarty's No Objection on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) Thread-Index: AQHSvjqGazdO8I2dJk2K9BFv7NOow6HXzkLQ Date: Wed, 26 Apr 2017 15:55:27 +0000 Message-ID: References: <149317616760.24864.481092935925849196.idtracker@ietfa.amsl.com> In-Reply-To: <149317616760.24864.481092935925849196.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [192.104.54.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 7:eN9/7ckjnJUFB77KF1vKPvHUclvP5l7tPaDCQyaTWwJv7fOlmpbnNhZ0RoerjLoHViQr8E7UWjcqNRIhnvVKYifgQ3CeljDJHud9AltVPIdnnRWh11dHhwteZi3/MEbrCyjEEIOSm9Ljh6rl+aoLZPe/CrxdlJbscwrSjwZ9Nqd/8jfYaTGvyX7sKiEKaTUnO6UmQO4mOGWj10KcvZH75g6So+eNQ3tK5c5LC7vuzaHADp+l/BwDUGmuIBLePkYfiDwbKuqeb+68sf5eplM4M6KQbDqVDMRC5F6KgevisLW7hIeaHYjpKb4165sZrWKY2DiKRn4eltV9EgxlS5/Now== x-ms-office365-filtering-correlation-id: 686d9063-886a-4134-55fd-08d48cbca884 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR09MB0633; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(6072148); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(377454003)(13464003)(81166006)(66066001)(99286003)(3280700002)(229853002)(189998001)(53936002)(38730400002)(3660700001)(6436002)(9686003)(6306002)(6246003)(54906002)(55016002)(8936002)(8676002)(575784001)(86362001)(5660300001)(54356999)(74316002)(77096006)(53546009)(6506006)(25786009)(122556002)(7736002)(2900100001)(7696004)(76176999)(4326008)(305945005)(50986999)(3846002)(33656002)(102836003)(2950100002)(39060400002)(6116002)(2906002)(230783001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2017 15:55:27.3216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-26_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Kathleen Moriarty's No Objection on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) 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, 26 Apr 2017 15:55:56 -0000 SSBoYXZlIHJlbW92ZWQgdGhlICdnb3Zlcm5tZW50JyBwYXJ0LCBhbHRob3VnaCB0aGV5IGFyZSB0 aGUgb25lcyBtb3N0IGxpa2VseSB0byBhcnJlc3Qgc2NhbW1lcnMuLi4NCg0KKFRoZSBjb25jZXJu IGFib3V0IHNwb29maW5nIGhhcyBhbHNvIGJlZW4gYWRkZWQgYmFzZWQgb24gdGhlIGVhcmxpZXIg Y29tbWVudHMuKQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogS2F0aGxlZW4g TW9yaWFydHkgW21haWx0bzpLYXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbV0gDQpTZW50 OiBUdWVzZGF5LCBBcHJpbCAyNSwgMjAxNyAxMTowOSBQTQ0KVG86IFRoZSBJRVNHIDxpZXNnQGll dGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWRAaWV0Zi5vcmc7 IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+OyBzaXBjb3JlLWNoYWlyc0BpZXRmLm9yZzsg YWRhbUBub3N0cnVtLmNvbTsgc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogS2F0aGxlZW4gTW9y aWFydHkncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRl ZC0wNTogKHdpdGggQ09NTUVOVCkNCg0KS2F0aGxlZW4gTW9yaWFydHkgaGFzIGVudGVyZWQgdGhl IGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVz LXVud2FudGVkLTA1OiBObyBPYmplY3Rpb24NCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2Vl cCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJlc3Nl cyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlz IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p ZXRmLm9yZ19pZXNnX3N0YXRlbWVudF9kaXNjdXNzLTJEY3JpdGVyaWEuaHRtbCZkPUR3SUNhUSZj PXkwaDBvbUNlMGpBVUdyNGdBUTAyRncmcj1GSmNWb0RrV001RWlWY1YwUmVYOGxEVTFYZUhJWVJI ZmFycGs0TUs1OVJFJm09QUdHU08zV1RXMUFyRzZ1VnhWLXlPdW1zWXp2bmo1YUVwMGFEbENWM3N1 ayZzPU1WVm1KaEJGTXgtWEhreEpXOVVhUTZVWWFxSTZ6Ym1lY0ZRVXlWMW5rbGcmZT0NCmZvciBt b3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMu DQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNh biBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEc2lw Y29yZS0yRHN0YXR1cy0yRHVud2FudGVkXyZkPUR3SUNhUSZjPXkwaDBvbUNlMGpBVUdyNGdBUTAy Rncmcj1GSmNWb0RrV001RWlWY1YwUmVYOGxEVTFYZUhJWVJIZmFycGs0TUs1OVJFJm09QUdHU08z V1RXMUFyRzZ1VnhWLXlPdW1zWXp2bmo1YUVwMGFEbENWM3N1ayZzPS1vNDlWUDZiNFVRSVkzMFRn R3pKQl9ZcjQ3VnlOTkVza1R5VGVqRWpFY00mZT0gDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01N RU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpJIGFncmVlIHdpdGggRUtSJ3MgY29tbWVudCBhbmQgd291 bGQgbGlrZSB0byBzZWUgYWRkaXRpb25hbCBzZWN1cml0eQ0KY29uc2lkZXJhdGlvbnMgdGhhdCBz cGVsbCBvdXQgdGhlIGRhbmdlcnMgb2Ygbm90IHNlbmRpbmcgdGhpcyBvdmVyIHNlY3VyZQ0KbmV0 d29yayBvciB3aXRob3V0IG11dHVhbCBhdXRoZW50aWNhdGlvbiAoTWlUTSBhdHRhY2sgaGUgZGVz Y3JpYmVzKS4gIA0KDQpJIGp1c3Qgbm90aWNlZCB0aGUgdGV4dCBjYWxsZWQgb3V0IGJ5IHRoZSBT ZWNEaXIgcmV2aWV3IGFuZCB3b3VsZCBsaWtlIHRvDQprbm93IGlmIHRoZSBmb2xsb3dpbmcgY2hh bmdlIGNvdWxkIGJlIG1hZGUgc2luY2UgaXQgaXMganVzdCBwYXJ0IG9mIGENCmxpc3Qgb2YgZXhh bXBsZXM6DQpPTEQ6DQogICBvciByZXBvcnQgdGhlIGNhbGxpbmcgcGFydHkgaWRlbnRpdHkgdG8g Y29uc3VtZXINCiAgIGNvbXBsYWludCBkYXRhYmFzZXMgb3BlcmF0ZWQgYnkgZ292ZXJubWVudCBh dXRob3JpdGllcy4NCk5FVzoNCiAgIG9yIHJlcG9ydCB0aGUgY2FsbGluZyBwYXJ0eSBpZGVudGl0 eSB0byBjb25zdW1lcg0KICAgY29tcGxhaW50IGRhdGFiYXNlcy4NCkl0IGRvZXNuJ3Qgc2VlbSBu ZWNlc3NhcnkgdG8gY2FsbCBvdXQgZ292ZXJubWVudCBhdXRob3JpdGllcyBoZXJlIGFuZA0KdGhl cmUgaXMgdGhlIHBvdGVudGlhbCBmb3IgYWJ1c2Ugd2l0aCBzdWNoIGRhdGFiYXNlcyAoZ292ZXJu bWVudCBvcg0Kb3RoZXJ3aXNlIG1hbmFnZWQpLg0KDQpJIHdhcyBnbGFkIHRvIHNlZSB0aGUgZXhw bGFuYXRpb24gZm9yIHRoZSBleGlzdGVuY2Ugb2YgdGhpcyBkcmFmdCBpbiB0aGUNCnNoZXBoZXJk IHJlcG9ydCBhbmQgYmFsbG90IHRleHQsIGJ1dCB0aGluayB0aGUgZXhwbGFuYXRpb24gc2hvdWxk IGJlIGluDQp0aGUgZHJhZnQgYXMgd2VsbC4gIEkgd2FzIGN1cmlvdXMgYWJvdXQgaW1wbGVtZW50 YXRpb25zIGFzIHRoZXJlIGlzIHRoZQ0KcG90ZW50aWFsIGZvciB0cm91YmxlIHdpdGggdGhpcyBv cHRpb24uICBJdCBzZWVtcyBsaWtlIGl0IHNob3VsZCBiZQ0KZXhwZXJpbWVudGFsIGZpcnN0LCBi dXQgSSBndWVzcyB3ZSBjb3VsZCBhbHdheXMgbWFrZSBpdCBoaXN0b3JpYyBsYXRlciBpZg0KdW5m b3Jlc2VlbiBwcm9ibGVtcyBhcmlzZS4NCg0KDQo= From nobody Wed Apr 26 10:07:59 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 4B1E412704A; Wed, 26 Apr 2017 10:07:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-sipcore-status-unwanted@ietf.org, Adam Roach , sipcore-chairs@ietf.org, adam@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149322647121.14925.7574406005591553723.idtracker@ietfa.amsl.com> Date: Wed, 26 Apr 2017 10:07:51 -0700 Archived-At: Subject: [sipcore] Spencer Dawkins' Yes on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) 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, 26 Apr 2017 17:07:51 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-sipcore-status-unwanted-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Warren - short, clear, and to the point. I agree with EKR and Kathleen about requiring authentication. In this text, Thus, the call is rejected due to the called party's (temporary) disposition. I'm having trouble matching dictionary definitions to the use of "disposition" here. I guess it's an OK use of the word, and I know what's intended based on context clues, but if another word would be clearer, that would be helpful. This text, The particular response code number was chosen to reflect the distaste felt by many upon receiving such calls. is unchanged from the previous version, where the response code number was 666. Is that intentional? Just checking - in this text, The service provider delivering calls or messages to the user issuing the response MAY take a range of actions, for example, add the calling party to a personal blacklist specific to the called party, use the information as input when computing the likelihood that the calling party is placing unwanted calls ("crowd sourcing"), initiate a traceback request, or report the calling party identity to consumer complaint databases operated by government authorities. there's no standardized way for the called party to signal that this action should be reversed, is there? I ask, because the next paragraph says, The user experience is envisioned to be somewhat similar to email spam buttons where the detailed actions of the email provider remain opaque to the user. and I use the "this is not spam" button on email fairly frequently. The security considerations section does talk about the protected party notifying the service provider using unstandardized mechanisms - I see that. Maybe a forward pointer to that discussion would be helpful. From nobody Wed Apr 26 10:20: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 82AD2131500; Wed, 26 Apr 2017 10:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=GQemiDGA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=djBvRg06 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 4rtXNz2S1bL7; Wed, 26 Apr 2017 10:20:01 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E455B1314CA; Wed, 26 Apr 2017 10:20:00 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5879421AE9; Wed, 26 Apr 2017 13:20:00 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 26 Apr 2017 13:20:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=CmG74M5yLRQIOVHQe1 tdNMJimFLjUmtXEaSfTRhszhU=; b=GQemiDGAKq0vz0XMnshGg9G47TSRycG5jT 0SOeAnI5Rge6gZrbO1efIzYN7aZ9XT25l7ZN2+utOjuXD/DTqFLh69Ar85hwbX9X BkNCpmoF3TziMhyUdx9hNRO2oJWDVrBMjdUlwA5jxHxfByQgfyRYf+nzKYbfB6pa Vou0zNaslzErJaWvLWZv13ied87d3DTwID4Gdc+SEkQ7RXmXgxo74U9vTbxzKofW SLIx9UJtTwR8V7THxBrTHbWmabovqPs/rCl6IJGkFNtoTMpJ1nGBxiQ9BJJELisL ATJp0h0a9orrEFeBibi0XWK1w2/aPRqQ10g3qviqIz88IzuReqMg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=CmG74M5yLRQIOVHQe1tdNMJimFLjUmtXEaSfTRhszhU=; b=djBvRg06 bphBr0INyzDBsUQ5J8tEkVr502JYE4m0Cs558SbPup2FOXX1LeSnhfEjmVPyQYx6 l1RBEGhYlXXkwzLYPGiMn+jXoiHY6ZAK+cmwNAorv/RS1CwDY1lzvS33Bgn6FG0p e499U4+KOgwbQXzatDujoIO5qd7JVGo1opIrFPSaSlbNOPjCVAvJYZHcscIGz49s lpQcRK3rHPOXR2zhVaYRn7p3KMFMDfleGe+kF1g55z8+FcXHq718HbLmwbaGRRwZ MymJrKBu1ElbrOyy4MHP7bbgCdtI1zTU6dSbE96A3z2Dy8bfPvnpjJdmUZ72BoQl azNOUdzrymBaxg== X-ME-Sender: X-Sasl-enc: Si42MChYfH/hPJduUUF0y4HQxzKL8Seb28hPCS6Tmmy1 1493227200 Received: from [10.24.116.101] (unknown [128.107.241.169]) by mail.messagingengine.com (Postfix) with ESMTPA id 608787E70C; Wed, 26 Apr 2017 13:19:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <149015426220.3518.3546300688917567228@ietfa.amsl.com> Date: Wed, 26 Apr 2017 13:19:58 -0400 Cc: General Area Review Team , sipcore@ietf.org, draft-ietf-sipcore-status-unwanted.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149015426220.3518.3546300688917567228@ietfa.amsl.com> To: Peter Yee X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sipcore] [Gen-art] Review of draft-ietf-sipcore-status-unwanted-04 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, 26 Apr 2017 17:20:03 -0000 Peter, thanks for your review. Henning, thanks for taking the changes = into account. I have ballotted no-objection. Alissa > On Mar 21, 2017, at 11:44 PM, Peter Yee wrote: >=20 > Reviewer: Peter Yee > Review result: Ready with Nits >=20 > 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. >=20 > For more information, please see the FAQ at >=20 > . >=20 > 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 >=20 > 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. >=20 > The document has a couple of nits, but nothing seriously wrong.=20 > [Ready with nits] >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments:=20 >=20 > 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". >=20 > Page 5, Section 6, 2nd paragraph, 1st sentence: change "extract" to > "exact". >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Apr 27 00:23: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 D5BD4127286 for ; Thu, 27 Apr 2017 00:23:22 -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 Sbd8ILqCmH3g for ; Thu, 27 Apr 2017 00:23:21 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 3F837126BF0 for ; Thu, 27 Apr 2017 00:23:20 -0700 (PDT) X-AuditID: c1b4fb3a-f56d89a000005025-2b-59019c67c6a8 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 44.86.20517.66C91095; Thu, 27 Apr 2017 09:23:19 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0339.000; Thu, 27 Apr 2017 09:23:18 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new version: draft-content-id-02 - Paul's comments Thread-Index: AQHSvmjNKMGBh5tjm0a4Pt/k9GGZD6HXpUaAgAE+RgA= Date: Thu, 27 Apr 2017 07:23:17 +0000 Message-ID: References: <440df8b4-b22d-f796-692d-95131ce90b39@comcast.net> In-Reply-To: <440df8b4-b22d-f796-692d-95131ce90b39@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7t276HMZIg82TeC0e/Ohls/j6YxOb A5PH5MdzGD2WLPnJFMAUxWWTkpqTWZZapG+XwJVx7q9ywR/WikVr17M3ML5g7WLk5JAQMJF4 c2EjYxcjF4eQwBFGiQ+f/7BDOEsYJRYfXMzSxcjBwSZgIdH9TxukQUQgRGL7z6NgzcICgRKb 53exQMSDJD7NaGWEsK0kZk07xgZiswioSpyY9gIszitgLdF3fi9YXEigQGJ373qwXk4Be4mD +7rAahgFxCS+n1rDBGIzC4hL3HoynwniUAGJJXvOM0PYohIvH/8Du0FUQE9i37+vbCBnSggo Sizvl4No1ZL48mMfG4RtLbHqyn4WCFtRYkr3Q3aIcwQlTs58wjKBUWwWkm2zkLTPQtI+C0n7 LCTtCxhZVzGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIExtTBLb+tdjAefO54iFGAg1GJh1fh AUOkEGtiWXFl7iFGCQ5mJRFetVmMkUK8KYmVValF+fFFpTmpxYcYpTlYlMR5HfZdiBASSE8s Sc1OTS1ILYLJMnFwSjUwGqdKiu0yNzyWxKT2w7SlnI/l+94m9gPTLrx4eTuC7fg31VsxBnFx 9uZ//tyK3Mpjecr5eASTvZfeKolO94USLslTVi82Sgs84DYz5Ymmow/PxDaHCR+jf3/fyWbu 8S5ysdM0i6WeuyP7lXJKP686w/Es7Ip4jErM2viZ4ZOMfIom8xn37D6jxFKckWioxVxUnAgA yUdIJaUCAAA= Archived-At: Subject: Re: [sipcore] Draft new version: draft-content-id-02 - Paul's comments 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, 27 Apr 2017 07:23:23 -0000 SGksDQoNClB1bGwgcmVxdWVzdCB1cGRhdGVkLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoN Ck9uIDI2LzA0LzE3IDE4OjI4LCAiUGF1bCBLeXppdmF0IiA8cGF1bC5reXppdmF0QGNvbWNhc3Qu bmV0PiB3cm90ZToNCg0KPk9uIDQvMjYvMTcgNDo0MCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3Jv dGU6DQo+Pg0KPj4gSGksDQo+Pg0KPj4gUHVsbCByZXF1ZXN0IGJhc2VkIG9uIFBhdWyp9nMgY29t bWVudHM6DQo+Pg0KPj4gaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LWNvbnRlbnQtaWQv cHVsbC80L2ZpbGVzDQo+DQo+VGhlcmUgYXJlIHN0aWxsIGEgYnVuY2ggb2YgaW5zdGFuY2VzIG9m ICJyZWZlciIgKG9yIHZhcmlhbnRzIHN1Y2ggYXMNCj5yZWZlcnJlZCwgcmVmZXJyaW5nKSB0aGF0 IG91Z2h0IHRvIGdldCB0aGUgc2FtZSB0cmVhdG1lbnQsIGluY2x1ZGluZw0KPnRoZSB0aXRsZSBs aW5lIG9mIHNlY3Rpb24gMS4yLiBOb3RlIHRoYXQgZWl0aGVyICJyZWZlcmVuY2UiIG9yICJyZWZl cg0KPnRvIiB3aWxsIHdvcmsuDQo+DQo+CVRoYW5rcywNCj4JUGF1bA0KDQo= From nobody Thu Apr 27 05:38: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 5F61A12025C for ; Thu, 27 Apr 2017 05:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_SORBS_SPAM=0.5, 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=broadsoft-com.20150623.gappssmtp.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 Bi6RQtkqNcQH for ; Thu, 27 Apr 2017 05:38:44 -0700 (PDT) Received: from mx0a-001d8301.pphosted.com (mx0a-001d8301.pphosted.com [67.231.149.199]) (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 523BB129447 for ; Thu, 27 Apr 2017 05:38:44 -0700 (PDT) Received: from pps.filterd (m0103510.ppops.net [127.0.0.1]) by mx0a-001d8301.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v3RCZUrT007671 for ; Thu, 27 Apr 2017 08:38:42 -0400 Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) by mx0a-001d8301.pphosted.com with ESMTP id 2a3fv5r58j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 27 Apr 2017 08:38:42 -0400 Received: by mail-lf0-f70.google.com with SMTP id i3so4992815lfh.17 for ; Thu, 27 Apr 2017 05:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to; bh=VqeI/LZVuxJamftB4o5TZpx2IR0Jjg/jryjDMfos2hw=; b=tWhKLCHVKTdZVPIfnv02KSFXknjLkgZRw4qinhFXjTD53G/7UG9g4UJjypdbV3fEFV Ht41+spEEum+R28CsLsYZ3Pw+Z9ofrzwOd3w1Z6rQM729R9+UuFaJ2qwFYxgvqn/9BHy aGb+FGRoiXZG9JsB059sDaoQfj/s1HaTrRlpLfLT11oAflwkm/4A0cpk6Sg4Nndr6R1h rjSLqsF8kNoUDJaaRocfsLFQZrJ6ujfEhA1ejkgrOS8woli3SvsKtTU+5O3+QTaEh8C+ xIt0Vp7RUwtoUWVmgOyB/gDuPAmoOrux29fjG2S3kF+2vYedSP9R+jlTvyhGIpfmy9O9 zXog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to; bh=VqeI/LZVuxJamftB4o5TZpx2IR0Jjg/jryjDMfos2hw=; b=feVvEs/bzEiq3QOLfHKSggKbp1zmLXYIcJp9Bfptm0LOWNpT4xEuMvjFjZvKRfKfdN mY1kYZ+GZpF7VHez8n8QatrFMH8o124/AJ1ZnKSG7Hu8Rme+/7YZGaVQu3oXktWbo9vX avLiR8hKf6/DI+8tglxtImCMAKEn31ns7BIPZzW63Bq//0lXWdewFYl1h6OYqblKIigZ 20cC6QiZ5w158PalMzyyFzVfvKtTBaIH4hKDFWIzIgcbPJqMcY/gCX8jnuzsSVlZaU/H 0k/qOr7IuUdqcc8ccuqlUjtjV9HdDZV5u7U2gvdoHk2npKfdb6NHL+HSqZjs2gQRxR9a rT3Q== X-Gm-Message-State: AN3rC/7JJthcPheLvvAM5BNFYGZa3zro/t01M6N6jwGdu9qgh9v7ZEky wTMl8oHO13/twP2tuPSsZz6kC7BUqeJ0eRqE1WslTkFiH8TSHk6/rLRWoQtmM1X+94GLO8uCRly R8eKWycSQcQhv X-Received: by 10.25.195.17 with SMTP id t17mr1755742lff.165.1493296719464; Thu, 27 Apr 2017 05:38:39 -0700 (PDT) X-Received: by 10.25.195.17 with SMTP id t17mr1755739lff.165.1493296719290; Thu, 27 Apr 2017 05:38:39 -0700 (PDT) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdK/UvW3vK8UI1H8SgWxvU+vbnA59Q== Date: Thu, 27 Apr 2017 08:38:37 -0400 Message-ID: <764c7d0a66ed8fcfe17472219f8e64ac@mail.gmail.com> To: sipcore@ietf.org, draft-yusef-sipcore-digest-scheme@ietf.org Content-Type: text/plain; charset=UTF-8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-27_08:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [sipcore] draft-yusef-sipcore-digest-scheme-05: internationalization 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, 27 Apr 2017 12:38:45 -0000 Hi, Concerning draft-yusef-sipcore-digest-scheme-05, does RFC 7616 section 4 "Internationalization Considerations" apply to SIP? If so, it potentially should be mentioned within the draft. The following link from 2011 discusses some charset ambiguity within SIP authentication. http://www.ietf.org/mail-archive/web/sipcore/current/msg04507.html Thanks, Brett From nobody Thu Apr 27 06:54: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 56E2B127B73 for ; Thu, 27 Apr 2017 06:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 HpZVhrM5gmjT for ; Thu, 27 Apr 2017 06:54:37 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795BC1294F7 for ; Thu, 27 Apr 2017 06:54:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=H3i7EzpgmImxVWRw+mDc2wp5SLO+aVohvtU4/KFUzmoUuzPgUNkbH+B2TVEmNdmGUFaZA0Y00sTfQbdfj7QgpZGyeVopmpTUIDknN2fT31xRxL8hckP4WhX47iV/bxYVWrLuOOAXBf+b/J/EhQfN3aCoBzU+SOh+beADXMWda30=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 27809 invoked from network); 27 Apr 2017 15:54:35 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 27 Apr 2017 15:54:35 +0200 To: Henning Schulzrinne , The IESG References: <149303246277.25889.4535549169926039230.idtracker@ietfa.amsl.com> Cc: "draft-ietf-sipcore-status-unwanted@ietf.org" , Adam Roach , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <95b50d9d-ee9b-1f8d-a270-f09b8d67f24d@kuehlewind.net> Date: Thu, 27 Apr 2017 15:54:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20170427135435.27800.24714@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-sipcore-status-unwanted-05=3A_=28with_COMMENT=29?= 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, 27 Apr 2017 13:54:39 -0000 Hi Henning, yes I understand that there is no good way to enforce one or the other. I was mainly wondering a) what you want to emphasize in the document and make sure the receiver makes the right assumptions about this, and b) if it would make sense to provide a way to distinguish those two cases. Of course that would not guarantee that is would always be indicated correctly but some systems may indicate it if is there is a use cases where this information can be valuable... Mirja On 24.04.2017 16:29, Henning Schulzrinne wrote: > There was an extensive discussion on the "who is responsible" issue on the list. My take is that there's just no good way to know whether the 'unwanted' response was generated by a button press or something semi-automated (e.g., the system pops up a "you hung up very quickly. Was this a spam call?" dialog box) or automated fancy-machine-learning algorithm implemented on the end system. My guess is that manual will be, by far, the most common usage. If I implement ML on the end system for call classification, I probably want to control the experience and thus not muddy the waters by having the network filter, too. > > Practically-speaking, I don't see a good way to enforce any distinction, even leaving aside the possibilities between a fully-manual and invisibly-automatic mechanism. It is also not clear how the network would make use of such a distinction - both humans and machines make mistakes. > > Thus, I think the intent is to use it for human feedback, but without trying to be overly prescriptive. > > That said, the call-info draft may need an extension for the kind of "backward" indication so that an automated call recipient can tell the network how it classified the call. > > Henning > > -----Original Message----- > From: Mirja Kühlewind [mailto:ietf@kuehlewind.net] > Sent: Monday, April 24, 2017 7:14 AM > To: The IESG > Cc: draft-ietf-sipcore-status-unwanted@ietf.org; Adam Roach ; sipcore-chairs@ietf.org; adam@nostrum.com; sipcore@ietf.org > Subject: Mirja Kühlewind's No Objection on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) > > Mirja Kühlewind has entered the following ballot position for > draft-ietf-sipcore-status-unwanted-05: No Objection > > When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) > > > Please refer to https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIDaQ&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=pxuO3nw6kw9wO2J3VMaOn96WscW6Xfx0rezXBVrB6MA&s=MG-50-smFxU54QYl1KNrnRaos5nVAFoDKpM_Fm2l2Ds&e= > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=DwIDaQ&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=pxuO3nw6kw9wO2J3VMaOn96WscW6Xfx0rezXBVrB6MA&s=wU_pnKWunwKpQ87EJo62tgb6DuObf2NsKXmx1SME6N8&e= > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I actually have one mostly technical question: It is not fully clear to > me if the Unwanted response code always indicates a user action or if the > same code is used when an automated system declines the call? My > understanding is that the idea is that this could also be automated if > the user has some kind of control of the system (which is probably hard > to verify). Or would it make sense to distinct between the cases where > the user actively rejects a call or an automated system is generating the > response code (on behalf of the user)? > > From nobody Thu Apr 27 07:52: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 7F8BF12955F for ; Thu, 27 Apr 2017 07:52:13 -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 Dqdb-iE3-V2k for ; Thu, 27 Apr 2017 07:52:11 -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 RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425321296B0 for ; Thu, 27 Apr 2017 07:52:02 -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=/pH4dPjSrFUdYvfpQzQTpWgeT+5G1b9YuQ0+1gr6IqE=; b=s5pFLhNKjj1TQjR1jQaTIhPUWJt47WqijGOsTDMJ+3VX5NU0LC63ZHZGV5I3HU/Q6koDZBvoj4VAkfqNfKvPdj5A6JraTpIsicnCiowmvtKyU56UgYfO66RpViuRBX57jKONxDFoprk/69sAK1D3xtvwhpMy+ydCbDbv1RAgQhU= Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0179.outbound.protection.outlook.com [216.32.180.179]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-67-y0f5nkAaOSi2wWu2cWnACQ-1; Thu, 27 Apr 2017 10:51:58 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Thu, 27 Apr 2017 14:51:56 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1061.013; Thu, 27 Apr 2017 14:51:56 +0000 From: "Asveren, Tolga" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "Henning Schulzrinne" , The IESG CC: "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , "draft-ietf-sipcore-status-unwanted@ietf.org" Thread-Topic: =?utf-8?B?W3NpcGNvcmVdICBNaXJqYSBLw7xobGV3aW5kJ3MgTm8gT2JqZWN0aW9uIG9u?= =?utf-8?B?IGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDU6ICh3aXRo?= =?utf-8?Q?_COMMENT)?= Thread-Index: AQHSvQdOIK26eEN8xU+CASnfkaAc9KHZQYyAgAAJbnA= Date: Thu, 27 Apr 2017 14:51:56 +0000 Message-ID: References: <149303246277.25889.4535549169926039230.idtracker@ietfa.amsl.com> <95b50d9d-ee9b-1f8d-a270-f09b8d67f24d@kuehlewind.net> In-Reply-To: <95b50d9d-ee9b-1f8d-a270-f09b8d67f24d@kuehlewind.net> 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-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:8MwT7T7dTtiPbhC0DS6RMEB9v9iYY1a2zxVc/SPPClTmbXXJqXD1xhXgyt0oJ9qlQEiRISRDSmmpSoUMuR0UPYBMk/OqrZvino/3x+J6auXUTJzBtQFUl907TQ0yBOqIjCpIXy+izjJlZQGzmAVoYNTIs8L8eKYzpQMx0O9jIiG3atOU/bl6cL2+04T9FGS8MjN+pIiKx2Sw0df498d3odvbill/da9DGpOeEgt3sWth1f1LY1bz7CEgwk8GgkPszcJpcnAWTfSx2gEoR6DW82/x0vnbUWlkQyR4YD0UO2z7cHPDt7hq02oaId5jPwvfvrUIPVeCtgRmXjgK3HqX7g==; 20:RDyrGL1AzsTFdk8BdO+NiSSB3XzuANn4Xf+tjN0ewBJgd289b3i9OR/y3GDgwrR5ra4tzEeu12WYbYhmiQML3UPdNM9mXk1ogcAjEqK6CDj5vcQYBObgKCTDxeNFQdbTSMbLDWpTsXZcunIg4Ah7BytLwsyak/aeKdGhxeQsTpI= x-ms-office365-filtering-correlation-id: 6ddc6c86-1ea0-43fb-45f3-08d48d7cf346 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:SN2PR03MB2350; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(6072148); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(39450400003)(39400400002)(39410400002)(377454003)(13464003)(24454002)(38730400002)(189998001)(3280700002)(6246003)(2950100002)(33656002)(2906002)(53936002)(3660700001)(122556002)(86362001)(229853002)(7696004)(575784001)(9686003)(4326008)(76176999)(54356999)(25786009)(66066001)(54906002)(50986999)(53546009)(55016002)(77096006)(224303003)(224313004)(99286003)(5660300001)(74316002)(6306002)(3846002)(8936002)(230783001)(81166006)(305945005)(102836003)(6116002)(6506006)(2900100001)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.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: 27 Apr 2017 14:51:56.1801 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 X-MC-Unique: y0f5nkAaOSi2wWu2cWnACQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-sipcore-status-unwanted-05=3A_=28with_COMMENT=29?= 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, 27 Apr 2017 14:52:13 -0000 SSB0aGluayB0aGUgaW50ZW50IHdhcyBleGNsdXNpdmVseSBmb3IgdGhlIGh1bWFuIGFnZW50IHRv IHByZXNzIGEgYnV0dG9uLiBHcmFudGVkLCB0aGVyZSBpcyBubyB3YXkgdG8gcG9saWNlIHRoaXMg YnV0IHRoaXMgaGFzIGJlZW4gdGhlIHNjZW5hcmlvIHVuZGVyIGNvbnNpZGVyYXRpb24gaW4gdGhl IHBhc3QuIEFueXRoaW5nIG90aGVyIHRoYW4gdGhhdCwgZS5nLiBodW1hbiBhZ2VudCBleGNsdXNp dmVseSBibGFja2xpc3RpbmcgY2VydGFpbiBBb1JzLCBpcyBzdXBwb3NlZCB0byBiZSBoYW5kbGVk IGJ5IG90aGVyIG1lY2hhbmlzbXMsIGUuZy4gYSB3ZWIgcG9ydGFsLg0KDQpUaGUgc2VtYW50aWNz IGZvciA2MDcgaXM6ICJJIGRvbuKAmXQgd2FudCB0aGlzIGNhbGwiLCBub3RoaW5nIG1vcmUsIGF0 IGxlYXN0IEFGQUlVIGFuZCBhZHZvY2F0ZWQgc28gZmFyLiBBY3R1YWxseSB3ZSByZWFsbHkgc2hv dWxkIHNwZWxsIHRoaXMgb3V0IHZlcnkgY2xlYXJseS4gRm9sa3Mgd2hvIGRpZCBub3QgcGFydGlj aXBhdGUgZHVyaW5nIHRoZSBldm9sdXRpb24gb2YgdGhpcyBkb2N1bWVudCBrZWVwIGhhdmluZyBj b25mdXNpb25zIG9uIHRoaXMgaXNzdWUuDQoNClRoYW5rcywNClRvbGdhDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgTWlyamEgS8O8aGxld2luZA0KU2VudDogVGh1cnNkYXksIEFw cmlsIDI3LCAyMDE3IDk6NTUgQU0NClRvOiBIZW5uaW5nIFNjaHVsenJpbm5lIDxIZW5uaW5nLlNj aHVsenJpbm5lQGZjYy5nb3Y+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCkNjOiBzaXBjb3Jl LWNoYWlyc0BpZXRmLm9yZzsgc2lwY29yZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1zaXBjb3JlLXN0 YXR1cy11bndhbnRlZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBNaXJqYSBLw7xo bGV3aW5kJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50 ZWQtMDU6ICh3aXRoIENPTU1FTlQpDQoNCkhpIEhlbm5pbmcsDQoNCnllcyBJIHVuZGVyc3RhbmQg dGhhdCB0aGVyZSBpcyBubyBnb29kIHdheSB0byBlbmZvcmNlIG9uZSBvciB0aGUgb3RoZXIuIEkg d2FzIG1haW5seSB3b25kZXJpbmcgYSkgd2hhdCB5b3Ugd2FudCB0byBlbXBoYXNpemUgaW4gdGhl IGRvY3VtZW50IGFuZCBtYWtlIHN1cmUgdGhlIHJlY2VpdmVyIG1ha2VzIHRoZSByaWdodCBhc3N1 bXB0aW9ucyBhYm91dCB0aGlzLCBhbmQgYikgaWYgaXQgd291bGQgbWFrZSBzZW5zZSB0byBwcm92 aWRlIGEgd2F5IHRvIGRpc3Rpbmd1aXNoIHRob3NlIHR3byBjYXNlcy4gT2YgY291cnNlIHRoYXQg d291bGQgbm90IGd1YXJhbnRlZSB0aGF0IGlzIHdvdWxkIGFsd2F5cyBiZSBpbmRpY2F0ZWQgY29y cmVjdGx5IGJ1dCBzb21lIHN5c3RlbXMgbWF5IGluZGljYXRlIGl0IGlmIGlzIHRoZXJlIGlzIGEg dXNlIGNhc2VzIHdoZXJlIHRoaXMgaW5mb3JtYXRpb24gY2FuIGJlIHZhbHVhYmxlLi4uDQoNCk1p cmphDQoNCg0KDQpPbiAyNC4wNC4yMDE3IDE2OjI5LCBIZW5uaW5nIFNjaHVsenJpbm5lIHdyb3Rl Og0KPiBUaGVyZSB3YXMgYW4gZXh0ZW5zaXZlIGRpc2N1c3Npb24gb24gdGhlICJ3aG8gaXMgcmVz cG9uc2libGUiIGlzc3VlIG9uIHRoZSBsaXN0LiBNeSB0YWtlIGlzIHRoYXQgdGhlcmUncyBqdXN0 IG5vIGdvb2Qgd2F5IHRvIGtub3cgd2hldGhlciB0aGUgJ3Vud2FudGVkJyByZXNwb25zZSB3YXMg Z2VuZXJhdGVkIGJ5IGEgYnV0dG9uIHByZXNzIG9yIHNvbWV0aGluZyBzZW1pLWF1dG9tYXRlZCAo ZS5nLiwgdGhlIHN5c3RlbSBwb3BzIHVwIGEgInlvdSBodW5nIHVwIHZlcnkgcXVpY2tseS4gV2Fz IHRoaXMgYSBzcGFtIGNhbGw/IiBkaWFsb2cgYm94KSBvciBhdXRvbWF0ZWQgZmFuY3ktbWFjaGlu ZS1sZWFybmluZyBhbGdvcml0aG0gaW1wbGVtZW50ZWQgb24gdGhlIGVuZCBzeXN0ZW0uIE15IGd1 ZXNzIGlzIHRoYXQgbWFudWFsIHdpbGwgYmUsIGJ5IGZhciwgdGhlIG1vc3QgY29tbW9uIHVzYWdl LiBJZiBJIGltcGxlbWVudCBNTCBvbiB0aGUgZW5kIHN5c3RlbSBmb3IgY2FsbCBjbGFzc2lmaWNh dGlvbiwgSSBwcm9iYWJseSB3YW50IHRvIGNvbnRyb2wgdGhlIGV4cGVyaWVuY2UgYW5kIHRodXMg bm90IG11ZGR5IHRoZSB3YXRlcnMgYnkgaGF2aW5nIHRoZSBuZXR3b3JrIGZpbHRlciwgdG9vLg0K Pg0KPiBQcmFjdGljYWxseS1zcGVha2luZywgSSBkb24ndCBzZWUgYSBnb29kIHdheSB0byBlbmZv cmNlIGFueSBkaXN0aW5jdGlvbiwgZXZlbiBsZWF2aW5nIGFzaWRlIHRoZSBwb3NzaWJpbGl0aWVz IGJldHdlZW4gYSBmdWxseS1tYW51YWwgYW5kIGludmlzaWJseS1hdXRvbWF0aWMgbWVjaGFuaXNt LiBJdCBpcyBhbHNvIG5vdCBjbGVhciBob3cgdGhlIG5ldHdvcmsgd291bGQgbWFrZSB1c2Ugb2Yg c3VjaCBhIGRpc3RpbmN0aW9uIC0gYm90aCBodW1hbnMgYW5kIG1hY2hpbmVzIG1ha2UgbWlzdGFr ZXMuDQo+DQo+IFRodXMsIEkgdGhpbmsgdGhlIGludGVudCBpcyB0byB1c2UgaXQgZm9yIGh1bWFu IGZlZWRiYWNrLCBidXQgd2l0aG91dCB0cnlpbmcgdG8gYmUgb3Zlcmx5IHByZXNjcmlwdGl2ZS4N Cj4NCj4gVGhhdCBzYWlkLCB0aGUgY2FsbC1pbmZvIGRyYWZ0IG1heSBuZWVkIGFuIGV4dGVuc2lv biBmb3IgdGhlIGtpbmQgb2YgImJhY2t3YXJkIiBpbmRpY2F0aW9uIHNvIHRoYXQgYW4gYXV0b21h dGVkIGNhbGwgcmVjaXBpZW50IGNhbiB0ZWxsIHRoZSBuZXR3b3JrIGhvdyBpdCBjbGFzc2lmaWVk IHRoZSBjYWxsLg0KPg0KPiBIZW5uaW5nDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IE1pcmphIEvDvGhsZXdpbmQgW21haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0XQ0K PiBTZW50OiBNb25kYXksIEFwcmlsIDI0LCAyMDE3IDc6MTQgQU0NCj4gVG86IFRoZSBJRVNHIDxp ZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZEBp ZXRmLm9yZzsgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbT47IHNpcGNvcmUtY2hhaXJzQGll dGYub3JnOyBhZGFtQG5vc3RydW0uY29tOyBzaXBjb3JlQGlldGYub3JnDQo+IFN1YmplY3Q6IE1p cmphIEvDvGhsZXdpbmQncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1 cy11bndhbnRlZC0wNTogKHdpdGggQ09NTUVOVCkNCj4NCj4gTWlyamEgS8O8aGxld2luZCBoYXMg ZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1z aXBjb3JlLXN0YXR1cy11bndhbnRlZC0wNTogTm8gT2JqZWN0aW9uDQo+DQo+IFdoZW4gcmVzcG9u ZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFs bCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwg ZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4NCj4N Cj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX2llc2dfc3RhdGVtZW50X2Rpc2N1c3MtMkRjcml0 ZXJpYS5odG1sJmQ9RHdJRGFRJmM9eTBoMG9tQ2UwakFVR3I0Z0FRMDJGdyZyPUZKY1ZvRGtXTTVF aVZjVjBSZVg4bERVMVhlSElZUkhmYXJwazRNSzU5UkUmbT1weHVPM253Nmt3OXdPMkozVk1hT245 NldzY1c2WGZ4MHJlelhCVnJCNk1BJnM9TUctNTAtc21GeFU1NFFZbDFLTnJuUmFvczVuVkFGb0RL cE1fRm0ybDJEcyZlPQ0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1Mg YW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPg0KPg0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGgg b3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0 Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRHNpcGNvcmUtMkRzdGF0dXMtMkR1bndhbnRlZF8mZD1E d0lEYVEmYz15MGgwb21DZTBqQVVHcjRnQVEwMkZ3JnI9RkpjVm9Ea1dNNUVpVmNWMFJlWDhsRFUx WGVISVlSSGZhcnBrNE1LNTlSRSZtPXB4dU8zbnc2a3c5d08ySjNWTWFPbjk2V3NjVzZYZngwcmV6 WEJWckI2TUEmcz13VV9wbktXdW53S3BRODdFSm82MnRnYjZEdU9iZjJOc0tYbXgxU01FNk44JmU9 DQo+DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pg0KPiBJIGFjdHVhbGx5IGhhdmUgb25lIG1vc3RseSB0ZWNobmljYWwgcXVlc3Rpb246IEl0IGlz IG5vdCBmdWxseSBjbGVhciB0bw0KPiBtZSBpZiB0aGUgVW53YW50ZWQgcmVzcG9uc2UgY29kZSBh bHdheXMgaW5kaWNhdGVzIGEgdXNlciBhY3Rpb24gb3IgaWYgdGhlDQo+IHNhbWUgY29kZSBpcyB1 c2VkIHdoZW4gYW4gYXV0b21hdGVkIHN5c3RlbSBkZWNsaW5lcyB0aGUgY2FsbD8gTXkNCj4gdW5k ZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBpZGVhIGlzIHRoYXQgdGhpcyBjb3VsZCBhbHNvIGJlIGF1 dG9tYXRlZCBpZg0KPiB0aGUgdXNlciBoYXMgc29tZSBraW5kIG9mIGNvbnRyb2wgb2YgdGhlIHN5 c3RlbSAod2hpY2ggaXMgcHJvYmFibHkgaGFyZA0KPiB0byB2ZXJpZnkpLiBPciB3b3VsZCBpdCBt YWtlIHNlbnNlIHRvIGRpc3RpbmN0IGJldHdlZW4gdGhlIGNhc2VzIHdoZXJlDQo+IHRoZSB1c2Vy IGFjdGl2ZWx5IHJlamVjdHMgYSBjYWxsIG9yIGFuIGF1dG9tYXRlZCBzeXN0ZW0gaXMgZ2VuZXJh dGluZyB0aGUNCj4gcmVzcG9uc2UgY29kZSAob24gYmVoYWxmIG9mIHRoZSB1c2VyKT8NCj4NCj4N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNv cmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From nobody Thu Apr 27 08:10:58 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 B12C7129B18; Thu, 27 Apr 2017 08:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 KmDviCJvwh4F; Thu, 27 Apr 2017 08:10:49 -0700 (PDT) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (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 E47C2129B13; Thu, 27 Apr 2017 08:09:33 -0700 (PDT) Received: from pps.filterd (m0102173.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3REnDqn005299; Thu, 27 Apr 2017 14:52:19 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0049.outbound.protection.outlook.com [23.103.198.49]) by mx0a-0024ed01.pphosted.com with ESMTP id 2a2ebchesr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 27 Apr 2017 14:52:19 +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=9OryV6tw+U6kXA1FgzodKR9IoSUo4JoDaVwcVtbmhY4=; b=ptvO9HAxoi/EUxOoPoSXSmFWUJHHsKwCQb+HdrZvqC8Ynha3vnf09g5XrKEZ6n1FQf/LzLxyqi2wSWGMM8aVlOstZwLknmkUEkU+fzHAt6P0MsgRL6bH6LXvLCVyb49fXlaxqascB1rtqTbhQGsbYd5gGaOy8cO6yLtCpbkPkRg= 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_128_CBC_SHA256_P256) id 15.1.1047.13; Thu, 27 Apr 2017 14:52:17 +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.1047.019; Thu, 27 Apr 2017 14:52:17 +0000 From: Henning Schulzrinne To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "draft-ietf-sipcore-status-unwanted@ietf.org" , Adam Roach , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-sipcore-status-unwanted-05:_(with_COMMENT)?= Thread-Index: AQHSvOvw1py7aDhMjEyD7coW+O+7oqHUkcnQgASv+oCAAA4hcA== Date: Thu, 27 Apr 2017 14:52:17 +0000 Message-ID: References: <149303246277.25889.4535549169926039230.idtracker@ietfa.amsl.com> <95b50d9d-ee9b-1f8d-a270-f09b8d67f24d@kuehlewind.net> In-Reply-To: <95b50d9d-ee9b-1f8d-a270-f09b8d67f24d@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kuehlewind.net; dkim=none (message not signed) header.d=none;kuehlewind.net; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [192.104.54.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 7:3YqUYTXABiNvQTwSRTrbMqt+gK4GGe1Fc6LQTYOXcLqhp5GepgbqnDD6RdI0S0+JeGMMuO8qcm2+7t/Xdl6n45ZDnKEXFUlr4T6shj1Eb+H+uQXRZ4gzLhN5BZ7tdrkQNjNsQqUH71pdrUFFz9pnquDnzw9hohtB2efbjshd+1bk20MAr5nBIerDJHWvr9OMjsjaLcCGN8ZAzYCo9t/bekXgAcicw319kKRTFnVMavm1f5uLMkjBe7LgpYbq3tRDUy1mDXNriCU7ZTg9UNUO5qanBvauFi8sxF6RakU4yM5OBGZlwzDBWaZBCnO5bK4BrLc9561VyrpeoYjejDFGNQ== x-ms-office365-filtering-correlation-id: 69944c6e-9f81-4726-cd8e-08d48d7cfff8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR09MB0634; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39450400003)(39840400002)(39410400002)(377454003)(24454002)(13464003)(55016002)(38730400002)(6306002)(99286003)(224303003)(9686003)(54906002)(230783001)(224313004)(2950100002)(6246003)(74316002)(3846002)(102836003)(6116002)(5660300001)(53936002)(53546009)(33656002)(189998001)(122556002)(4326008)(77096006)(3280700002)(3660700001)(66066001)(54356999)(76176999)(50986999)(305945005)(2900100001)(6436002)(575784001)(7696004)(8936002)(229853002)(2906002)(25786009)(81166006)(6506006)(86362001); 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2017 14:52:17.2676 (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-04-27_13:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-sipcore-status-unwanted-05=3A_=28with_COMMENT=29?= 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, 27 Apr 2017 15:10:57 -0000 TWlyamEsDQoNCk9uZSBvZiBteSBjb25jZXJucyBpcyBzaW1wbGljaXR5IC0gSSB3YW50IHRvIGtl ZXAgdGhlIG1lY2hhbmlzbXMgYXMgbWluaW1hbCBhbmQgc3RyYWlnaHRmb3J3YXJkIGFzIHBvc3Np YmxlLCB0byBlbmNvdXJhZ2UgcmFwaWQgaW1wbGVtZW50YXRpb24uIFNpbmNlIHdlIGFyZSBhdCB0 aGUgYmVnaW5uaW5nIG9mIGNvbnN1bWVyLWxldmVsIHVud2FudGVkIGNhbGwgZmlsdGVyaW5nLCBt eSB0YWtlIGlzIHRvIGdhaW4gc29tZSBleHBlcmllbmNlIGFuZCB0aGVuIGFkZCBtZWNoYW5pc21z LiBGb3IgZXhhbXBsZSwgZm9yIGFueSBhdXRvbWF0ZWQgbWVjaGFuaXNtcywgeW91J2QgcHJvYmFi bHkgd2FudCBtb3JlIGRldGFpbHMgYXMgdG8gdGhlICJ3aHkiLCBwcmltYXJpbHkgdG8gZGVhbCB3 aXRoIG1pcy1jbGFzc2lmaWNhdGlvbiBhbmQgdG8gZW5zdXJlIGRlbGl2ZXJhYmlsaXR5IG9mIGNh bGxzLiAoIlRoaXMgZ29vZCBjYWxsIHdhcyBqdXN0IGNsYXNzaWZpZWQgYXMgc3BhbSAtIHdoYXQg bWFkZSB0aGF0IGhhcHBlbj8iKSBUaGlzIGlzIHNvbWV3aGF0IHNpbWlsYXIgdG8gdGhlIGVtYWls IHByb2JsZW0sIHdoZXJlIHRoZSBnb29kIGd1eXMgbmVlZCBpbmZvcm1hdGlvbiB0byBhdm9pZCBh Y2NpZGVudGFsbHkgdHJpcHBpbmcgc3BhbSBmaWx0ZXJzICgiZml4IHlvdXIgU1BGIGVudHJ5Iiwg Im1ha2Ugc3VyZSB0aGF0IHRoZSBoZWFkZXIgZm9ybWF0IGlzIHVwIHRvIGN1cnJlbnQgc3RhbmRh cmRzIHJhdGhlciB0aGFuIHRoZSAxOTgwcyB2ZXJzaW9uIiwgImNoZWNrIHdoeSB5b3UgZW5kZWQg dXAgb24gdGhpcyBibGFja2xpc3QiKS4NCg0KQnV0IEkgZG9uJ3QgdGhpbmsgd2UgdW5kZXJzdGFu ZCB3ZWxsIGVub3VnaCBob3cgdG8gcHJvdmlkZSBzdWNoIGZlZWRiYWNrIGZvciBWb0lQIGF0IHRo aXMgcG9pbnQuDQoNCkhlbm5pbmcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IE1pcmphIEvDvGhsZXdpbmQgW21haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0XSANClNlbnQ6IFRo dXJzZGF5LCBBcHJpbCAyNywgMjAxNyA5OjU1IEFNDQpUbzogSGVubmluZyBTY2h1bHpyaW5uZSA8 SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292PjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpD YzogZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZEBpZXRmLm9yZzsgQWRhbSBSb2Fj aCA8YWRhbUBub3N0cnVtLmNvbT47IHNpcGNvcmUtY2hhaXJzQGlldGYub3JnOyBzaXBjb3JlQGll dGYub3JnDQpTdWJqZWN0OiBSZTogTWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBk cmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVzLXVud2FudGVkLTA1OiAod2l0aCBDT01NRU5UKQ0KDQpI aSBIZW5uaW5nLA0KDQp5ZXMgSSB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgaXMgbm8gZ29vZCB3YXkg dG8gZW5mb3JjZSBvbmUgb3IgdGhlIG90aGVyLiBJIHdhcyBtYWlubHkgd29uZGVyaW5nIGEpIHdo YXQgeW91IHdhbnQgdG8gZW1waGFzaXplIGluIHRoZSBkb2N1bWVudCBhbmQgbWFrZSBzdXJlIHRo ZSByZWNlaXZlciBtYWtlcyB0aGUgcmlnaHQgYXNzdW1wdGlvbnMgYWJvdXQgdGhpcywgYW5kIGIp IGlmIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gcHJvdmlkZSBhIHdheSB0byBkaXN0aW5ndWlzaCB0 aG9zZSB0d28gY2FzZXMuIE9mIGNvdXJzZSB0aGF0IHdvdWxkIG5vdCBndWFyYW50ZWUgdGhhdCBp cyB3b3VsZCBhbHdheXMgYmUgaW5kaWNhdGVkIGNvcnJlY3RseSBidXQgc29tZSBzeXN0ZW1zIG1h eSBpbmRpY2F0ZSBpdCBpZiBpcyB0aGVyZSBpcyBhIHVzZSBjYXNlcyB3aGVyZSB0aGlzIGluZm9y bWF0aW9uIGNhbiBiZSB2YWx1YWJsZS4uLg0KDQpNaXJqYQ0KDQoNCg0KT24gMjQuMDQuMjAxNyAx NjoyOSwgSGVubmluZyBTY2h1bHpyaW5uZSB3cm90ZToNCj4gVGhlcmUgd2FzIGFuIGV4dGVuc2l2 ZSBkaXNjdXNzaW9uIG9uIHRoZSAid2hvIGlzIHJlc3BvbnNpYmxlIiBpc3N1ZSBvbiB0aGUgbGlz dC4gTXkgdGFrZSBpcyB0aGF0IHRoZXJlJ3MganVzdCBubyBnb29kIHdheSB0byBrbm93IHdoZXRo ZXIgdGhlICd1bndhbnRlZCcgcmVzcG9uc2Ugd2FzIGdlbmVyYXRlZCBieSBhIGJ1dHRvbiBwcmVz cyBvciBzb21ldGhpbmcgc2VtaS1hdXRvbWF0ZWQgKGUuZy4sIHRoZSBzeXN0ZW0gcG9wcyB1cCBh ICJ5b3UgaHVuZyB1cCB2ZXJ5IHF1aWNrbHkuIFdhcyB0aGlzIGEgc3BhbSBjYWxsPyIgZGlhbG9n IGJveCkgb3IgYXV0b21hdGVkIGZhbmN5LW1hY2hpbmUtbGVhcm5pbmcgYWxnb3JpdGhtIGltcGxl bWVudGVkIG9uIHRoZSBlbmQgc3lzdGVtLiBNeSBndWVzcyBpcyB0aGF0IG1hbnVhbCB3aWxsIGJl LCBieSBmYXIsIHRoZSBtb3N0IGNvbW1vbiB1c2FnZS4gSWYgSSBpbXBsZW1lbnQgTUwgb24gdGhl IGVuZCBzeXN0ZW0gZm9yIGNhbGwgY2xhc3NpZmljYXRpb24sIEkgcHJvYmFibHkgd2FudCB0byBj b250cm9sIHRoZSBleHBlcmllbmNlIGFuZCB0aHVzIG5vdCBtdWRkeSB0aGUgd2F0ZXJzIGJ5IGhh dmluZyB0aGUgbmV0d29yayBmaWx0ZXIsIHRvby4NCj4NCj4gUHJhY3RpY2FsbHktc3BlYWtpbmcs IEkgZG9uJ3Qgc2VlIGEgZ29vZCB3YXkgdG8gZW5mb3JjZSBhbnkgZGlzdGluY3Rpb24sIGV2ZW4g bGVhdmluZyBhc2lkZSB0aGUgcG9zc2liaWxpdGllcyBiZXR3ZWVuIGEgZnVsbHktbWFudWFsIGFu ZCBpbnZpc2libHktYXV0b21hdGljIG1lY2hhbmlzbS4gSXQgaXMgYWxzbyBub3QgY2xlYXIgaG93 IHRoZSBuZXR3b3JrIHdvdWxkIG1ha2UgdXNlIG9mIHN1Y2ggYSBkaXN0aW5jdGlvbiAtIGJvdGgg aHVtYW5zIGFuZCBtYWNoaW5lcyBtYWtlIG1pc3Rha2VzLg0KPg0KPiBUaHVzLCBJIHRoaW5rIHRo ZSBpbnRlbnQgaXMgdG8gdXNlIGl0IGZvciBodW1hbiBmZWVkYmFjaywgYnV0IHdpdGhvdXQgdHJ5 aW5nIHRvIGJlIG92ZXJseSBwcmVzY3JpcHRpdmUuDQo+DQo+IFRoYXQgc2FpZCwgdGhlIGNhbGwt aW5mbyBkcmFmdCBtYXkgbmVlZCBhbiBleHRlbnNpb24gZm9yIHRoZSBraW5kIG9mICJiYWNrd2Fy ZCIgaW5kaWNhdGlvbiBzbyB0aGF0IGFuIGF1dG9tYXRlZCBjYWxsIHJlY2lwaWVudCBjYW4gdGVs bCB0aGUgbmV0d29yayBob3cgaXQgY2xhc3NpZmllZCB0aGUgY2FsbC4NCj4NCj4gSGVubmluZw0K Pg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNaXJqYSBLw7xobGV3aW5k IFttYWlsdG86aWV0ZkBrdWVobGV3aW5kLm5ldF0NCj4gU2VudDogTW9uZGF5LCBBcHJpbCAyNCwg MjAxNyA3OjE0IEFNDQo+IFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0 LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWRAaWV0Zi5vcmc7IEFkYW0gUm9hY2ggPGFkYW1A bm9zdHJ1bS5jb20+OyBzaXBjb3JlLWNoYWlyc0BpZXRmLm9yZzsgYWRhbUBub3N0cnVtLmNvbTsg c2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBNaXJqYSBLw7xobGV3aW5kJ3MgTm8gT2JqZWN0 aW9uIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDU6ICh3aXRoIENPTU1F TlQpDQo+DQo+IE1pcmphIEvDvGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxs b3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDU6 IE5vIE9iamVjdGlvbg0KPg0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJq ZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVk IGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0 b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+DQo+DQo+IFBsZWFzZSByZWZlciB0byBodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y Z19pZXNnX3N0YXRlbWVudF9kaXNjdXNzLTJEY3JpdGVyaWEuaHRtbCZkPUR3SURhUSZjPXkwaDBv bUNlMGpBVUdyNGdBUTAyRncmcj1GSmNWb0RrV001RWlWY1YwUmVYOGxEVTFYZUhJWVJIZmFycGs0 TUs1OVJFJm09cHh1TzNudzZrdzl3TzJKM1ZNYU9uOTZXc2NXNlhmeDByZXpYQlZyQjZNQSZzPU1H LTUwLXNtRnhVNTRRWWwxS05yblJhb3M1blZBRm9ES3BNX0ZtMmwyRHMmZT0NCj4gZm9yIG1vcmUg aW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4N Cj4NCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNh biBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRGlldGYtMkRz aXBjb3JlLTJEc3RhdHVzLTJEdW53YW50ZWRfJmQ9RHdJRGFRJmM9eTBoMG9tQ2UwakFVR3I0Z0FR MDJGdyZyPUZKY1ZvRGtXTTVFaVZjVjBSZVg4bERVMVhlSElZUkhmYXJwazRNSzU5UkUmbT1weHVP M253Nmt3OXdPMkozVk1hT245NldzY1c2WGZ4MHJlelhCVnJCNk1BJnM9d1VfcG5LV3Vud0twUTg3 RUpvNjJ0Z2I2RHVPYmYyTnNLWG14MVNNRTZOOCZlPQ0KPg0KPg0KPg0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gSSBhY3R1YWxseSBoYXZlIG9uZSBt b3N0bHkgdGVjaG5pY2FsIHF1ZXN0aW9uOiBJdCBpcyBub3QgZnVsbHkgY2xlYXIgdG8NCj4gbWUg aWYgdGhlIFVud2FudGVkIHJlc3BvbnNlIGNvZGUgYWx3YXlzIGluZGljYXRlcyBhIHVzZXIgYWN0 aW9uIG9yIGlmIHRoZQ0KPiBzYW1lIGNvZGUgaXMgdXNlZCB3aGVuIGFuIGF1dG9tYXRlZCBzeXN0 ZW0gZGVjbGluZXMgdGhlIGNhbGw/IE15DQo+IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgaWRl YSBpcyB0aGF0IHRoaXMgY291bGQgYWxzbyBiZSBhdXRvbWF0ZWQgaWYNCj4gdGhlIHVzZXIgaGFz IHNvbWUga2luZCBvZiBjb250cm9sIG9mIHRoZSBzeXN0ZW0gKHdoaWNoIGlzIHByb2JhYmx5IGhh cmQNCj4gdG8gdmVyaWZ5KS4gT3Igd291bGQgaXQgbWFrZSBzZW5zZSB0byBkaXN0aW5jdCBiZXR3 ZWVuIHRoZSBjYXNlcyB3aGVyZQ0KPiB0aGUgdXNlciBhY3RpdmVseSByZWplY3RzIGEgY2FsbCBv ciBhbiBhdXRvbWF0ZWQgc3lzdGVtIGlzIGdlbmVyYXRpbmcgdGhlDQo+IHJlc3BvbnNlIGNvZGUg KG9uIGJlaGFsZiBvZiB0aGUgdXNlcik/DQo+DQo+DQo= From nobody Thu Apr 27 08:45: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 C7B4B129B2A for ; Thu, 27 Apr 2017 08:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 ZeyY7Y7oKbs8 for ; Thu, 27 Apr 2017 08:45:36 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43523129AF9 for ; Thu, 27 Apr 2017 08:44:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=DUZC0ewGFnpDhu9PjpMFHMptqzk4UBvGFBTwZmDPLq3+GyiaHlhkk5js6gCzFIdhA7WzS/kSDqLbmEXNTjusUP6tDg3tTGVpBAS5yJkt0acWp9UPPbswNlbHZVtdMfnLBMy+I0CGnl+LCbqhJl3vJtk69K9cNNAvZAz66OTtnS4=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 1695 invoked from network); 27 Apr 2017 17:43:58 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 27 Apr 2017 17:43:58 +0200 To: Henning Schulzrinne , The IESG References: <149303246277.25889.4535549169926039230.idtracker@ietfa.amsl.com> <95b50d9d-ee9b-1f8d-a270-f09b8d67f24d@kuehlewind.net> Cc: "draft-ietf-sipcore-status-unwanted@ietf.org" , Adam Roach , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <85f31f96-09e1-8d9e-8e1d-7e645be74f0b@kuehlewind.net> Date: Thu, 27 Apr 2017 17:43:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20170427154358.1686.45525@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-sipcore-status-unwanted-05=3A_=28with_COMMENT=29?= 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, 27 Apr 2017 15:45:40 -0000 Okay. I have to say that sounds a little like this should be experimental. But I guess that's not that much on an issue. Still these open questions could be documented in the draft eventually. Mirja On 27.04.2017 16:52, Henning Schulzrinne wrote: > Mirja, > > One of my concerns is simplicity - I want to keep the mechanisms as minimal and straightforward as possible, to encourage rapid implementation. Since we are at the beginning of consumer-level unwanted call filtering, my take is to gain some experience and then add mechanisms. For example, for any automated mechanisms, you'd probably want more details as to the "why", primarily to deal with mis-classification and to ensure deliverability of calls. ("This good call was just classified as spam - what made that happen?") This is somewhat similar to the email problem, where the good guys need information to avoid accidentally tripping spam filters ("fix your SPF entry", "make sure that the header format is up to current standards rather than the 1980s version", "check why you ended up on this blacklist"). > > But I don't think we understand well enough how to provide such feedback for VoIP at this point. > > Henning > > -----Original Message----- > From: Mirja Kühlewind [mailto:ietf@kuehlewind.net] > Sent: Thursday, April 27, 2017 9:55 AM > To: Henning Schulzrinne ; The IESG > Cc: draft-ietf-sipcore-status-unwanted@ietf.org; Adam Roach ; sipcore-chairs@ietf.org; sipcore@ietf.org > Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) > > Hi Henning, > > yes I understand that there is no good way to enforce one or the other. I was mainly wondering a) what you want to emphasize in the document and make sure the receiver makes the right assumptions about this, and b) if it would make sense to provide a way to distinguish those two cases. Of course that would not guarantee that is would always be indicated correctly but some systems may indicate it if is there is a use cases where this information can be valuable... > > Mirja > > > > On 24.04.2017 16:29, Henning Schulzrinne wrote: >> There was an extensive discussion on the "who is responsible" issue on the list. My take is that there's just no good way to know whether the 'unwanted' response was generated by a button press or something semi-automated (e.g., the system pops up a "you hung up very quickly. Was this a spam call?" dialog box) or automated fancy-machine-learning algorithm implemented on the end system. My guess is that manual will be, by far, the most common usage. If I implement ML on the end system for call classification, I probably want to control the experience and thus not muddy the waters by having the network filter, too. >> >> Practically-speaking, I don't see a good way to enforce any distinction, even leaving aside the possibilities between a fully-manual and invisibly-automatic mechanism. It is also not clear how the network would make use of such a distinction - both humans and machines make mistakes. >> >> Thus, I think the intent is to use it for human feedback, but without trying to be overly prescriptive. >> >> That said, the call-info draft may need an extension for the kind of "backward" indication so that an automated call recipient can tell the network how it classified the call. >> >> Henning >> >> -----Original Message----- >> From: Mirja Kühlewind [mailto:ietf@kuehlewind.net] >> Sent: Monday, April 24, 2017 7:14 AM >> To: The IESG >> Cc: draft-ietf-sipcore-status-unwanted@ietf.org; Adam Roach ; sipcore-chairs@ietf.org; adam@nostrum.com; sipcore@ietf.org >> Subject: Mirja Kühlewind's No Objection on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) >> >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-sipcore-status-unwanted-05: No Objection >> >> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) >> >> >> Please refer to https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIDaQ&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=pxuO3nw6kw9wO2J3VMaOn96WscW6Xfx0rezXBVrB6MA&s=MG-50-smFxU54QYl1KNrnRaos5nVAFoDKpM_Fm2l2Ds&e= >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=DwIDaQ&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=pxuO3nw6kw9wO2J3VMaOn96WscW6Xfx0rezXBVrB6MA&s=wU_pnKWunwKpQ87EJo62tgb6DuObf2NsKXmx1SME6N8&e= >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I actually have one mostly technical question: It is not fully clear to >> me if the Unwanted response code always indicates a user action or if the >> same code is used when an automated system declines the call? My >> understanding is that the idea is that this could also be automated if >> the user has some kind of control of the system (which is probably hard >> to verify). Or would it make sense to distinct between the cases where >> the user actively rejects a call or an automated system is generating the >> response code (on behalf of the user)? >> >> From nobody Thu Apr 27 08:51: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 A70D8129B44 for ; Thu, 27 Apr 2017 08:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 si7h88My3TYP for ; Thu, 27 Apr 2017 08:50:52 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906D212944A for ; Thu, 27 Apr 2017 08:49:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=bkqO19GVulcAMrCAfjuPsxTyTGWKqzLK27e1L1MJBlRtOiYLIpbb9L0Ha2RM2h/UJaJ6ahkGau+zh/j+xp3BPBjzWbjWZZheTcJeqqQ4LN0/7PFzqE3wy/Im4ws+a58Dr13krqq8zCoyne/HekQZp1pekK1dtFKSlqBtgsG1ka8=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 1590 invoked from network); 27 Apr 2017 17:42:39 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 27 Apr 2017 17:42:38 +0200 To: "Asveren, Tolga" , Henning Schulzrinne , The IESG References: <149303246277.25889.4535549169926039230.idtracker@ietfa.amsl.com> <95b50d9d-ee9b-1f8d-a270-f09b8d67f24d@kuehlewind.net> Cc: "draft-ietf-sipcore-status-unwanted@ietf.org" , "sipcore@ietf.org" , "sipcore-chairs@ietf.org" From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Thu, 27 Apr 2017 17:42:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20170427154239.1581.38996@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-sipcore-status-unwanted-05=3A_=28with_COMMENT=29?= 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, 27 Apr 2017 15:50:59 -0000 Yes, making this more clear would be good. Thanks! On 27.04.2017 16:51, Asveren, Tolga wrote: > I think the intent was exclusively for the human agent to press a button. Granted, there is no way to police this but this has been the scenario under consideration in the past. Anything other than that, e.g. human agent exclusively blacklisting certain AoRs, is supposed to be handled by other mechanisms, e.g. a web portal. > > The semantics for 607 is: "I don’t want this call", nothing more, at least AFAIU and advocated so far. Actually we really should spell this out very clearly. Folks who did not participate during the evolution of this document keep having confusions on this issue. > > Thanks, > Tolga > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Mirja Kühlewind > Sent: Thursday, April 27, 2017 9:55 AM > To: Henning Schulzrinne ; The IESG > Cc: sipcore-chairs@ietf.org; sipcore@ietf.org; draft-ietf-sipcore-status-unwanted@ietf.org > Subject: Re: [sipcore] Mirja Kühlewind's No Objection on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) > > Hi Henning, > > yes I understand that there is no good way to enforce one or the other. I was mainly wondering a) what you want to emphasize in the document and make sure the receiver makes the right assumptions about this, and b) if it would make sense to provide a way to distinguish those two cases. Of course that would not guarantee that is would always be indicated correctly but some systems may indicate it if is there is a use cases where this information can be valuable... > > Mirja > > > > On 24.04.2017 16:29, Henning Schulzrinne wrote: >> There was an extensive discussion on the "who is responsible" issue on the list. My take is that there's just no good way to know whether the 'unwanted' response was generated by a button press or something semi-automated (e.g., the system pops up a "you hung up very quickly. Was this a spam call?" dialog box) or automated fancy-machine-learning algorithm implemented on the end system. My guess is that manual will be, by far, the most common usage. If I implement ML on the end system for call classification, I probably want to control the experience and thus not muddy the waters by having the network filter, too. >> >> Practically-speaking, I don't see a good way to enforce any distinction, even leaving aside the possibilities between a fully-manual and invisibly-automatic mechanism. It is also not clear how the network would make use of such a distinction - both humans and machines make mistakes. >> >> Thus, I think the intent is to use it for human feedback, but without trying to be overly prescriptive. >> >> That said, the call-info draft may need an extension for the kind of "backward" indication so that an automated call recipient can tell the network how it classified the call. >> >> Henning >> >> -----Original Message----- >> From: Mirja Kühlewind [mailto:ietf@kuehlewind.net] >> Sent: Monday, April 24, 2017 7:14 AM >> To: The IESG >> Cc: draft-ietf-sipcore-status-unwanted@ietf.org; Adam Roach ; sipcore-chairs@ietf.org; adam@nostrum.com; sipcore@ietf.org >> Subject: Mirja Kühlewind's No Objection on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) >> >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-sipcore-status-unwanted-05: No Objection >> >> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) >> >> >> Please refer to https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIDaQ&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=pxuO3nw6kw9wO2J3VMaOn96WscW6Xfx0rezXBVrB6MA&s=MG-50-smFxU54QYl1KNrnRaos5nVAFoDKpM_Fm2l2Ds&e= >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=DwIDaQ&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=pxuO3nw6kw9wO2J3VMaOn96WscW6Xfx0rezXBVrB6MA&s=wU_pnKWunwKpQ87EJo62tgb6DuObf2NsKXmx1SME6N8&e= >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I actually have one mostly technical question: It is not fully clear to >> me if the Unwanted response code always indicates a user action or if the >> same code is used when an automated system declines the call? My >> understanding is that the idea is that this could also be automated if >> the user has some kind of control of the system (which is probably hard >> to verify). Or would it make sense to distinct between the cases where >> the user actively rejects a call or an automated system is generating the >> response code (on behalf of the user)? >> >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Apr 27 10:38: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 1543C129B1B; Thu, 27 Apr 2017 10:38:06 -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 NIeWkrrkDG-q; Thu, 27 Apr 2017 10:38:03 -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 D01F5129B01; Thu, 27 Apr 2017 10:34:53 -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 v3RHY521026521; Thu, 27 Apr 2017 17:34:50 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0047.outbound.protection.outlook.com [23.103.198.47]) by mx0b-0024ed01.pphosted.com with ESMTP id 2a2ebcsj54-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 27 Apr 2017 17:34:50 +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=p8QXboDR5iHV0JvS8sPbFZKmULBba3uO3bPKNBCdpWk=; b=WNyFPxrKRU60t7K+SHMbmm5tvkbPlHGGPEV3lHrMnRcMJcOUlntEsqQCE/tdML3WrTalig/TrE3gibkUbD1dVrf/8QarwIuWjAayq94Z84E7k/3KVcKiaThtOMQlqgjh7pECNEb7iR3erwlfkGj0kL3st4ednxqXQSUbrD5i/aA= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Thu, 27 Apr 2017 17:34:48 +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.1047.019; Thu, 27 Apr 2017 17:34:48 +0000 From: Henning Schulzrinne To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "draft-ietf-sipcore-status-unwanted@ietf.org" , Adam Roach , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-sipcore-status-unwanted-05:_(with_COMMENT)?= Thread-Index: AQHSvOvw1py7aDhMjEyD7coW+O+7oqHUkcnQgASv+oCAAA4hcIAAEG8AgAAefaA= Date: Thu, 27 Apr 2017 17:34:48 +0000 Message-ID: References: <149303246277.25889.4535549169926039230.idtracker@ietfa.amsl.com> <95b50d9d-ee9b-1f8d-a270-f09b8d67f24d@kuehlewind.net> <85f31f96-09e1-8d9e-8e1d-7e645be74f0b@kuehlewind.net> In-Reply-To: <85f31f96-09e1-8d9e-8e1d-7e645be74f0b@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kuehlewind.net; dkim=none (message not signed) header.d=none;kuehlewind.net; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [192.104.54.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:YX2L5a4tbgZoTLJQOBx163eBKw8M3ZXFtJPKDkVZt/3QbMJob2+TNiFrqfcCB/dO8rK3Pp+7ogcSaT1jruEuVkVY98hiKDm/OXvrvK0/GNS82c65nNkhzaDJHZu1XozbxfDXkx/GHy+7S+wNTltjIC7OS2xdDLjdfIzQ6BTfTqu+8jgdDWAr649jLSDA4x6NcjUKinz4NVEm0HnD6EcsWQeY2zdVgZ9HgWEsw6ZFzBg70oVz73gmBGonK7aA6Cl77pzc++/zkE/EJKWvhnu0mxgCrGcRxhCUntYI4Vp7+O8BgrZB279cLCFx/O3E+7ZsH7PoLo+jme0jJk8l6ElSlg== x-ms-office365-filtering-correlation-id: d79e4524-0040-4297-ee3d-08d48d93b428 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR09MB0636; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39840400002)(39450400003)(39400400002)(377454003)(13464003)(24454002)(86362001)(2900100001)(575784001)(3280700002)(229853002)(6506006)(66066001)(77096006)(6116002)(3660700001)(102836003)(3846002)(6246003)(5660300001)(33656002)(224303003)(99286003)(55016002)(54906002)(224313004)(2906002)(6436002)(54356999)(6306002)(50986999)(76176999)(9686003)(305945005)(7736002)(74316002)(53936002)(81166006)(93886004)(122556002)(7696004)(2950100002)(53546009)(25786009)(8936002)(189998001)(230783001)(4326008)(38730400002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2017 17:34:48.7031 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-27_15:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-sipcore-status-unwanted-05=3A_=28with_COMMENT=29?= 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, 27 Apr 2017 17:38:06 -0000 Tm90ZSB0aGF0IHRoZSBjdXJyZW50IGRyYWZ0IGlzIGFib3V0IGh1bWFuIGZlZWRiYWNrICh3aXRo IHRoZSB1c3VhbCBjYXZlYXQgdGhhdCB3ZSBjYW4ndCBwb2xpY2Ugcm9ib3RzIHByZXRlbmRpbmcg dG8gYmUgaHVtYW5zKSwgc28gdGhlICJkb24ndCB1bmRlcnN0YW5kIiBwYXJ0IHdvdWxkIGFwcGx5 IHRvIHByb3ZpZGluZyBhdXRvbWF0ZWQgZmVlZGJhY2ssIG5vdCB0aGUgZHJhZnQgdW5kZXIgZGlz Y3Vzc2lvbi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1pcmphIEvDvGhs ZXdpbmQgW21haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0XSANClNlbnQ6IFRodXJzZGF5LCBBcHJp bCAyNywgMjAxNyAxMTo0NCBBTQ0KVG86IEhlbm5pbmcgU2NodWx6cmlubmUgPEhlbm5pbmcuU2No dWx6cmlubmVAZmNjLmdvdj47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWll dGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWRAaWV0Zi5vcmc7IEFkYW0gUm9hY2ggPGFkYW1Abm9z dHJ1bS5jb20+OyBzaXBjb3JlLWNoYWlyc0BpZXRmLm9yZzsgc2lwY29yZUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IE1pcmphIEvDvGhsZXdpbmQncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1z aXBjb3JlLXN0YXR1cy11bndhbnRlZC0wNTogKHdpdGggQ09NTUVOVCkNCg0KT2theS4gSSBoYXZl IHRvIHNheSB0aGF0IHNvdW5kcyBhIGxpdHRsZSBsaWtlIHRoaXMgc2hvdWxkIGJlIGV4cGVyaW1l bnRhbC4gDQpCdXQgSSBndWVzcyB0aGF0J3Mgbm90IHRoYXQgbXVjaCBvbiBhbiBpc3N1ZS4gU3Rp bGwgdGhlc2Ugb3BlbiBxdWVzdGlvbnMgY291bGQgYmUgZG9jdW1lbnRlZCBpbiB0aGUgZHJhZnQg ZXZlbnR1YWxseS4NCg0KTWlyamENCg0KDQpPbiAyNy4wNC4yMDE3IDE2OjUyLCBIZW5uaW5nIFNj aHVsenJpbm5lIHdyb3RlOg0KPiBNaXJqYSwNCj4NCj4gT25lIG9mIG15IGNvbmNlcm5zIGlzIHNp bXBsaWNpdHkgLSBJIHdhbnQgdG8ga2VlcCB0aGUgbWVjaGFuaXNtcyBhcyBtaW5pbWFsIGFuZCBz dHJhaWdodGZvcndhcmQgYXMgcG9zc2libGUsIHRvIGVuY291cmFnZSByYXBpZCBpbXBsZW1lbnRh dGlvbi4gU2luY2Ugd2UgYXJlIGF0IHRoZSBiZWdpbm5pbmcgb2YgY29uc3VtZXItbGV2ZWwgdW53 YW50ZWQgY2FsbCBmaWx0ZXJpbmcsIG15IHRha2UgaXMgdG8gZ2FpbiBzb21lIGV4cGVyaWVuY2Ug YW5kIHRoZW4gYWRkIG1lY2hhbmlzbXMuIEZvciBleGFtcGxlLCBmb3IgYW55IGF1dG9tYXRlZCBt ZWNoYW5pc21zLCB5b3UnZCBwcm9iYWJseSB3YW50IG1vcmUgZGV0YWlscyBhcyB0byB0aGUgIndo eSIsIHByaW1hcmlseSB0byBkZWFsIHdpdGggbWlzLWNsYXNzaWZpY2F0aW9uIGFuZCB0byBlbnN1 cmUgZGVsaXZlcmFiaWxpdHkgb2YgY2FsbHMuICgiVGhpcyBnb29kIGNhbGwgd2FzIGp1c3QgY2xh c3NpZmllZCBhcyBzcGFtIC0gd2hhdCBtYWRlIHRoYXQgaGFwcGVuPyIpIFRoaXMgaXMgc29tZXdo YXQgc2ltaWxhciB0byB0aGUgZW1haWwgcHJvYmxlbSwgd2hlcmUgdGhlIGdvb2QgZ3V5cyBuZWVk IGluZm9ybWF0aW9uIHRvIGF2b2lkIGFjY2lkZW50YWxseSB0cmlwcGluZyBzcGFtIGZpbHRlcnMg KCJmaXggeW91ciBTUEYgZW50cnkiLCAibWFrZSBzdXJlIHRoYXQgdGhlIGhlYWRlciBmb3JtYXQg aXMgdXAgdG8gY3VycmVudCBzdGFuZGFyZHMgcmF0aGVyIHRoYW4gdGhlIDE5ODBzIHZlcnNpb24i LCAiY2hlY2sgd2h5IHlvdSBlbmRlZCB1cCBvbiB0aGlzIGJsYWNrbGlzdCIpLg0KPg0KPiBCdXQg SSBkb24ndCB0aGluayB3ZSB1bmRlcnN0YW5kIHdlbGwgZW5vdWdoIGhvdyB0byBwcm92aWRlIHN1 Y2ggZmVlZGJhY2sgZm9yIFZvSVAgYXQgdGhpcyBwb2ludC4NCj4NCj4gSGVubmluZw0KPg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNaXJqYSBLw7xobGV3aW5kIFttYWls dG86aWV0ZkBrdWVobGV3aW5kLm5ldF0NCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDI3LCAyMDE3 IDk6NTUgQU0NCj4gVG86IEhlbm5pbmcgU2NodWx6cmlubmUgPEhlbm5pbmcuU2NodWx6cmlubmVA ZmNjLmdvdj47IFRoZSBJRVNHIA0KPiA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0LWlldGYt c2lwY29yZS1zdGF0dXMtdW53YW50ZWRAaWV0Zi5vcmc7IEFkYW0gUm9hY2ggDQo+IDxhZGFtQG5v c3RydW0uY29tPjsgc2lwY29yZS1jaGFpcnNAaWV0Zi5vcmc7IHNpcGNvcmVAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IE1pcmphIEvDvGhsZXdpbmQncyBObyBPYmplY3Rpb24gb24gDQo+IGRyYWZ0 LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDU6ICh3aXRoIENPTU1FTlQpDQo+DQo+IEhp IEhlbm5pbmcsDQo+DQo+IHllcyBJIHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBpcyBubyBnb29kIHdh eSB0byBlbmZvcmNlIG9uZSBvciB0aGUgb3RoZXIuIEkgd2FzIG1haW5seSB3b25kZXJpbmcgYSkg d2hhdCB5b3Ugd2FudCB0byBlbXBoYXNpemUgaW4gdGhlIGRvY3VtZW50IGFuZCBtYWtlIHN1cmUg dGhlIHJlY2VpdmVyIG1ha2VzIHRoZSByaWdodCBhc3N1bXB0aW9ucyBhYm91dCB0aGlzLCBhbmQg YikgaWYgaXQgd291bGQgbWFrZSBzZW5zZSB0byBwcm92aWRlIGEgd2F5IHRvIGRpc3Rpbmd1aXNo IHRob3NlIHR3byBjYXNlcy4gT2YgY291cnNlIHRoYXQgd291bGQgbm90IGd1YXJhbnRlZSB0aGF0 IGlzIHdvdWxkIGFsd2F5cyBiZSBpbmRpY2F0ZWQgY29ycmVjdGx5IGJ1dCBzb21lIHN5c3RlbXMg bWF5IGluZGljYXRlIGl0IGlmIGlzIHRoZXJlIGlzIGEgdXNlIGNhc2VzIHdoZXJlIHRoaXMgaW5m b3JtYXRpb24gY2FuIGJlIHZhbHVhYmxlLi4uDQo+DQo+IE1pcmphDQo+DQo+DQo+DQo+IE9uIDI0 LjA0LjIwMTcgMTY6MjksIEhlbm5pbmcgU2NodWx6cmlubmUgd3JvdGU6DQo+PiBUaGVyZSB3YXMg YW4gZXh0ZW5zaXZlIGRpc2N1c3Npb24gb24gdGhlICJ3aG8gaXMgcmVzcG9uc2libGUiIGlzc3Vl IG9uIHRoZSBsaXN0LiBNeSB0YWtlIGlzIHRoYXQgdGhlcmUncyBqdXN0IG5vIGdvb2Qgd2F5IHRv IGtub3cgd2hldGhlciB0aGUgJ3Vud2FudGVkJyByZXNwb25zZSB3YXMgZ2VuZXJhdGVkIGJ5IGEg YnV0dG9uIHByZXNzIG9yIHNvbWV0aGluZyBzZW1pLWF1dG9tYXRlZCAoZS5nLiwgdGhlIHN5c3Rl bSBwb3BzIHVwIGEgInlvdSBodW5nIHVwIHZlcnkgcXVpY2tseS4gV2FzIHRoaXMgYSBzcGFtIGNh bGw/IiBkaWFsb2cgYm94KSBvciBhdXRvbWF0ZWQgZmFuY3ktbWFjaGluZS1sZWFybmluZyBhbGdv cml0aG0gaW1wbGVtZW50ZWQgb24gdGhlIGVuZCBzeXN0ZW0uIE15IGd1ZXNzIGlzIHRoYXQgbWFu dWFsIHdpbGwgYmUsIGJ5IGZhciwgdGhlIG1vc3QgY29tbW9uIHVzYWdlLiBJZiBJIGltcGxlbWVu dCBNTCBvbiB0aGUgZW5kIHN5c3RlbSBmb3IgY2FsbCBjbGFzc2lmaWNhdGlvbiwgSSBwcm9iYWJs eSB3YW50IHRvIGNvbnRyb2wgdGhlIGV4cGVyaWVuY2UgYW5kIHRodXMgbm90IG11ZGR5IHRoZSB3 YXRlcnMgYnkgaGF2aW5nIHRoZSBuZXR3b3JrIGZpbHRlciwgdG9vLg0KPj4NCj4+IFByYWN0aWNh bGx5LXNwZWFraW5nLCBJIGRvbid0IHNlZSBhIGdvb2Qgd2F5IHRvIGVuZm9yY2UgYW55IGRpc3Rp bmN0aW9uLCBldmVuIGxlYXZpbmcgYXNpZGUgdGhlIHBvc3NpYmlsaXRpZXMgYmV0d2VlbiBhIGZ1 bGx5LW1hbnVhbCBhbmQgaW52aXNpYmx5LWF1dG9tYXRpYyBtZWNoYW5pc20uIEl0IGlzIGFsc28g bm90IGNsZWFyIGhvdyB0aGUgbmV0d29yayB3b3VsZCBtYWtlIHVzZSBvZiBzdWNoIGEgZGlzdGlu Y3Rpb24gLSBib3RoIGh1bWFucyBhbmQgbWFjaGluZXMgbWFrZSBtaXN0YWtlcy4NCj4+DQo+PiBU aHVzLCBJIHRoaW5rIHRoZSBpbnRlbnQgaXMgdG8gdXNlIGl0IGZvciBodW1hbiBmZWVkYmFjaywg YnV0IHdpdGhvdXQgdHJ5aW5nIHRvIGJlIG92ZXJseSBwcmVzY3JpcHRpdmUuDQo+Pg0KPj4gVGhh dCBzYWlkLCB0aGUgY2FsbC1pbmZvIGRyYWZ0IG1heSBuZWVkIGFuIGV4dGVuc2lvbiBmb3IgdGhl IGtpbmQgb2YgImJhY2t3YXJkIiBpbmRpY2F0aW9uIHNvIHRoYXQgYW4gYXV0b21hdGVkIGNhbGwg cmVjaXBpZW50IGNhbiB0ZWxsIHRoZSBuZXR3b3JrIGhvdyBpdCBjbGFzc2lmaWVkIHRoZSBjYWxs Lg0KPj4NCj4+IEhlbm5pbmcNCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g RnJvbTogTWlyamEgS8O8aGxld2luZCBbbWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXRdDQo+PiBT ZW50OiBNb25kYXksIEFwcmlsIDI0LCAyMDE3IDc6MTQgQU0NCj4+IFRvOiBUaGUgSUVTRyA8aWVz Z0BpZXRmLm9yZz4NCj4+IENjOiBkcmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVzLXVud2FudGVkQGll dGYub3JnOyBBZGFtIFJvYWNoIA0KPj4gPGFkYW1Abm9zdHJ1bS5jb20+OyBzaXBjb3JlLWNoYWly c0BpZXRmLm9yZzsgYWRhbUBub3N0cnVtLmNvbTsgDQo+PiBzaXBjb3JlQGlldGYub3JnDQo+PiBT dWJqZWN0OiBNaXJqYSBLw7xobGV3aW5kJ3MgTm8gT2JqZWN0aW9uIG9uIA0KPj4gZHJhZnQtaWV0 Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC0wNTogKHdpdGggQ09NTUVOVCkNCj4+DQo+PiBNaXJq YSBLw7xobGV3aW5kIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZv cg0KPj4gZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC0wNTogTm8gT2JqZWN0aW9u DQo+Pg0KPj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGlu dGFjdCBhbmQgcmVwbHkgdG8gYWxsIA0KPj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRo ZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IA0KPj4gdGhpcyBpbnRyb2R1Y3Rv cnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4+DQo+Pg0KPj4gUGxlYXNlIHJlZmVyIHRvIA0KPj4g aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfaWVzDQo+PiBnX3N0YXRlbWVudF9kaXNjdXNzLTJEY3JpdGVyaWEuaHRtbCZkPUR3 SURhUSZjPXkwaDBvbUNlMGpBVUdyNGdBUTAyRncNCj4+ICZyPUZKY1ZvRGtXTTVFaVZjVjBSZVg4 bERVMVhlSElZUkhmYXJwazRNSzU5UkUmbT1weHVPM253Nmt3OXdPMkozVk1hTw0KPj4gbjk2V3Nj VzZYZngwcmV6WEJWckI2TUEmcz1NRy01MC1zbUZ4VTU0UVlsMUtOcm5SYW9zNW5WQUZvREtwTV9G bTJsMkRzDQo+PiAmZT0gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFu ZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4+DQo+Pg0KPj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRo IG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPj4gaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5p ZXRmDQo+PiAub3JnX2RvY19kcmFmdC0yRGlldGYtMkRzaXBjb3JlLTJEc3RhdHVzLTJEdW53YW50 ZWRfJmQ9RHdJRGFRJmM9eTBoMG8NCj4+IG1DZTBqQVVHcjRnQVEwMkZ3JnI9RkpjVm9Ea1dNNUVp VmNWMFJlWDhsRFUxWGVISVlSSGZhcnBrNE1LNTlSRSZtPXB4dQ0KPj4gTzNudzZrdzl3TzJKM1ZN YU9uOTZXc2NXNlhmeDByZXpYQlZyQjZNQSZzPXdVX3BuS1d1bndLcFE4N0VKbzYydGdiNkR1DQo+ PiBPYmYyTnNLWG14MVNNRTZOOCZlPQ0KPj4NCj4+DQo+Pg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiAt DQo+PiBDT01NRU5UOg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiAtDQo+Pg0KPj4gSSBhY3R1YWxseSBo YXZlIG9uZSBtb3N0bHkgdGVjaG5pY2FsIHF1ZXN0aW9uOiBJdCBpcyBub3QgZnVsbHkgY2xlYXIg DQo+PiB0byBtZSBpZiB0aGUgVW53YW50ZWQgcmVzcG9uc2UgY29kZSBhbHdheXMgaW5kaWNhdGVz IGEgdXNlciBhY3Rpb24gb3IgDQo+PiBpZiB0aGUgc2FtZSBjb2RlIGlzIHVzZWQgd2hlbiBhbiBh dXRvbWF0ZWQgc3lzdGVtIGRlY2xpbmVzIHRoZSBjYWxsPyANCj4+IE15IHVuZGVyc3RhbmRpbmcg aXMgdGhhdCB0aGUgaWRlYSBpcyB0aGF0IHRoaXMgY291bGQgYWxzbyBiZSANCj4+IGF1dG9tYXRl ZCBpZiB0aGUgdXNlciBoYXMgc29tZSBraW5kIG9mIGNvbnRyb2wgb2YgdGhlIHN5c3RlbSAod2hp Y2ggDQo+PiBpcyBwcm9iYWJseSBoYXJkIHRvIHZlcmlmeSkuIE9yIHdvdWxkIGl0IG1ha2Ugc2Vu c2UgdG8gZGlzdGluY3QgDQo+PiBiZXR3ZWVuIHRoZSBjYXNlcyB3aGVyZSB0aGUgdXNlciBhY3Rp dmVseSByZWplY3RzIGEgY2FsbCBvciBhbiANCj4+IGF1dG9tYXRlZCBzeXN0ZW0gaXMgZ2VuZXJh dGluZyB0aGUgcmVzcG9uc2UgY29kZSAob24gYmVoYWxmIG9mIHRoZSB1c2VyKT8NCj4+DQo+Pg0K From nobody Thu Apr 27 10:38: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 6D1E1129B5B for ; Thu, 27 Apr 2017 10:38:27 -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 XtzFaEwWLJ08 for ; Thu, 27 Apr 2017 10:38:17 -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 912AE129B5A for ; Thu, 27 Apr 2017 10:35:11 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-05v.sys.comcast.net with SMTP id 3nJZdN2XZzz3d3nJud4dwu; Thu, 27 Apr 2017 17:35:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1493314510; bh=8AbRqpzQM21zpfNsv/ymNaEqNhlcU1/PbCawbsrz1U8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=AUFUiurS4Ji0Urapq4kQPbO0SYLTGbNplM3Qil9rUxOQm7DFfIMU8Sm1L2VsK2yDz S9NVOTf3WJeqXCSBs52LoZHDusBNTw7QsU7ImUp1fBivqpOgrZJRffAVB/QuKO5OCS IC9QIIruAc/zm85cP/HhlZB9rhR11JcrJIVb/zt8RdUPXe4NsqU+zvfMSdW1HLGqAZ ZoxxXH7fz5aWEjS8r3FDpFRujiJ73NQ0Wfv3+eXcjY0a9AvEEsh7YLkJmIO9O0cQkP 7XR2jw7cMrKgR71RO3EaS/Dv9KvyjNRW9ziT/SJCbVFvAul9RuWW6NHFWRvDknHFOq bc8V2ZeKJ1Gwg== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-09v.sys.comcast.net with SMTP id 3nJtdtUBNjCS03nJudYYNh; Thu, 27 Apr 2017 17:35:10 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <440df8b4-b22d-f796-692d-95131ce90b39@comcast.net> From: Paul Kyzivat Message-ID: <2a5f2151-6fd6-8d48-e244-18d41983dbf8@comcast.net> Date: Thu, 27 Apr 2017 13:35:09 -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: Content-Type: text/plain; charset=euc-kr; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfIdjtNKlA00e2rNWBjOoDK8FzwGd0ttarDuhM2IE50JwGMp3PvonLQs3Vzh2cxV2laX23jgInTsYFdbZ5w3NeyZuJBUwep7QA7CcSSgHWRsKCp7/NbUS 2ZiNaZdcg38oKkLPBDuhbBOuXl32szKtqrU9ll9cMF6f3zUqhMCVI+5r7qEQapXo3B/Ywklkn3ui2fLjSPAjvHtoMOju/OcFK63PWswXvAo/66xl33Ylyh00 Archived-At: Subject: Re: [sipcore] Draft new version: draft-content-id-02 - Paul's comments 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, 27 Apr 2017 17:38:27 -0000 On 4/27/17 3:23 AM, Christer Holmberg wrote: > Hi, > > Pull request updated. > > Regards, > > Christer Looking good now. I'm down to just a nit: Section 4: This section updates section 9.1 of [RFC5621], by allowing a Content- ID URL to reference a message-body and the related metadata (Section 3.3), in addition to allowing to reference to a body part.A s/to allowing to/to allowing a/ s/.A/./ Thanks, Paul From nobody Thu Apr 27 11:08: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 835BD129B45 for ; Thu, 27 Apr 2017 11:08:00 -0700 (PDT) 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 000GyLm-EV9x for ; Thu, 27 Apr 2017 11:07:59 -0700 (PDT) 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 4E9DF129B76 for ; Thu, 27 Apr 2017 11:04:59 -0700 (PDT) X-AuditID: c1b4fb30-af94d9a000001047-d2-590232c9a6b1 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8C.DB.04167.9C232095; Thu, 27 Apr 2017 20:04:57 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0339.000; Thu, 27 Apr 2017 20:04:54 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new version: draft-content-id-02 - Paul's comments Thread-Index: AQHSvmjNKMGBh5tjm0a4Pt/k9GGZD6HXpUaAgAE+RgCAAHdWgIAAKZMg Date: Thu, 27 Apr 2017 18:04:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB89223@ESESSMB109.ericsson.se> References: <440df8b4-b22d-f796-692d-95131ce90b39@comcast.net> <2a5f2151-6fd6-8d48-e244-18d41983dbf8@comcast.net> In-Reply-To: <2a5f2151-6fd6-8d48-e244-18d41983dbf8@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7k+5JI6ZIg99/VCwe/Ohls/j6YxOb A5PH5MdzGD2WLPnJFMAUxWWTkpqTWZZapG+XwJVxe/JFloJ25opFF04yNjAuYupi5OSQEDCR aPrSxdbFyMUhJHCEUeLF8rUsEM4SRokN+x4ydjFycLAJWEh0/9MGaRARCJHY/vMoK4gtLBAo cW/GeyaIeJDEpxmtjBC2m8TWaz9ZQGwWAVWJuROeg9XzCvhKnP4xmRnEFhK4zijR/DQVxOYU sJe4dbiRHcRmFBCT+H5qDdhMZgFxiVtP5kMdKiCxZM95ZghbVOLl43+sELaSROOSJ6wQ9ToS C3Z/YoOwtSWWLXzNDLFXUOLkzCcsExhFZiEZOwtJyywkLbOQtCxgZFnFKFqcWpyUm25kpJda lJlcXJyfp5eXWrKJERgPB7f8NtjB+PK54yFGAQ5GJR7ehJ+MkUKsiWXFlbmHGCU4mJVEeJWB 0STEm5JYWZValB9fVJqTWnyIUZqDRUmc13HfhQghgfTEktTs1NSC1CKYLBMHp1QDo+WH+tNZ h5sX5j9a8UTvjpH/T4c3yZ9enyh+suKL3YaPH/M/lM5331NwO4GvpuUJy5OjvMuvCQufrdXR 91g+ZWO9peS5up9Xz734LPj9xc61B+6vTrgV2qnnEH7V9l7fwjfbGaWW7vs878c3u4JWvfQp ibPiw/QnK27cO4vt013HjtubFWLjXzgosRRnJBpqMRcVJwIAmEAH5YMCAAA= Archived-At: Subject: Re: [sipcore] Draft new version: draft-content-id-02 - Paul's comments 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, 27 Apr 2017 18:08:01 -0000 Hi, >Looking good now. I'm down to just a nit: > >Section 4: > > This section updates section 9.1 of [RFC5621], by allowing a Content- > ID URL to reference a message-body and the related metadata > (Section 3.3), in addition to allowing to reference to a body part.A > > s/to allowing to/to allowing a/ > s/.A/./ Will be fixed. Thanks! Regards, Christer From nobody Thu Apr 27 13:58: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 F09A7129416; Thu, 27 Apr 2017 13:58:37 -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, 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 (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 lBpI20ABPszG; Thu, 27 Apr 2017 13:58:34 -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 8A548129418; Thu, 27 Apr 2017 13:54:59 -0700 (PDT) Received: from pps.filterd (m0102175.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3RKrQrf027121; Thu, 27 Apr 2017 20:54:57 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0021.outbound.protection.outlook.com [23.103.198.21]) by mx0b-0024ed01.pphosted.com with ESMTP id 2a2ebbhpyy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 27 Apr 2017 20:54:56 +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=HuhXp7IV9o+RPHaVQz87DSdJBnHvwQ+QMha4J+j70xk=; b=YfdYqjJ6Ihnw1UUw9MwR6UUUrjYERSucB5k9a8SE8Z0Lbskl0Ci9iBFj6h99zy/TQtK9NBxLYszimPZ2Nucg3oXxRe8DWkhuRx9mYMcZRwzAvO0I+0/dxR45IVBDVzyMc9JlOp5rR7KpGFfnVqMx/gqiiqwgVwL22thU/REVhWk= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0635.namprd09.prod.outlook.com (10.160.151.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Thu, 27 Apr 2017 20:54:54 +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.1047.019; Thu, 27 Apr 2017 20:54:54 +0000 From: Henning Schulzrinne To: Spencer Dawkins , The IESG CC: "draft-ietf-sipcore-status-unwanted@ietf.org" , Adam Roach , "sipcore-chairs@ietf.org" , "adam@nostrum.com" , "sipcore@ietf.org" Thread-Topic: Spencer Dawkins' Yes on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) Thread-Index: AQHSvq+l2AeZFuQX+E2QJEZsPl+FsaHZk2Qg Date: Thu, 27 Apr 2017 20:54:54 +0000 Message-ID: References: <149322647121.14925.7574406005591553723.idtracker@ietfa.amsl.com> In-Reply-To: <149322647121.14925.7574406005591553723.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [192.104.54.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 7:hj2pZ7A37At9dJ9u9scrd4nfT4V4k6SNMAETVrrhMLsvEYocP7vKtHUS0uwJB4GbatrxBnHjY1pyKaJ8pjSbLrBbqOU3GEYOk2Wo42J4qgfPzzDE/UImIrEjT8oWqNXyyUwRLUWsm+dFrHEZbLcLjiJKOaXmmU0Xi1TwyzCA5ZW3dDBDsrxulJ0x1AjA2cdnk1tv83nqN5MD//PsZ/HU+te0gIlhpphKnQv3ejwPt9oCcqAs6ZNZbOERtobCzrWH09Lhd0P3ojKu7VUZu4QTaFxtARDRNK6sOyMhImJJHl0P2deaxf35o+o2wK1+jIpbP7g4V5PnWiX0Dvy1xX9S9g== x-ms-office365-filtering-correlation-id: 6eda35fc-def9-4591-3c87-08d48dafa852 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR09MB0635; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123564025)(6072148); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39410400002)(39400400002)(39850400002)(13464003)(3660700001)(9686003)(3280700002)(2900100001)(5660300001)(7696004)(38730400002)(54896002)(6306002)(99286003)(55016002)(54906002)(77096006)(229853002)(6506006)(6436002)(189998001)(66066001)(102836003)(33656002)(3846002)(2906002)(6116002)(54356999)(2950100002)(7736002)(8936002)(81166006)(790700001)(50986999)(76176999)(8676002)(86362001)(4326008)(6246003)(39060400002)(74316002)(25786009)(122556002)(230783001)(53936002)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; 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_CY1PR09MB0634D07CE4FBCB61D9B53CBFEA100CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2017 20:54:54.8076 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-27_17:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Spencer Dawkins' Yes on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) 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, 27 Apr 2017 20:58:38 -0000 --_000_CY1PR09MB0634D07CE4FBCB61D9B53CBFEA100CY1PR09MB0634namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3BlbmNlciwNCg0KDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gSW5saW5lIGJlbG93Lg0K DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNwZW5jZXIgRGF3a2lucyBb bWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tXQ0KDQoNCkluIHRoaXMgdGV4dCwN Cg0KDQoNCiAgIFRodXMsIHRoZSBjYWxsIGlzIHJlamVjdGVkIGR1ZSB0byB0aGUgY2FsbGVkIHBh cnR5J3MNCg0KICAgKHRlbXBvcmFyeSkgZGlzcG9zaXRpb24uDQoNCg0KDQpJJ20gaGF2aW5nIHRy b3VibGUgbWF0Y2hpbmcgZGljdGlvbmFyeSBkZWZpbml0aW9ucyB0byB0aGUgdXNlIG9mDQoNCiJk aXNwb3NpdGlvbiIgaGVyZS4gSSBndWVzcyBpdCdzIGFuIE9LIHVzZSBvZiB0aGUgd29yZCwgYW5k IEkga25vdyB3aGF0J3MNCg0KaW50ZW5kZWQgYmFzZWQgb24gY29udGV4dCBjbHVlcywgYnV0IGlm IGFub3RoZXIgd29yZCB3b3VsZCBiZSBjbGVhcmVyLA0KDQp0aGF0IHdvdWxkIGJlIGhlbHBmdWwu DQoNCg0KDQpJ4oCZbGwgcmVwbGFjZSBieSDigJxzdGF0dXPigJ0uIEkgbWVhbnQgc29tZXRoaW5n IGxpa2UgdGhlIOKAnHByZXNlbmNlIHN0YXR1c+KAnSAoYnVzeSwgZHJpdmluZywgaW4gdGhlIHNo b3dlciwgZXRjLikuDQoNCg0KDQoNCg0KVGhpcyB0ZXh0LA0KDQoNCg0KICAgVGhlIHBhcnRpY3Vs YXIgcmVzcG9uc2UgY29kZSBudW1iZXINCg0KICAgd2FzIGNob3NlbiB0byByZWZsZWN0IHRoZSBk aXN0YXN0ZSBmZWx0IGJ5IG1hbnkgdXBvbiByZWNlaXZpbmcgc3VjaA0KDQogICBjYWxscy4NCg0K DQoNCmlzIHVuY2hhbmdlZCBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uLCB3aGVyZSB0aGUgcmVz cG9uc2UgY29kZSBudW1iZXINCg0Kd2FzIDY2Ni4gSXMgdGhhdCBpbnRlbnRpb25hbD8NCg0KDQoN ClRoaXMgd2FzIGFsc28gcG9pbnRlZCBvdXQgYnkgQnJldHQgVGF0ZTsgSSByZW1vdmVkIHRoZSBu b3ctbWVhbmluZ2xlc3Mgc2VudGVuY2UuDQoNCg0KDQoNCg0KSnVzdCBjaGVja2luZyAtIGluIHRo aXMgdGV4dCwNCg0KDQoNCiAgIFRoZSBzZXJ2aWNlDQoNCiAgIHByb3ZpZGVyIGRlbGl2ZXJpbmcg Y2FsbHMgb3IgbWVzc2FnZXMgdG8gdGhlIHVzZXIgaXNzdWluZyB0aGUNCg0KICAgcmVzcG9uc2Ug TUFZIHRha2UgYSByYW5nZSBvZiBhY3Rpb25zLCBmb3IgZXhhbXBsZSwgYWRkIHRoZSBjYWxsaW5n DQoNCiAgIHBhcnR5IHRvIGEgcGVyc29uYWwgYmxhY2tsaXN0IHNwZWNpZmljIHRvIHRoZSBjYWxs ZWQgcGFydHksIHVzZSB0aGUNCg0KICAgaW5mb3JtYXRpb24gYXMgaW5wdXQgd2hlbiBjb21wdXRp bmcgdGhlIGxpa2VsaWhvb2QgdGhhdCB0aGUgY2FsbGluZw0KDQogICBwYXJ0eSBpcyBwbGFjaW5n IHVud2FudGVkIGNhbGxzICgiY3Jvd2Qgc291cmNpbmciKSwgaW5pdGlhdGUgYQ0KDQogICB0cmFj ZWJhY2sgcmVxdWVzdCwgb3IgcmVwb3J0IHRoZSBjYWxsaW5nIHBhcnR5IGlkZW50aXR5IHRvIGNv bnN1bWVyDQoNCiAgIGNvbXBsYWludCBkYXRhYmFzZXMgb3BlcmF0ZWQgYnkgZ292ZXJubWVudCBh dXRob3JpdGllcy4NCg0KDQoNCnRoZXJlJ3Mgbm8gc3RhbmRhcmRpemVkIHdheSBmb3IgdGhlIGNh bGxlZCBwYXJ0eSB0byBzaWduYWwgdGhhdCB0aGlzDQoNCmFjdGlvbiBzaG91bGQgYmUgcmV2ZXJz ZWQsIGlzIHRoZXJlPyBJIGFzaywgYmVjYXVzZSB0aGUgbmV4dCBwYXJhZ3JhcGgNCg0KDQoNCkkg ZG9u4oCZdCBzZWUgaG93IHRoaXMgd291bGQgYmUgcG9zc2libGUuIE9uY2UgeW91IGhhdmUgcmVq ZWN0ZWQgdGhlIGNhbGwsIGl04oCZcyBnb25lLiAoVGhhdOKAmXMgd2hlcmUgdGhlIGVtYWlsIGFu YWxvZ3kgYnJlYWtzIGRvd24sIGFzIHRoZSBjYWxsIGlzbuKAmXQganVzdCBkdW1wZWQgaW50byBh IGZvbGRlci4pIFBvc3QtY2FsbCBtZWNoYW5pc21zLCBlLmcuLCBmcm9tIHRoZSBjYWxsIGxvZywg d291bGQgbGlrZWx5IGJlIHNvbWUgSFRUUCBBUEksIGFzIFNJUCB3b3VsZG7igJl0IGZpdC4gTWF5 YmUgd2UgY2FuIGRlZmluZSBZQU5HIG1vZGVsLCBzaW5jZSBpdOKAmXMgdXNlZCBmb3IganVzdCBh Ym91dCBldmVyeXRoaW5nIGVsc2Ug4pi6DQoNCg0KDQpzYXlzLA0KDQoNCg0KICAgVGhlIHVzZXIg ZXhwZXJpZW5jZSBpcyBlbnZpc2lvbmVkIHRvIGJlIHNvbWV3aGF0IHNpbWlsYXIgdG8gZW1haWwN Cg0KICAgc3BhbSBidXR0b25zIHdoZXJlIHRoZSBkZXRhaWxlZCBhY3Rpb25zIG9mIHRoZSBlbWFp bCBwcm92aWRlciByZW1haW4NCg0KICAgb3BhcXVlIHRvIHRoZSB1c2VyLg0KDQoNCg0KYW5kIEkg dXNlIHRoZSAidGhpcyBpcyBub3Qgc3BhbSIgYnV0dG9uIG9uIGVtYWlsIGZhaXJseSBmcmVxdWVu dGx5LiBUaGUNCg0Kc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBkb2VzIHRhbGsgYWJv dXQgdGhlIHByb3RlY3RlZCBwYXJ0eQ0KDQpub3RpZnlpbmcgdGhlIHNlcnZpY2UgcHJvdmlkZXIg dXNpbmcgdW5zdGFuZGFyZGl6ZWQgbWVjaGFuaXNtcyAtIEkgc2VlDQoNCnRoYXQuIE1heWJlIGEg Zm9yd2FyZCBwb2ludGVyIHRvIHRoYXQgZGlzY3Vzc2lvbiB3b3VsZCBiZSBoZWxwZnVsLg0KDQoN Cg0KQXMgZmFyIGFzIEkga25vdywgdGhlcmUgaXMgcmVhbGx5IG5vIHN0YW5kYXJkIHNwYW0gKG9y IG5vLXNwYW0pIHByb3RvY29sIGluZGljYXRvciBpbiBlbWFpbC4gQWxsIHRoZSBuby1zcGFtIGJ1 dHRvbnMgZWl0aGVyIGp1c3QgaW5mbHVlbmNlIHNvbWUgbG9jYWwgTVVBIGJlaGF2aW9yIChlLmcu LCBjcmVhdGUgc29tZSBraW5kIG9mIHdoaXRlbGlzdCBlbnRyeSkgb3IgYXJlIHRyYW5zbGF0ZWQg dG8gSU1BUCBjb21tYW5kcyAoZS5nLiwgdG8gbW92ZSB0aGUgbWVzc2FnZSBvdXQgb2YgdGhlIHNw YW0gZm9sZGVyKS4NCg0KDQoNCkkgd2lsbCBhZGQgYSBmb3J3YXJkIHJlZmVyZW5jZS4NCg0KDQoN Ckhlbm5pbmcNCg== --_000_CY1PR09MB0634D07CE4FBCB61D9B53CBFEA100CY1PR09MB0634namp_ 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 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxh aW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TcGVuY2VyLDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIElubGluZSBiZWxv dy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJjb2xvcjojNEY4MUJEIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCkZyb206IFNwZW5jZXIgRGF3a2lucyBbbWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21h aWwuY29tXSA8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0 RjgxQkQiPkluIHRoaXMgdGV4dCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0 RjgxQkQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzRGODFCRCI+ Jm5ic3A7Jm5ic3A7IFRodXMsIHRoZSBjYWxsIGlzIHJlamVjdGVkIGR1ZSB0byB0aGUgY2FsbGVk IHBhcnR5J3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0RjgxQkQiPiZuYnNw OyZuYnNwOyAodGVtcG9yYXJ5KSBkaXNwb3NpdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM0RjgxQkQiPiZuYnNwOyZuYnNwOyA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iY29sb3I6IzRGODFCRCI+SSdtIGhhdmluZyB0cm91YmxlIG1hdGNoaW5nIGRpY3Rpb25h cnkgZGVmaW5pdGlvbnMgdG8gdGhlIHVzZSBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Y29sb3I6IzRGODFCRCI+JnF1b3Q7ZGlzcG9zaXRpb24mcXVvdDsgaGVyZS4gSSBndWVzcyBpdCdz IGFuIE9LIHVzZSBvZiB0aGUgd29yZCwgYW5kIEkga25vdyB3aGF0J3M8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM0RjgxQkQiPmludGVuZGVkIGJhc2VkIG9uIGNvbnRleHQgY2x1 ZXMsIGJ1dCBpZiBhbm90aGVyIHdvcmQgd291bGQgYmUgY2xlYXJlciw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM0RjgxQkQiPnRoYXQgd291bGQgYmUgaGVscGZ1bC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ SeKAmWxsIHJlcGxhY2UgYnkg4oCcc3RhdHVz4oCdLiBJIG1lYW50IHNvbWV0aGluZyBsaWtlIHRo ZSDigJxwcmVzZW5jZSBzdGF0dXPigJ0gKGJ1c3ksIGRyaXZpbmcsIGluIHRoZSBzaG93ZXIsIGV0 Yy4pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0RjgxQkQiPlRoaXMgdGV4dCw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0RjgxQkQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iY29sb3I6IzRGODFCRCI+Jm5ic3A7Jm5ic3A7IFRoZSBwYXJ0aWN1bGFyIHJl c3BvbnNlIGNvZGUgbnVtYmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojNEY4 MUJEIj4mbmJzcDsmbmJzcDsgd2FzIGNob3NlbiB0byByZWZsZWN0IHRoZSBkaXN0YXN0ZSBmZWx0 IGJ5IG1hbnkgdXBvbiByZWNlaXZpbmcgc3VjaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Y29sb3I6IzRGODFCRCI+Jm5ic3A7Jm5ic3A7IGNhbGxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iY29sb3I6IzRGODFCRCI+Jm5ic3A7Jm5ic3A7IDxvOnA+DQo8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJjb2xvcjojNEY4MUJEIj5pcyB1bmNoYW5nZWQgZnJvbSB0aGUgcHJldmlvdXMgdmVy c2lvbiwgd2hlcmUgdGhlIHJlc3BvbnNlIGNvZGUgbnVtYmVyPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJjb2xvcjojNEY4MUJEIj53YXMgNjY2LiBJcyB0aGF0IGludGVudGlvbmFsPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGlzIHdhcyBhbHNvIHBvaW50ZWQg b3V0IGJ5IEJyZXR0IFRhdGU7IEkgcmVtb3ZlZCB0aGUgbm93LW1lYW5pbmdsZXNzIHNlbnRlbmNl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0RjgxQkQi Pkp1c3QgY2hlY2tpbmcgLSBpbiB0aGlzIHRleHQsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM0RjgxQkQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29s b3I6IzRGODFCRCI+Jm5ic3A7Jm5ic3A7IFRoZSBzZXJ2aWNlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJjb2xvcjojNEY4MUJEIj4mbmJzcDsmbmJzcDsgcHJvdmlkZXIgZGVsaXZlcmluZyBj YWxscyBvciBtZXNzYWdlcyB0byB0aGUgdXNlciBpc3N1aW5nIHRoZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iY29sb3I6IzRGODFCRCI+Jm5ic3A7Jm5ic3A7IHJlc3BvbnNlIE1BWSB0YWtl IGEgcmFuZ2Ugb2YgYWN0aW9ucywgZm9yIGV4YW1wbGUsIGFkZCB0aGUgY2FsbGluZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzRGODFCRCI+Jm5ic3A7Jm5ic3A7IHBhcnR5IHRv IGEgcGVyc29uYWwgYmxhY2tsaXN0IHNwZWNpZmljIHRvIHRoZSBjYWxsZWQgcGFydHksIHVzZSB0 aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0RjgxQkQiPiZuYnNwOyZuYnNw OyBpbmZvcm1hdGlvbiBhcyBpbnB1dCB3aGVuIGNvbXB1dGluZyB0aGUgbGlrZWxpaG9vZCB0aGF0 IHRoZSBjYWxsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojNEY4MUJEIj4m bmJzcDsmbmJzcDsgcGFydHkgaXMgcGxhY2luZyB1bndhbnRlZCBjYWxscyAoJnF1b3Q7Y3Jvd2Qg c291cmNpbmcmcXVvdDspLCBpbml0aWF0ZSBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJj b2xvcjojNEY4MUJEIj4mbmJzcDsmbmJzcDsgdHJhY2ViYWNrIHJlcXVlc3QsIG9yIHJlcG9ydCB0 aGUgY2FsbGluZyBwYXJ0eSBpZGVudGl0eSB0byBjb25zdW1lcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iY29sb3I6IzRGODFCRCI+Jm5ic3A7Jm5ic3A7IGNvbXBsYWludCBkYXRhYmFzZXMg b3BlcmF0ZWQgYnkgZ292ZXJubWVudCBhdXRob3JpdGllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImNvbG9yOiM0RjgxQkQiPiZuYnNwOyZuYnNwOyA8bzpwPg0KPC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iY29sb3I6IzRGODFCRCI+dGhlcmUncyBubyBzdGFuZGFyZGl6ZWQgd2F5IGZvciB0 aGUgY2FsbGVkIHBhcnR5IHRvIHNpZ25hbCB0aGF0IHRoaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImNvbG9yOiM0RjgxQkQiPmFjdGlvbiBzaG91bGQgYmUgcmV2ZXJzZWQsIGlzIHRoZXJl PyBJIGFzaywgYmVjYXVzZSB0aGUgbmV4dCBwYXJhZ3JhcGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+SSBkb27igJl0IHNlZSBob3cgdGhpcyB3b3VsZCBiZSBwb3NzaWJs ZS4gT25jZSB5b3UgaGF2ZSByZWplY3RlZCB0aGUgY2FsbCwgaXTigJlzIGdvbmUuIChUaGF04oCZ cyB3aGVyZSB0aGUgZW1haWwgYW5hbG9neSBicmVha3MgZG93biwgYXMgdGhlIGNhbGwgaXNu4oCZ dCBqdXN0IGR1bXBlZCBpbnRvIGEgZm9sZGVyLikgUG9zdC1jYWxsIG1lY2hhbmlzbXMsIGUuZy4s IGZyb20NCiB0aGUgY2FsbCBsb2csIHdvdWxkIGxpa2VseSBiZSBzb21lIEhUVFAgQVBJLCBhcyBT SVAgd291bGRu4oCZdCBmaXQuIE1heWJlIHdlIGNhbiBkZWZpbmUgWUFORyBtb2RlbCwgc2luY2Ug aXTigJlzIHVzZWQgZm9yIGp1c3QgYWJvdXQgZXZlcnl0aGluZyBlbHNlDQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjpibGFjayI+Sjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJjb2xvcjojNEY4MUJEIj5zYXlzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iY29sb3I6IzRGODFCRCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJj b2xvcjojNEY4MUJEIj4mbmJzcDsmbmJzcDsgVGhlIHVzZXIgZXhwZXJpZW5jZSBpcyBlbnZpc2lv bmVkIHRvIGJlIHNvbWV3aGF0IHNpbWlsYXIgdG8gZW1haWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImNvbG9yOiM0RjgxQkQiPiZuYnNwOyZuYnNwOyBzcGFtIGJ1dHRvbnMgd2hlcmUgdGhl IGRldGFpbGVkIGFjdGlvbnMgb2YgdGhlIGVtYWlsIHByb3ZpZGVyIHJlbWFpbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzRGODFCRCI+Jm5ic3A7Jm5ic3A7IG9wYXF1ZSB0byB0 aGUgdXNlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0RjgxQkQiPiZuYnNw OyZuYnNwOyA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzRGODFCRCI+YW5k IEkgdXNlIHRoZSAmcXVvdDt0aGlzIGlzIG5vdCBzcGFtJnF1b3Q7IGJ1dHRvbiBvbiBlbWFpbCBm YWlybHkgZnJlcXVlbnRseS4gVGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjoj NEY4MUJEIj5zZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGRvZXMgdGFsayBhYm91dCB0 aGUgcHJvdGVjdGVkIHBhcnR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojNEY4 MUJEIj5ub3RpZnlpbmcgdGhlIHNlcnZpY2UgcHJvdmlkZXIgdXNpbmcgdW5zdGFuZGFyZGl6ZWQg bWVjaGFuaXNtcyAtIEkgc2VlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojNEY4 MUJEIj50aGF0LiBNYXliZSBhIGZvcndhcmQgcG9pbnRlciB0byB0aGF0IGRpc2N1c3Npb24gd291 bGQgYmUgaGVscGZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFzIGZh ciBhcyBJIGtub3csIHRoZXJlIGlzIHJlYWxseSBubyBzdGFuZGFyZCBzcGFtIChvciBuby1zcGFt KSBwcm90b2NvbCBpbmRpY2F0b3IgaW4gZW1haWwuIEFsbCB0aGUgbm8tc3BhbSBidXR0b25zIGVp dGhlciBqdXN0IGluZmx1ZW5jZSBzb21lIGxvY2FsIE1VQSBiZWhhdmlvciAoZS5nLiwgY3JlYXRl IHNvbWUga2luZCBvZiB3aGl0ZWxpc3QgZW50cnkpIG9yIGFyZSB0cmFuc2xhdGVkIHRvIElNQVAN CiBjb21tYW5kcyAoZS5nLiwgdG8gbW92ZSB0aGUgbWVzc2FnZSBvdXQgb2YgdGhlIHNwYW0gZm9s ZGVyKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JIHdpbGwgYWRkIGEgZm9yd2Fy ZCByZWZlcmVuY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkhlbm5p bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR09MB0634D07CE4FBCB61D9B53CBFEA100CY1PR09MB0634namp_-- From nobody Thu Apr 27 19:43: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 318F112778E; Thu, 27 Apr 2017 19:43:50 -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 U4k5ARHhKg43; Thu, 27 Apr 2017 19:43:47 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 DB33E129506; Thu, 27 Apr 2017 19:41:13 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id k11so24908524ywb.1; Thu, 27 Apr 2017 19:41:13 -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=9Tp6awHPjgM50swjdWFdO8Fd16rqc9PASESqWC//gfc=; b=uctYY6umYx3rX+R7e83uBMjoUt9UkuPkk14Tsyt8pDsHi4LOgQyfj4w6MJnyqY4rWh 3XMJZ6sYZt8k9iDuycxvTv3a0+P6SdBzSY0ROHwBHWe5L1CL9cgp7o6Z1rmRp+AIourG P4U0rbNasLB9nqaSRaicAijQU3jTHhpilRVNevRtmjZaIqL/9CjvAXpcQH7qqBXn58kM f+E8zp9MFXQ7HTkTr2MuqUaKcGE7r0C8PrgbPhDjDvDeeRjlVv+HtoBBodmt0gfomYgX iWTSONshkfsX2ORopZb4FkEoCyJQNxVT3fuGbzC/43aKHbguB+bv27pYdevxu8yw6SDG z5ag== 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=9Tp6awHPjgM50swjdWFdO8Fd16rqc9PASESqWC//gfc=; b=LXhlDNlm9Cq84oq+683iSblXeZy6fsYBajkKCQuHr6f9JnMW2G4FzeUKZFprthPiLr ObPF7zH5eKxWf5XB8/mn89XzZ7mGNY8t9HMsRD0PgX/TcQojFt/vNrla8MoF/X7Tu0W9 mqJe81AJHL+Q/ZErOReqkbgkp+iyRGeTXaO8GQd92kucKe8ZkHGs4f1zy5pqUkB2hKxV JSG+yoxAYmegzTdom+m3b8mC3Lo8r8WaGnm7Vw0LUHuHAub1KY8bp9uOUzB9CCe1T35i iucAzelXZdSIrn1yYm57EexNAK4sthYQburmTvtGi9Kme6jLbr6LNkhs6cv3e2HLK7kZ MUEw== X-Gm-Message-State: AN3rC/5N2boesihyUDIAVDWJIHXoovcZGWUD9Rn8UyjH/FtmhV9fyQEw DV6k9aaVb2aRz7n2Tc9f6hd/1mYwhw== X-Received: by 10.129.129.197 with SMTP id r188mr7077222ywf.289.1493347273105; Thu, 27 Apr 2017 19:41:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.161.198 with HTTP; Thu, 27 Apr 2017 19:41:12 -0700 (PDT) Received: by 10.37.161.198 with HTTP; Thu, 27 Apr 2017 19:41:12 -0700 (PDT) In-Reply-To: References: <149322647121.14925.7574406005591553723.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Thu, 27 Apr 2017 21:41:12 -0500 Message-ID: To: Henning Schulzrinne Cc: sipcore-chairs@ietf.org, "draft-ietf-sipcore-status-unwanted@ietf.org" , The IESG , "sipcore@ietf.org" , "adam@nostrum.com" Content-Type: multipart/alternative; boundary=94eb2c081298bd8015054e310161 Archived-At: Subject: Re: [sipcore] Spencer Dawkins' Yes on draft-ietf-sipcore-status-unwanted-05: (with COMMENT) 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, 28 Apr 2017 02:43:50 -0000 --94eb2c081298bd8015054e310161 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Henning, Top posting to say this is all fine, and thanks for the quick response! Spencer On Apr 27, 2017 15:54, "Henning Schulzrinne" wrote: Spencer, Thanks for your comments. Inline below. -----Original Message----- From: Spencer Dawkins [mailto:spencerdawkins.ietf@gmail.com] In this text, Thus, the call is rejected due to the called party's (temporary) disposition. I'm having trouble matching dictionary definitions to the use of "disposition" here. I guess it's an OK use of the word, and I know what's intended based on context clues, but if another word would be clearer, that would be helpful. I=E2=80=99ll replace by =E2=80=9Cstatus=E2=80=9D. I meant something like th= e =E2=80=9Cpresence status=E2=80=9D (busy, driving, in the shower, etc.). This text, The particular response code number was chosen to reflect the distaste felt by many upon receiving such calls. is unchanged from the previous version, where the response code number was 666. Is that intentional? This was also pointed out by Brett Tate; I removed the now-meaningless sentence. Just checking - in this text, The service provider delivering calls or messages to the user issuing the response MAY take a range of actions, for example, add the calling party to a personal blacklist specific to the called party, use the information as input when computing the likelihood that the calling party is placing unwanted calls ("crowd sourcing"), initiate a traceback request, or report the calling party identity to consumer complaint databases operated by government authorities. there's no standardized way for the called party to signal that this action should be reversed, is there? I ask, because the next paragraph I don=E2=80=99t see how this would be possible. Once you have rejected the = call, it=E2=80=99s gone. (That=E2=80=99s where the email analogy breaks down, as = the call isn=E2=80=99t just dumped into a folder.) Post-call mechanisms, e.g., from the call log, would likely be some HTTP API, as SIP wouldn=E2=80=99t fit. Maybe we can de= fine YANG model, since it=E2=80=99s used for just about everything else J says, The user experience is envisioned to be somewhat similar to email spam buttons where the detailed actions of the email provider remain opaque to the user. and I use the "this is not spam" button on email fairly frequently. The security considerations section does talk about the protected party notifying the service provider using unstandardized mechanisms - I see that. Maybe a forward pointer to that discussion would be helpful. As far as I know, there is really no standard spam (or no-spam) protocol indicator in email. All the no-spam buttons either just influence some local MUA behavior (e.g., create some kind of whitelist entry) or are translated to IMAP commands (e.g., to move the message out of the spam folder). I will add a forward reference. Henning --94eb2c081298bd8015054e310161 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Henning,

Top posting to say this is all fine, and thanks for the quick r= esponse!

Spencer

On Apr 27, 2017 15:54, "Henning Schulzrinne" <Henning.Schulzrinne@fcc.gov&= gt; wrote:

Spencer,

=C2=A0

Thanks for your comments. I= nline below.

=C2=A0

= -----Original Message-----
From: Spencer Dawkins [mailto:spencerdawkins.ietf@gmail.com]

= In this text,

= =C2=A0

= =C2=A0=C2=A0 Thus, the call is rejected due t= o the called party's

= =C2=A0=C2=A0 (temporary) disposition.<= u>

= =C2=A0=C2=A0

= I'm having trouble matching dictionary de= finitions to the use of

= "disposition" here. I guess it'= s an OK use of the word, and I know what's

= intended based on context clues, but if anoth= er word would be clearer,

= that would be helpful.

=C2=A0

I=E2=80=99ll replace by =E2=80=9Cstatus=E2=80=9D. I meant something = like the =E2=80=9Cpresence status=E2=80=9D (busy, driving, in the shower, e= tc.).

=C2=A0

=C2=A0

= This text,

= =C2=A0

= =C2=A0=C2=A0 The particular response code num= ber

= =C2=A0=C2=A0 was chosen to reflect the distas= te felt by many upon receiving such

= =C2=A0=C2=A0 calls.

= =C2=A0=C2=A0

= is unchanged from the previous version, where= the response code number

= was 666. Is that intentional?

=C2=A0

This was also pointed out by Brett Tate; I removed the now-meaningle= ss sentence.

=C2=A0

=C2=A0

= Just checking - in this text,

= =C2=A0

= =C2=A0=C2=A0 The service=

= =C2=A0=C2=A0 provider delivering calls or mes= sages to the user issuing the

= =C2=A0=C2=A0 response MAY take a range of act= ions, for example, add the calling

= =C2=A0=C2=A0 party to a personal blacklist sp= ecific to the called party, use the

= =C2=A0=C2=A0 information as input when comput= ing the likelihood that the calling

= =C2=A0=C2=A0 party is placing unwanted calls = ("crowd sourcing"), initiate a

= =C2=A0=C2=A0 traceback request, or report the= calling party identity to consumer

= =C2=A0=C2=A0 complaint databases operated by = government authorities.

= =C2=A0=C2=A0

= there's no standardized way for the calle= d party to signal that this

= action should be reversed, is there? I ask, b= ecause the next paragraph

=C2=A0

I don=E2=80=99t see how this would be possible. Once you have reject= ed the call, it=E2=80=99s gone. (That=E2=80=99s where the email analogy bre= aks down, as the call isn=E2=80=99t just dumped into a folder.) Post-call m= echanisms, e.g., from the call log, would likely be some HTTP API, as SIP wouldn=E2=80=99t fit. = Maybe we can define YANG model, since it=E2=80=99s used for just about ever= ything else J

=C2=A0

= says,

= =C2=A0

= =C2=A0=C2=A0 The user experience is envisione= d to be somewhat similar to email

= =C2=A0=C2=A0 spam buttons where the detailed = actions of the email provider remain

= =C2=A0=C2=A0 opaque to the user.

= =C2=A0=C2=A0

= and I use the "this is not spam" bu= tton on email fairly frequently. The

= security considerations section does talk abo= ut the protected party

= notifying the service provider using unstanda= rdized mechanisms - I see

= that. Maybe a forward pointer to that discuss= ion would be helpful.

=C2=A0

As far as I know, the= re is really no standard spam (or no-spam) protocol indicator in email. All= the no-spam buttons either just influence some local MUA behavior (e.g., c= reate some kind of whitelist entry) or are translated to IMAP commands (e.g., to move the message out of the spam folder).=

=C2=A0

I will add a forward reference.

=C2=A0

Henning


--94eb2c081298bd8015054e310161-- From nobody Thu Apr 27 23:59:53 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 ABA271200F1; Thu, 27 Apr 2017 23:59:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149336279266.2903.8274560697182713470@ietfa.amsl.com> Date: Thu, 27 Apr 2017 23:59:52 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-content-id-03.txt 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: Fri, 28 Apr 2017 06:59:53 -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-03.txt Pages : 8 Date : 2017-04-27 Abstract: This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP). The document also updates RFC 5621, to enable a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-content-id/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-content-id-03 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-content-id-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-content-id-03 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 Apr 28 00:04: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 A4A9C1201FA for ; Fri, 28 Apr 2017 00:04:36 -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, 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 f9lVZ2kduTbI for ; Fri, 28 Apr 2017 00:04:35 -0700 (PDT) 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 C0F7A1279EB for ; Fri, 28 Apr 2017 00:01:32 -0700 (PDT) X-AuditID: c1b4fb30-af94d9a000001047-f9-5902e8cb9b27 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F4.27.04167.AC8E2095; Fri, 28 Apr 2017 09:01:31 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0339.000; Fri, 28 Apr 2017 09:01:07 +0200 From: Christer Holmberg To: "sipcore@ietf.org" CC: SIPCORE Chairs Thread-Topic: Draft new version: draft-content-id-03 Thread-Index: AQHSv+01ypb30qoHLkeKEaNnKrzfGw== Date: Fri, 28 Apr 2017 07:01:06 +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.2.170228 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D528C4821BD28christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7tO7pF0yRBk19vBanXp1mtvj6YxOb A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJXRe+UYS8FSzoobTz+zNTB2cHQxcnJICJhI vPv9mLWLkYtDSOAIo8TCjjvsEM4SRonH8x8zdTFycLAJWEh0/9MGaRAR0JRY/m0rO4jNLGAk seDeB7ASYQF9ib0NCRAlJhIPmvYzgoRFBPQk3qwVAAmzCKhKHD78hQUkzCtgLXHzsAFImFFA TOL7qTVMEAPFJW49mc8EcZmAxJI955khbFGJl4//sYLYokAT9/37ygYyRkJAUWJ5vxxEa4JE 86ZXYK28AoISJ2c+YZnAKDwLydRZSMpmISmDiOtILNj9iQ3C1pZYtvA1M4x95sBjqF5rif3z JzIiq1nAyLGKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzCeDm75bbCD8eVzx0OMAhyMSjy8 CT8ZI4VYE8uKK3MPMUpwMCuJ8EomMkUK8aYkVlalFuXHF5XmpBYfYpTmYFES53XcdyFCSCA9 sSQ1OzW1ILUIJsvEwSnVwMgz/cQlH983yqKnLTLYVj3Uab9eXvp2wuMSY76LbH1mh8x2Hw/t 81B+csI480TYhWNtZxv9blnwBDPNf/pYZinnTB0VcwnT0MXtR76datixaeFD5p+SJZebPSNl T7DsMjNfbeDOLFLZ0dxxI/10hrTJh/WbHvCwFjHsiIzkvn7NesZEE/nF/UosxRmJhlrMRcWJ AEiFz8mjAgAA Archived-At: Subject: [sipcore] Draft new version: draft-content-id-03 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, 28 Apr 2017 07:04:37 -0000 --_000_D528C4821BD28christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the comments, we have submitted a new version (-03) of draft-conte= nt-id. Thanks to everyone who provided feedback and comments! :) Regards, Christer --_000_D528C4821BD28christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <379CB10B06582B4F88C4979B8E0E5318@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Based on the comments, we have submitted a new version (-03) of draft-= content-id.

Thanks to everyone who provided feedback and comments! :)

Regards,

Christer
--_000_D528C4821BD28christerholmbergericssoncom_-- From nobody Sun Apr 30 13:48: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 52289129441 for ; Sun, 30 Apr 2017 13:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.766 X-Spam-Level: X-Spam-Status: No, score=0.766 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 RI-UZ2qzCH53 for ; Sun, 30 Apr 2017 13:48:27 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 3F996127863 for ; Sun, 30 Apr 2017 13:46:15 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-01v.sys.comcast.net with SMTP id 4vj8dIaoPO3Qo4vjSdGiY5; Sun, 30 Apr 2017 20:46:14 +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 4vjRd4fGSStKd4vjRdW8lK; Sun, 30 Apr 2017 20:46:14 +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 v3UKk7tR026757 for ; Sun, 30 Apr 2017 16:46:07 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v3UKk7eP026753; Sun, 30 Apr 2017 16:46:07 -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: Sun, 30 Apr 2017 16:46:07 -0400 Message-ID: <87bmrdmxo0.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfGLUi1mH9sRdvbUnPP8yPuY43C03VzQwZxwQueBeZ3F8UTwixdtS5zeLdiWh4SSsyLnO+VsC/WuOttwtNhLs78pVkWXVGqJBZMpQBoyYuQejFpmWCFzG bB2MUHRZBU598iRXs44AtpMrotWeJUkW2txcdhiGDQcUPUz53WEelexu Archived-At: Subject: [sipcore] Proposal to revise the dual stack milestone 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, 30 Apr 2017 20:48:28 -0000 The Sipcore working group has the following milestone listed (at https://datatracker.ietf.org/wg/sipcore/about/): Dec 2017 Request publication of mechanisms for rapid dual-stack protocol selection in SIP The draft draft-johansson-sip-he-connection is listed for this milestone. However, that draft covers only a narrow subset of the overall problem. Over the past month or so, I have been canvassing Sipcore members to find out if there is any practical demand for a dual-stack solution for SIP. With the exception of a particular case, I have found no interest. Because of this, I propose that we narrow the scope of this milestone to the one case for which I have found interest: Request publication of a mechanism for rapid dual-stack protocol selection in SIP when the destination has multiple, unprioritized targets for connection-oriented protocols Conveniently, draft-johansson-sip-he-connection describes such a mechanism. Its mechanism closely parallels that of RFC 6555 ("Happy Eyeballs"), and the text is essentially complete. Because there are no unresolved technical issues, the text is complete, and there are known implementation instances where this mechanism is needed, I urge the approval of this draft even if its scope is narrow. Dale