From nobody Tue Jul 4 02:57:42 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 4A1EF131D2E; Tue, 4 Jul 2017 02:57:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Elwyn Davies To: Cc: draft-ietf-sipcore-content-id.all@ietf.org, sipcore@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149916225425.16088.10318703158229973440@ietfa.amsl.com> Date: Tue, 04 Jul 2017 02:57:34 -0700 Archived-At: Subject: [sipcore] Genart telechat review of draft-ietf-sipcore-content-id-07 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, 04 Jul 2017 09:57:34 -0000 Reviewer: Elwyn Davies Review result: Ready 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-sipcore-content-id-07 Reviewer: Elwyn Davies Review Date: 2017-07-04 IETF LC End Date: 2017-06-27 IESG Telechat date: 2017-07-06 Summary: Ready. Thank you for addressing the comments in my last call review. Major issues: Minor issues: Nits/editorial comments: The references to RFC 5368 and RFC 6442 are informative rather than normative - you don't need the details to implement this update. From nobody Wed Jul 5 05:09:36 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 7EE87131CB7; Wed, 5 Jul 2017 05:09:35 -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-content-id@ietf.org, Jean Mahoney , sipcore-chairs@ietf.org, mahoney@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> Date: Wed, 05 Jul 2017 05:09:35 -0700 Archived-At: Subject: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and 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, 05 Jul 2017 12:09:35 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-sipcore-content-id-07: Discuss 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-content-id/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This document really needs some discussion of the interoperability implications of this change. Assuming I understand correctly, it is not possible to use this mechanism with any existing content type, because receiving implementations will expect to see a multipart and thus refuse to accept the message. Is that correct? If so, it seems like a limitation which needs to be called out explicitly ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document seems rather gratuitous to me. I agree it's somewhat of a misfeature not to be able to have Content-ID in the SIP headers, but as the examples in this document make clear, there's a straightforward workaround. It's unclear to me that there is actually sufficient benefit to this mechanism to publishing a standards track document with this change. From nobody Wed Jul 5 06:12:12 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 9DDE91329D8; Wed, 5 Jul 2017 06:12:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-sipcore-content-id@ietf.org, Jean Mahoney , sipcore-chairs@ietf.org, mahoney@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149926032463.17322.13484382609710818569.idtracker@ietfa.amsl.com> Date: Wed, 05 Jul 2017 06:12:04 -0700 Archived-At: Subject: [sipcore] Alissa Cooper's No Objection on draft-ietf-sipcore-content-id-07: (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, 05 Jul 2017 13:12:05 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sipcore-content-id-07: 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-content-id/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Per the Gen-ART review, the references to RFC 5368 and RFC 6442 should be informative rather than normative. From nobody Wed Jul 5 06:13:00 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1F8131CB0; Wed, 5 Jul 2017 06:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, URIBL_BLOCKED=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=drOJFlW0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ONXfzMNp 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 xZWgyL17vBSA; Wed, 5 Jul 2017 06:12:52 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45140131CD4; Wed, 5 Jul 2017 06:12:52 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A1AA020880; Wed, 5 Jul 2017 09:12:51 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 05 Jul 2017 09:12:51 -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=ohcjPMKf+spwcGgVOi ZoPA870E5AghQv5L7Z2b7v8EM=; b=drOJFlW0i1kJGibS65BqAYEWn64epPNGzp vdnY4ZF69G2bJZ6BL1HTzAHWvQnz7BtFz0h2LlhyAUo0dbGEb0GHbFmQvAtIYyx9 MJQyS/SA5eEaMTG2VZW+qZebkt137Ar6N7WpoyU3IvZku4+9IjMkZvujKAllMjws 80Ivvv+mD3hMsydYE9ZxzdJS3LBdmyr8gm6EHuyo0ZbrHvacn288e6zMorGQDaMy Iaj5TvDiGWnljn8+GiAKs3BhK7priouLqp+AB8sJAaps44LBAtCjI6vp7Sj9brF7 mGy+oLj8C3ATytledCDiKjvmu8c0g+8sERJpypQoMK5zt3jPeNEw== 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=ohcjPMKf+spwcGgVOiZoPA870E5AghQv5L7Z2b7v8EM=; b=ONXfzMNp 4sar7XBlFbNtfpvmAMi4AN4QEYzyHXXv9bFpsA3XEj9+/F5Md+ILqSbkkB9Rp6Tm pR6dogzff3TYByNE85QV782xvhrZacvphEkGo3Ia344B8IDCIfkVVY4/NgTMCtcX Uczx4w1fDULDNRb5RenTiHmftJT2lN/UEP0+aPpxQb7H1OyrlE5pdCcvKV5KcevA E5HFulN6dLAKAAGh1Ev7tNIhhlfbQ9EQZQ1ypdiBC9DXrG7V97YOGz0/1DiGWH6t nusO6S8zZzipq8JIokc1YQd5o67o6K7CNhzyrwUFMpmIcqHgmcenWQ2homwaHC5G 6DWhGvPxRESQhw== X-ME-Sender: X-Sasl-enc: fRbvC6HTFvrBLzgDJZQIKrAo59Z/Am4DnQkEB+kPDKWj 1499260371 Received: from sjc-alcoop-8814.cisco.com (unknown [128.107.241.163]) by mail.messagingengine.com (Postfix) with ESMTPA id 97DBE7E46B; Wed, 5 Jul 2017 09:12:50 -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: <149916225425.16088.10318703158229973440@ietfa.amsl.com> Date: Wed, 5 Jul 2017 09:12:49 -0400 Cc: gen-art , draft-ietf-sipcore-content-id.all@ietf.org, sipcore@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5605F756-848C-4691-809F-497F3CA288CB@cooperw.in> References: <149916225425.16088.10318703158229973440@ietfa.amsl.com> To: Elwyn Davies X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sipcore] [Gen-art] Genart telechat review of draft-ietf-sipcore-content-id-07 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 Jul 2017 13:12:54 -0000 Elwyn, thanks for your review. Authors, thanks for addressing his = comments. I have entered a No Objection ballot position. Alissa > On Jul 4, 2017, at 5:57 AM, Elwyn Davies = wrote: >=20 > Reviewer: Elwyn Davies > Review result: Ready >=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 wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-sipcore-content-id-07 > Reviewer: Elwyn Davies > Review Date: 2017-07-04 > IETF LC End Date: 2017-06-27 > IESG Telechat date: 2017-07-06 >=20 > Summary: > Ready. Thank you for addressing the comments in my last call review. >=20 > Major issues: >=20 > Minor issues: >=20 > Nits/editorial comments: > The references to RFC 5368 and RFC 6442 are informative rather than = normative - > you don't need the details to implement this update. >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Jul 5 07:39: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 321B9131D38 for ; Wed, 5 Jul 2017 07:39: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 pX5esEWeg01N for ; Wed, 5 Jul 2017 07:39:51 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 DE8B6131D30 for ; Wed, 5 Jul 2017 07:39:50 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-11v.sys.comcast.net with SMTP id SlT4dAF3kxSSiSlT4dW4E9; Wed, 05 Jul 2017 14:39:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1499265590; bh=KmUowQrADJze3ILKxBJvrbstoi6jjAF1NAx0BKk/YxE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=aNvBRFTSLT7lolZtnDLq+g7W9DsoYDD3bcG3nyoW6lO4kyQr0Fc6IPNKPg6EKSF7c AJ+md3+Nyvqp6OsNtyCytCV/3LqccwzQBszaOwUtiAvv4I/Ic3ajxJgcxvZ6w26q0A vs2sFmGd3ReZ41W0YtMqMoVfQHVou8d5mdOqwI+AXGlzrWuWkEMwfVrcFxK/C0NSJX eRgP7JdAGMRwv9vy+QF/NLmCtjpqhUrGcPHyhz+IRA0DXc/hVgK6MuDOLolgk/OFYb n1YugyFaxgTWuvMwhkP88bXaH08600s6PsjGfhqnjk3AiFtTatLyFwpd6edpJVOLKm RRb4jepHIYr+Q== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-07v.sys.comcast.net with SMTP id SlT3db2uHfkY7SlT3d6H7o; Wed, 05 Jul 2017 14:39:50 +0000 To: sipcore@ietf.org References: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <3de68d8b-193d-71ed-3a63-767cbad0762a@comcast.net> Date: Wed, 5 Jul 2017 10:39:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfCCisa96ph4n2AAxKUujj7QVXQcNEBczG82QMleZCc2glQ9NJJleO1KNa8Tnzjkink6kV4K0W59P3TCQ4xBIjjUXQOfTQh/3rOX3xwXg0rtPNo+uAcjm GUy7jSRNozMY2QFOZ/me6MXrCARgWUHfJS+jHYe4wk6fs/8QUMT6EyvKyFNfIyTXSIwyiX/DrnVSxQ== Archived-At: Subject: Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and 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, 05 Jul 2017 14:39:52 -0000 EKR, On 7/5/17 8:09 AM, Eric Rescorla wrote: > This document really needs some discussion of the interoperability implications > of this change. Assuming I understand correctly, it is not possible to use this > mechanism with any existing content type, because receiving implementations > will expect to see a multipart and thus refuse to accept the message. Is that > correct? If so, it seems like a limitation which needs to be called out > explicitly I don't see how "with any existing content type" has relevance here. The impact, if any, has to do with *references* (via cid: URLs in the sip message). The impact would occur with some existing implementation that already has code to dereference a cid url in some context, but only knows to search for the reference starting in a multipart body. In that case, if the sender follows this document then the reference may not be resolved. That perhaps does deserve some discussion. Thanks, Paul From nobody Wed Jul 5 08:06:04 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 04674131D53; Wed, 5 Jul 2017 08:06:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-sipcore-content-id@ietf.org, Jean Mahoney , sipcore-chairs@ietf.org, mahoney@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149926716100.19029.6886729336629315644.idtracker@ietfa.amsl.com> Date: Wed, 05 Jul 2017 08:06:01 -0700 Archived-At: Subject: [sipcore] Adam Roach's Yes on draft-ietf-sipcore-content-id-07: (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, 05 Jul 2017 15:06:01 -0000 Adam Roach has entered the following ballot position for draft-ietf-sipcore-content-id-07: 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-content-id/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm a little surprised that the document didn't end up with any text detailing the historical context for formally adding this mechanism. I would expect to see some discussion explaining that the use of Content-ID as a SIP header field has been inferred as acceptable for years, and that so many IETF participants had taken it as given that Content-ID was *already* a registered SIP header field that it appears in examples in (for example) RFCs 5368 and 6080. While I think the document would serve its intended purpose as-is, I believe that more explanatory text in the Introduction section to clarify that this is an attempt to formalize already-assumed (and likely deployed) behavior -- rather than simply casting it as a minor optimization -- would go a long way towards dealing with Eric's concerns. From nobody Wed Jul 5 11:02:17 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 85EBE131445; Wed, 5 Jul 2017 11:02:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-sipcore-content-id@ietf.org, Jean Mahoney , sipcore-chairs@ietf.org, mahoney@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149927773554.10408.3291321741889969419.idtracker@ietfa.amsl.com> Date: Wed, 05 Jul 2017 11:02:15 -0700 Archived-At: Subject: [sipcore] Warren Kumari's No Objection on draft-ietf-sipcore-content-id-07: (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, 05 Jul 2017 18:02:15 -0000 Warren Kumari has entered the following ballot position for draft-ietf-sipcore-content-id-07: 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-content-id/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm following EKR's discuss on the interoperability / backward compatibility implications. From nobody Wed Jul 5 11:25: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 1007C131B5F; Wed, 5 Jul 2017 11:25:30 -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 Z_0wXMIX6J9W; Wed, 5 Jul 2017 11:25:28 -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 7ED4D131845; Wed, 5 Jul 2017 11:25:27 -0700 (PDT) X-AuditID: c1b4fb30-aeec49c000001664-b8-595d2f1593ae Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 69.6D.05732.51F2D595; Wed, 5 Jul 2017 20:25:25 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Wed, 5 Jul 2017 20:25:25 +0200 From: Christer Holmberg To: Alissa Cooper , The IESG CC: "draft-ietf-sipcore-content-id@ietf.org" , Jean Mahoney , "sipcore-chairs@ietf.org" , "mahoney@nostrum.com" , "sipcore@ietf.org" Thread-Topic: Alissa Cooper's No Objection on draft-ietf-sipcore-content-id-07: (with COMMENT) Thread-Index: AQHS9ZBNVc3+q2Xip0y1HtAJIKT+YKJFjLug Date: Wed, 5 Jul 2017 18:25:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC5099B@ESESSMB109.ericsson.se> References: <149926032463.17322.13484382609710818569.idtracker@ietfa.amsl.com> In-Reply-To: <149926032463.17322.13484382609710818569.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7uq6ofmykwbXrGhbTz/xltDj9dQaT xYw/E5ktGjpXslr0fl7IbPH1xyY2BzaPL09eMnksWfKTyWPWzicsAcxRXDYpqTmZZalF+nYJ XBmd27ezFHzirJg0YSJrA+MFzi5GTg4JAROJz9/3M3cxcnEICRxhlLjf08gE4SxilPi6+w5L FyMHB5uAhUT3P22QBhEBe4lpV3+wgdQwC3QwSWx+fYEVJCEsEC/xfW0fE0RRgsTauwtYQXpF BIwk7v8WBwmzCKhI9Cy8xwJi8wr4SrRcf8YIYgsJ+En8WXAMbAyngL/E/cdt7CA2o4CYxPdT a8BGMguIS9x6Mp8J4mgBiSV7zjND2KISLx//Y4WwlSQW3f7MBLKWWUBTYv0ufYhWRYkp3Q/Z IdYKSpyc+YRlAqPoLCRTZyF0zELSMQtJxwJGllWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsY gVF1cMtvgx2ML587HmIU4GBU4uH1ko+NFGJNLCuuzD3EKMHBrCTCq60KFOJNSaysSi3Kjy8q zUktPsQozcGiJM7ruO9ChJBAemJJanZqakFqEUyWiYNTqoExpm/Wi+Bb2ffzl77yejLlzDoj Y6lb/31qnnoXHb1ap58Y+rS1//e5D7/XKl1zV0spuH9E5qD2l1q2V1eubJ705rRvX8O+exfc RcL5zF5YZ3MsWmJ4yDbxi3Quk4G1dvW0rNLEXO8PafnGC2+ccPYOaWPYFqwknm+/fbb6i+2r l1+vrnqTI7FPiaU4I9FQi7moOBEAdAE4p6YCAAA= Archived-At: Subject: Re: [sipcore] Alissa Cooper's No Objection on draft-ietf-sipcore-content-id-07: (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, 05 Jul 2017 18:25:30 -0000 SGksDQoNCj5BbGlzc2EgQ29vcGVyIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv c2l0aW9uIGZvcg0KPmRyYWZ0LWlldGYtc2lwY29yZS1jb250ZW50LWlkLTA3OiBObyBPYmplY3Rp b24NCj4NCj5XaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50 YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzID5pbmNsdWRlZCBpbiB0aGUgVG8g YW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3Jh cGgsIGhvd2V2ZXIuKQ0KPg0KPlBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9p ZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj5mb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPg0KPlRoZSBkb2N1 bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVy ZToNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNpcGNvcmUt Y29udGVudC1pZC8NCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Q09NTUVOVDoNCj4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+DQo+UGVyIHRoZSBHZW4tQVJUIHJldmlldywgdGhlIHJlZmVyZW5jZXMgdG8gUkZDIDUzNjgg YW5kIFJGQyA2NDQyIHNob3VsZCBiZSA+aW5mb3JtYXRpdmUgcmF0aGVyIHRoYW4gbm9ybWF0aXZl Lg0KDQpXZSdsbCBtYWtlIHRoZSByZWZlcmVuY2VzIGluZm9ybWF0aXZlLg0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0K From nobody Wed Jul 5 11:34: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 D34BA131DB8; Wed, 5 Jul 2017 11:34:01 -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 uuAvzPILdf9c; Wed, 5 Jul 2017 11:34: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 5A585131DB4; Wed, 5 Jul 2017 11:33:59 -0700 (PDT) X-AuditID: c1b4fb2d-803ff70000005faa-fc-595d3115a3da Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8D.43.24490.5113D595; Wed, 5 Jul 2017 20:33:57 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Wed, 5 Jul 2017 20:33:57 +0200 From: Christer Holmberg To: Adam Roach , The IESG CC: "draft-ietf-sipcore-content-id@ietf.org" , Jean Mahoney , "sipcore-chairs@ietf.org" , "mahoney@nostrum.com" , "sipcore@ietf.org" Thread-Topic: Adam Roach's Yes on draft-ietf-sipcore-content-id-07: (with COMMENT) Thread-Index: AQHS9aA4+0ECD8hNcU6WTJhBLu9mp6JFjt/A Date: Wed, 5 Jul 2017 18:33:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC50A6A@ESESSMB109.ericsson.se> References: <149926716100.19029.6886729336629315644.idtracker@ietfa.amsl.com> In-Reply-To: <149926716100.19029.6886729336629315644.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbE9UFfUMDbSoPOAusWev4vYLU5/ncFk MePPRGaLhs6VrBa9nxcyW3z9sYnNgc1jyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4Mr4cuoS S8EysYorzXINjHdEuxg5OSQETCQWbX/P1MXIxSEkcIRRYvrmW4wQziJGie3n77B1MXJwsAlY SHT/0wZpEBGwljjdfJIZpIZZoINJYvPrC6wgCWGBYImJiyYxQxSFSFyYt54NwjaSaG7sZwSx WQRUJKa1rAWr5xXwleja+50dxBYCsh8/384MsotTwE/i4v1okDCjgJjE91NrmEBsZgFxiVtP 5jNBHC0gsWTPeWYIW1Ti5eN/rBC2ksSi25+ZQMYwC2hKrN+lD9GqKDGl+yE7xFZBiZMzn7BM YBSdhWTqLISOWUg6ZiHpWMDIsopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMJIObvmtu4Nx 9WvHQ4wCHIxKPLzLZGIjhVgTy4orcw8xSnAwK4nwTtUDCvGmJFZWpRblxxeV5qQWH2KU5mBR Eud12HchQkggPbEkNTs1tSC1CCbLxMEp1cCYXSDw/gL3PcEKNc3NLtXZeosVTi97P28f97Rn 3XvV79zYMONdwa+W6Sutfbbdf3mKke/Zm766c22bP1hw9pq+98y+d5T198XNvW8vJTrtNjad WKbmn2nJtlKjiyV58sPeJb3mM+pTf0yTVgnxnc28md/AVH5p6yGLt5fy1Dh4lYT7cg9tWcio xFKckWioxVxUnAgAhwDgoKACAAA= Archived-At: Subject: Re: [sipcore] Adam Roach's Yes on draft-ietf-sipcore-content-id-07: (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, 05 Jul 2017 18:34:02 -0000 SGkgQWRhbSwNCg0KSSBhZ3JlZSB0aGF0IHRoZXJlIHNob3VsZCBiZSB0ZXh0IGFib3V0IGV4aXN0 aW5nIGFzc3VtcHRpb25zL3VzYWdlcyAoUkZDIDUzNjggYW5kIDYwODApIG9mIENvbnRlbnQtSUQg YXMgYSBTSVAgaGVhZGVyIGZpZWxkLiBXZSdsbCBhZGQgdGV4dCBhYm91dCB0aGF0Lg0KDQpSZWdh cmRzLA0KDQpDaHJpc3Rlcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBB ZGFtIFJvYWNoIFttYWlsdG86YWRhbUBub3N0cnVtLmNvbV0gDQpTZW50OiAwNSBKdWx5IDIwMTcg MTc6MDYNClRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLXNpcGNv cmUtY29udGVudC1pZEBpZXRmLm9yZzsgSmVhbiBNYWhvbmV5IDxtYWhvbmV5QG5vc3RydW0uY29t Pjsgc2lwY29yZS1jaGFpcnNAaWV0Zi5vcmc7IG1haG9uZXlAbm9zdHJ1bS5jb207IHNpcGNvcmVA aWV0Zi5vcmcNClN1YmplY3Q6IEFkYW0gUm9hY2gncyBZZXMgb24gZHJhZnQtaWV0Zi1zaXBjb3Jl LWNvbnRlbnQtaWQtMDc6ICh3aXRoIENPTU1FTlQpDQoNCkFkYW0gUm9hY2ggaGFzIGVudGVyZWQg dGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLXNpcGNvcmUtY29u dGVudC1pZC0wNzogWWVzDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1Ympl Y3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQg aW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3Rv cnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9yZSBp bmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoN ClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUg Zm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt c2lwY29yZS1jb250ZW50LWlkLw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KSSdtIGEgbGl0dGxlIHN1cnByaXNlZCB0aGF0IHRoZSBkb2N1bWVudCBkaWRu J3QgZW5kIHVwIHdpdGggYW55IHRleHQgZGV0YWlsaW5nIHRoZSBoaXN0b3JpY2FsIGNvbnRleHQg Zm9yIGZvcm1hbGx5IGFkZGluZyB0aGlzIG1lY2hhbmlzbS4NCg0KSSB3b3VsZCBleHBlY3QgdG8g c2VlIHNvbWUgZGlzY3Vzc2lvbiBleHBsYWluaW5nIHRoYXQgdGhlIHVzZSBvZiBDb250ZW50LUlE IGFzIGEgU0lQIGhlYWRlciBmaWVsZCBoYXMgYmVlbiBpbmZlcnJlZCBhcyBhY2NlcHRhYmxlIGZv ciB5ZWFycywgYW5kIHRoYXQgc28gbWFueSBJRVRGIHBhcnRpY2lwYW50cyBoYWQgdGFrZW4gaXQg YXMgZ2l2ZW4gdGhhdCBDb250ZW50LUlEIHdhcyAqYWxyZWFkeSogYSByZWdpc3RlcmVkIFNJUCBo ZWFkZXIgZmllbGQgdGhhdCBpdCBhcHBlYXJzIGluIGV4YW1wbGVzIGluIChmb3IgZXhhbXBsZSkg UkZDcw0KNTM2OCBhbmQgNjA4MC4NCg0KV2hpbGUgSSB0aGluayB0aGUgZG9jdW1lbnQgd291bGQg c2VydmUgaXRzIGludGVuZGVkIHB1cnBvc2UgYXMtaXMsIEkgYmVsaWV2ZSB0aGF0IG1vcmUgZXhw bGFuYXRvcnkgdGV4dCBpbiB0aGUgSW50cm9kdWN0aW9uIHNlY3Rpb24gdG8gY2xhcmlmeSB0aGF0 IHRoaXMgaXMgYW4gYXR0ZW1wdCB0byBmb3JtYWxpemUgYWxyZWFkeS1hc3N1bWVkIChhbmQgbGlr ZWx5IGRlcGxveWVkKSBiZWhhdmlvciAtLSByYXRoZXIgdGhhbiBzaW1wbHkgY2FzdGluZyBpdCBh cyBhIG1pbm9yIG9wdGltaXphdGlvbiAtLSB3b3VsZCBnbyBhIGxvbmcgd2F5IHRvd2FyZHMgZGVh bGluZyB3aXRoIEVyaWMncyBjb25jZXJucy4NCg0KDQo= From nobody Wed Jul 5 11:53: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 05DC0131442; Wed, 5 Jul 2017 11:53: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, 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 4uB55fn8jiie; Wed, 5 Jul 2017 11:53:10 -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 48DF012EC21; Wed, 5 Jul 2017 11:53:09 -0700 (PDT) X-AuditID: c1b4fb3a-803ff70000001b2f-c0-595d3593c082 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 61.73.06959.3953D595; Wed, 5 Jul 2017 20:53:07 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0352.000; Wed, 5 Jul 2017 20:53:06 +0200 From: Christer Holmberg To: Eric Rescorla , The IESG CC: "draft-ietf-sipcore-content-id@ietf.org" , Jean Mahoney , "sipcore-chairs@ietf.org" , "mahoney@nostrum.com" , "sipcore@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and COMMENT) Thread-Index: AQHS9YeSl7jlBr6gNkqjMJoiy+ImKKJFklVA Date: Wed, 5 Jul 2017 18:53:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC50BB3@ESESSMB109.ericsson.se> References: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> In-Reply-To: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7ve5k09hIg/k71C1Of53BZLHi9Tl2 ixl/JjJbNHSuZLXo/byQ2eLrj01sDmweS5b8ZPKYtfMJi8fkx23MAcxRXDYpqTmZZalF+nYJ XBmbVh5hLNgmUzH51m3WBsYb0l2MnBwSAiYSR3a3M3YxcnEICRxhlGg/dokJwlnEKPH18jeg DAcHm4CFRPc/bZAGEQEriVe/r7GA1DALdDBJbH59gRUkISyQJnH63UUWiKJ0iZuH10HZRhJd VxcxgdgsAioSZ0+vYgOxeQV8JdZ3nwbrFQKy/0y7yQSyi1PAT6KnXQQkzCggJvH91BqwVmYB cYlbT+YzQRwtILFkz3lmCFtU4uXjf6wQtpLEotufwcYwC2hKrN+lD9GqKDGl+yE7xFZBiZMz n7BMYBSdhWTqLISOWUg6ZiHpWMDIsopRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMKoObvlt tYPx4HPHQ4wCHIxKPLys0rGRQqyJZcWVuYcYJTiYlUR4p+oBhXhTEiurUovy44tKc1KLDzFK c7AoifM67LsQISSQnliSmp2aWpBaBJNl4uCUamDsWBOycfOrBBd3e/OYOCGG1Q78lQvS49d+ OudmO2/BiXWPWi889Q0M7JeQKX1yP2vXgx+OB9bfclT2XPCvV++K4/mFoYs6jc95nXr4IzuP Ue33Rd/J9V9Zjl62ftflzpz89TX7RDuDU4J3Xh/d++7sZcb/UvWtpz8lGq8rPNk6MbI0n8f5 V3S8EktxRqKhFnNRcSIAzMQD7qYCAAA= Archived-At: Subject: Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and 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, 05 Jul 2017 18:53:12 -0000 SGkgRWtyLA0KDQpOb3RlIHRoYXQgdGhlIGRyYWZ0IGRvZXMgbm90IHVwZGF0ZSB0aGUgZXhpc3Rp bmcgbXVsdGlwYXJ0IHVzYWdlcyAoUkZDIDUzNjggYW5kIDY0NDIpLiBTbywgdGhlIGRyYWZ0IGRv ZXMgbm90IGNhdXNlIGFueSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzc3Vlcy4NCg0KKE5vdywg SUYgcGVvcGxlIHdhbnQgdG8gY2hhbmdlIGV4aXN0aW5nIG11bHRpcGFydCB1c2FnZXMsIEkgYWdy ZWUgdGhlcmUgbmVlZHMgdG8gYmUgYSBtZWNoYW5pc20gdG8gZW5zdXJlIHRoYXQgdGhlIGVuZHBv aW50cyB1bmRlcnN0YW5kIGl0LiBXZSBjYW4gYWRkIHNvbWUgdGV4dCBhYm91dCB0aGF0LiBJIHRo aW5rIHRoYXQgaXMgYWxzbyB3aGF0IFBhdWwgaW5kaWNhdGVkLikNCg0KVGhlIGRyYWZ0IGFsbG93 cyBhbnkgbmV3IHVzYWdlcyBub3QgaGF2aW5nIHRvIHVzZSBtdWx0aXBhcnQgKGlmIHRoZXJlIGlz IG9ubHkgb25lIGJvZHkgcGFydCksIGFuZCAoYXMgcG9pbnRlZCBvdXQgYnkgQWRhbSkgbWFrZXMg ZXhpc3RpbmcgdXNhZ2VzIChSRkMgNTM2OCBhbmQgNjA4MCkgb2YgQ29udGVudC1JRCBhcyBhIFNJ UCBoZWFkZXIgZmllbGQgc3RhbmRhcmRzIGNvbXBsaWFudC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEVyaWMgUmVzY29ybGEgW21h aWx0bzpla3JAcnRmbS5jb21dIA0KU2VudDogMDUgSnVseSAyMDE3IDE0OjEwDQpUbzogVGhlIElF U0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogZHJhZnQtaWV0Zi1zaXBjb3JlLWNvbnRlbnQtaWRAaWV0 Zi5vcmc7IEplYW4gTWFob25leSA8bWFob25leUBub3N0cnVtLmNvbT47IHNpcGNvcmUtY2hhaXJz QGlldGYub3JnOyBtYWhvbmV5QG5vc3RydW0uY29tOyBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0 OiBFcmljIFJlc2NvcmxhJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXNpcGNvcmUtY29udGVudC1p ZC0wNzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KRXJpYyBSZXNjb3JsYSBoYXMgZW50 ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtc2lwY29y ZS1jb250ZW50LWlkLTA3OiBEaXNjdXNzDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAg dGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMg aW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBp bnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpm b3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRp b25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25z LCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtc2lwY29yZS1jb250ZW50LWlkLw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRElTQ1VT UzoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhpcyBkb2N1bWVudCByZWFsbHkgbmVlZHMgc29tZSBkaXNj dXNzaW9uIG9mIHRoZSBpbnRlcm9wZXJhYmlsaXR5IGltcGxpY2F0aW9ucyBvZiB0aGlzIGNoYW5n ZS4gQXNzdW1pbmcgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgaXQgaXMgbm90IHBvc3NpYmxlIHRv IHVzZSB0aGlzIG1lY2hhbmlzbSB3aXRoIGFueSBleGlzdGluZyBjb250ZW50IHR5cGUsIGJlY2F1 c2UgcmVjZWl2aW5nIGltcGxlbWVudGF0aW9ucyB3aWxsIGV4cGVjdCB0byBzZWUgYSBtdWx0aXBh cnQgYW5kIHRodXMgcmVmdXNlIHRvIGFjY2VwdCB0aGUgbWVzc2FnZS4gSXMgdGhhdCBjb3JyZWN0 PyBJZiBzbywgaXQgc2VlbXMgbGlrZSBhIGxpbWl0YXRpb24gd2hpY2ggbmVlZHMgdG8gYmUgY2Fs bGVkIG91dCBleHBsaWNpdGx5DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KVGhpcyBkb2N1bWVudCBzZWVtcyByYXRoZXIgZ3JhdHVpdG91cyB0byBtZS4gSSBh Z3JlZSBpdCdzIHNvbWV3aGF0IG9mIGEgbWlzZmVhdHVyZSBub3QgdG8gYmUgYWJsZSB0byBoYXZl IENvbnRlbnQtSUQgaW4gdGhlIFNJUCBoZWFkZXJzLCBidXQgYXMgdGhlIGV4YW1wbGVzIGluIHRo aXMgZG9jdW1lbnQgbWFrZSBjbGVhciwgdGhlcmUncyBhIHN0cmFpZ2h0Zm9yd2FyZCB3b3JrYXJv dW5kLg0KSXQncyB1bmNsZWFyIHRvIG1lIHRoYXQgdGhlcmUgaXMgYWN0dWFsbHkgc3VmZmljaWVu dCBiZW5lZml0IHRvIHRoaXMgbWVjaGFuaXNtIHRvIHB1Ymxpc2hpbmcgYSBzdGFuZGFyZHMgdHJh Y2sgZG9jdW1lbnQgd2l0aCB0aGlzIGNoYW5nZS4NCg0KDQo= From nobody Wed Jul 5 12:14: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 CD5CD131DC4 for ; Wed, 5 Jul 2017 12:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] 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 jPq6iPf2tbW7 for ; Wed, 5 Jul 2017 12:14:43 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (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 A72391316AC for ; Wed, 5 Jul 2017 12:14:41 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id f194so15970555yba.3 for ; Wed, 05 Jul 2017 12:14:41 -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=/xDSpMWrY6Jh0PPuAQKXPWoQ4O9ZFHgzunXpHw66uAM=; b=fPGRR4w7K+lphbzA/7YfBu4LeyNtiW9AJOmq67yd1aAqMj0UGmXt4AbWaPihB6bQtd qQuywvIuIo2cUYSO5VWt02UEdsn9zvZfg2Hl5tX7x7rGp7b7mtmSxXp4oeWrferiprCg xjerdxeydd2XQfWS3Ww4sCkBYPYus8p2T6om1YxmmO3TnWCi+OZlsXKpQcKeyf/QddDs tQcki6692PfAGM8qVBzoEftIsKwa+xQGCYfTTbYc0GnpW3ht6RU+nJuwv3T5Y/ZRxwVD CLXSgo+0VhccYQgDOI9T2TV2N4YZkTy2d2xanqPbQgZ4ybtybto/3QOqslDQcNnYzllm 2BLw== 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=/xDSpMWrY6Jh0PPuAQKXPWoQ4O9ZFHgzunXpHw66uAM=; b=he+CmR5grz17a6n6fs0fKd3iRIJqymyFctp7VBwiYwqnF4eyg8hNeAcnUtrN+6pS9E zbgYqtI/o3vPRH3NuuRYY0ROB+ToWdo8f98GwvJLFXnBhwLZ/lqq5zEw7JJ96LsEpdqw KxFALOMRRu4x+RX/ApMoaWxehFXaWRpg4CwRDNekcsrK5e1K/emnfWTMSS6HXXhntLQU H2+m8ZxRKhgRTHYbuNj/+m6Acoqez+CODNP2tkMBgwrFGZtNkCYjiIeoTsgTCwa3WRo+ UT9GmJRiCvBaSw2xUambm8JhjGhjhx78h5wELifcghboB41Jj6YNwWjyBYXhHbEpmN8N 61XQ== X-Gm-Message-State: AKS2vOxLfEzflylV+8B0J1dnq+78o+KP9SCMPiUDXFD4aIQlgcfXS+7H x8KHZjUpvnkfq09/WhryO8DpV56r+SQL X-Received: by 10.37.118.210 with SMTP id r201mr37864636ybc.15.1499282080962; Wed, 05 Jul 2017 12:14:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Wed, 5 Jul 2017 12:14:00 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CC50BB3@ESESSMB109.ericsson.se> References: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CC50BB3@ESESSMB109.ericsson.se> From: Eric Rescorla Date: Wed, 5 Jul 2017 12:14:00 -0700 Message-ID: To: Christer Holmberg Cc: The IESG , "draft-ietf-sipcore-content-id@ietf.org" , "sipcore-chairs@ietf.org" , "mahoney@nostrum.com" , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="001a114bd4c8dac0dd055396cf9f" Archived-At: Subject: Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and 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, 05 Jul 2017 19:14:46 -0000 --001a114bd4c8dac0dd055396cf9f Content-Type: text/plain; charset="UTF-8" On Wed, Jul 5, 2017 at 11:53 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Ekr, > > Note that the draft does not update the existing multipart usages (RFC > 5368 and 6442). So, the draft does not cause any backward compatibility > issues. > I must have missed this. Can you point me to where I can find that? > > (Now, IF people want to change existing multipart usages, I agree there > needs to be a mechanism to ensure that the endpoints understand it. We can > add some text about that. I think that is also what Paul indicated.) > > The draft allows any new usages not having to use multipart (if there is > only one body part), and (as pointed out by Adam) makes existing usages > (RFC 5368 and 6080) of Content-ID Now I'm confused about the status of 5368.... -Ekr > as a SIP header field standards compliant. > > Regards, > > Christer > > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: 05 July 2017 14:10 > To: The IESG > Cc: draft-ietf-sipcore-content-id@ietf.org; Jean Mahoney < > mahoney@nostrum.com>; sipcore-chairs@ietf.org; mahoney@nostrum.com; > sipcore@ietf.org > Subject: Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: > (with DISCUSS and COMMENT) > > Eric Rescorla has entered the following ballot position for > draft-ietf-sipcore-content-id-07: Discuss > > 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-content-id/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This document really needs some discussion of the interoperability > implications of this change. Assuming I understand correctly, it is not > possible to use this mechanism with any existing content type, because > receiving implementations will expect to see a multipart and thus refuse to > accept the message. Is that correct? If so, it seems like a limitation > which needs to be called out explicitly > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This document seems rather gratuitous to me. I agree it's somewhat of a > misfeature not to be able to have Content-ID in the SIP headers, but as the > examples in this document make clear, there's a straightforward workaround. > It's unclear to me that there is actually sufficient benefit to this > mechanism to publishing a standards track document with this change. > > > --001a114bd4c8dac0dd055396cf9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 5, 2017 at 11:53 AM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:
Hi Ekr,

Note that the draft does not update the existing multipart usages (RFC 5368= and 6442). So, the draft does not cause any backward compatibility issues.=

I must have missed this. Can you point= me to where I can find that?

(Now, IF people want to change existing multipart usages, I agree there nee= ds to be a mechanism to ensure that the endpoints understand it. We can add= some text about that. I think that is also what Paul indicated.)

The draft allows any new usages not having to use multipart (if there is on= ly one body part), and (as pointed out by Adam) makes existing usages (RFC = 5368 and 6080) of Content-ID

Now I'm co= nfused about the status of 5368....

-Ekr
=C2=A0
as a SIP header field standard= s compliant.

Regards,

Christer

-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: 05 July 2017 14:10
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-si= pcore-content-id@ietf.org; Jean Mahoney <mahoney@nostrum.com>; sipcore-chairs@ietf.org; mahoney@nostrum.com; sipcore= @ietf.org
Subject: Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-= 07: (with DISCUSS and COMMENT)

Eric Rescorla has entered the following ballot position for
draft-ietf-sipcore-content-id-07: Discuss

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://www.ietf.org/iesg/<= wbr>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-content-id/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

This document really needs some discussion of the interoperability implicat= ions of this change. Assuming I understand correctly, it is not possible to= use this mechanism with any existing content type, because receiving imple= mentations will expect to see a multipart and thus refuse to accept the mes= sage. Is that correct? If so, it seems like a limitation which needs to be = called out explicitly


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

This document seems rather gratuitous to me. I agree it's somewhat of a= misfeature not to be able to have Content-ID in the SIP headers, but as th= e examples in this document make clear, there's a straightforward worka= round.
It's unclear to me that there is actually sufficient benefit to this me= chanism to publishing a standards track document with this change.



--001a114bd4c8dac0dd055396cf9f-- From nobody Wed Jul 5 12:25: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 2F8CE131957; Wed, 5 Jul 2017 12:25: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 w5SzNIBozXxb; Wed, 5 Jul 2017 12:25:08 -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 470DB1316AC; Wed, 5 Jul 2017 12:25:07 -0700 (PDT) X-AuditID: c1b4fb3a-81bff70000001b2f-d0-595d3d10c79c Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 84.F6.06959.01D3D595; Wed, 5 Jul 2017 21:25:05 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Wed, 5 Jul 2017 21:25:04 +0200 From: Christer Holmberg To: Eric Rescorla CC: The IESG , "draft-ietf-sipcore-content-id@ietf.org" , "sipcore-chairs@ietf.org" , "mahoney@nostrum.com" , "sipcore@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and COMMENT) Thread-Index: AQHS9YeSl7jlBr6gNkqjMJoiy+ImKKJFklVA///mywCAACOk4A== Date: Wed, 5 Jul 2017 19:25:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC516C7@ESESSMB109.ericsson.se> References: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CC50BB3@ESESSMB109.ericsson.se> In-Reply-To: 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2J7oK6gbWykwcMH3Banv85gsljx+hy7 xYw/E5ktGjpXslr0fl7IbPH1xyY2BzaPJUt+MnnM2vmExWPy4zbmAOYoLpuU1JzMstQifbsE rowD8ztZC67IV3Ruv8bawPhGrouRg0NCwETi/r36LkYuDiGBI4wSn9rvsncxcgI5ixgl/j32 B6lhE7CQ6P6nDRIWEVCQ+PXnBAtIPbPAP0aJu/P+soEkhAXSJE6/u8gCUZQucfPwOijbSeLu veNMIDaLgIrElq4tYPW8Ar4Styf0sEMsvsEoce3JMbAiToFAif4JzcwgNqOAmMT3U2vA4swC 4hK3nswHsyUEBCSW7DnPDGGLSrx8/I8VwlaSaFzyhBXkaGYBTYn1u/QhWhUlpnQ/ZIfYKyhx cuYTlgmMorOQTJ2F0DELSccsJB0LGFlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgRG1cEt v612MB587niIUYCDUYmHl80mNlKINbGsuDL3EKMEB7OSCO9UPaAQb0piZVVqUX58UWlOavEh RmkOFiVxXod9FyKEBNITS1KzU1MLUotgskwcnFINjHU+X5Ze2dDHUe4luuWr6LfkTHdld+6A Vnvl6bqc/WvvPS1ozrjF0jOb6+Y0rs3RiUIvTSqezSl1nmebe02PS+3srP+HmM9mrnUN8Hr8 ZIfug222cz/lBebtsuF88fB5n+Wz9NdX3jOmdrtVhB5wZXKUOWQQ1hr7ZvPGY4suCSkYVt3Q XXRvjRJLcUaioRZzUXEiAKaicW6mAgAA Archived-At: Subject: Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and 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, 05 Jul 2017 19:25:10 -0000 SGksDQoNCj4+Tm90ZSB0aGF0IHRoZSBkcmFmdCBkb2VzIG5vdCB1cGRhdGUgdGhlIGV4aXN0aW5n IG11bHRpcGFydCB1c2FnZXMgKFJGQyA1MzY4IGFuZCA2NDQyKS4gU28sIHRoZSBkcmFmdCBkb2Vz IG5vdCBjYXVzZSBhbnkgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpc3N1ZXMuDQo+DQo+SSBtdXN0 IGhhdmUgbWlzc2VkIHRoaXMuIENhbiB5b3UgcG9pbnQgbWUgdG8gd2hlcmUgSSBjYW4gZmluZCB0 aGF0Pw0KDQpUaGUgZHJhZnQgZG9lcyBOT1QgdXBkYXRlIHRob3NlIFJGQ3MsIHNvIHRoZXJlIGlz IG5vdGhpbmcgdG8gZmluZCA6KQ0KDQpUaGUgZHJhZnQgdXNlcyB0aG9zZSBSRkNzIHRvIHNob3cg aG93IHRoaW5ncyBoYXZlIHRvIGJlIGRvbmUgd2l0aG91dCB0aGUgZHJhZnQuDQoNCj4+KE5vdywg SUYgcGVvcGxlIHdhbnQgdG8gY2hhbmdlIGV4aXN0aW5nIG11bHRpcGFydCB1c2FnZXMsIEkgYWdy ZWUgdGhlcmUgbmVlZHMgdG8gYmUgYSBtZWNoYW5pc20gdG8gZW5zdXJlIHRoYXQgdGhlIGVuZHBv aW50cyB1bmRlcnN0YW5kIGl0LiBXZSBjYW4gYWRkIHNvbWUgdGV4dCBhYm91dCA+PnRoYXQuIEkg dGhpbmsgdGhhdCBpcyBhbHNvIHdoYXQgUGF1bCBpbmRpY2F0ZWQuKQ0KPj4NCj4+VGhlIGRyYWZ0 IGFsbG93cyBhbnkgbmV3IHVzYWdlcyBub3QgaGF2aW5nIHRvIHVzZSBtdWx0aXBhcnQgKGlmIHRo ZXJlIGlzIG9ubHkgb25lIGJvZHkgcGFydCksIGFuZCAoYXMgcG9pbnRlZCBvdXQgYnkgQWRhbSkg bWFrZXMgZXhpc3RpbmcgdXNhZ2VzIChSRkMgNTM2OCBhbmQgNjA4MCkgb2YgPj5Db250ZW50LUlE DQo+DQo+IE5vdyBJJ20gY29uZnVzZWQgYWJvdXQgdGhlIHN0YXR1cyBvZiA1MzY4Li4uLg0KDQpJ biBSRkMgNTM2OCBDb250ZW50LUlEIGlzIHVzZWQgYXMgYSBTSVAgaGVhZGVyIGZpZWxkLg0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0KU2VudDogMDUgSnVseSAyMDE3 IDE0OjEwDQpUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogZHJhZnQtaWV0Zi1zaXBj b3JlLWNvbnRlbnQtaWRAaWV0Zi5vcmc7IEplYW4gTWFob25leSA8bWFob25leUBub3N0cnVtLmNv bT47IHNpcGNvcmUtY2hhaXJzQGlldGYub3JnOyBtYWhvbmV5QG5vc3RydW0uY29tOyBzaXBjb3Jl QGlldGYub3JnDQpTdWJqZWN0OiBFcmljIFJlc2NvcmxhJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRm LXNpcGNvcmUtY29udGVudC1pZC0wNzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KRXJp YyBSZXNjb3JsYSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3IN CmRyYWZ0LWlldGYtc2lwY29yZS1jb250ZW50LWlkLTA3OiBEaXNjdXNzDQoNCldoZW4gcmVzcG9u ZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFs bCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwg ZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQ bGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vz cy1jcml0ZXJpYS5odG1sDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1Mg YW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhl ciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2lwY29yZS1jb250ZW50LWlkLw0KDQoNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KRElTQ1VTUzoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhpcyBkb2N1bWVudCByZWFs bHkgbmVlZHMgc29tZSBkaXNjdXNzaW9uIG9mIHRoZSBpbnRlcm9wZXJhYmlsaXR5IGltcGxpY2F0 aW9ucyBvZiB0aGlzIGNoYW5nZS4gQXNzdW1pbmcgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgaXQg aXMgbm90IHBvc3NpYmxlIHRvIHVzZSB0aGlzIG1lY2hhbmlzbSB3aXRoIGFueSBleGlzdGluZyBj b250ZW50IHR5cGUsIGJlY2F1c2UgcmVjZWl2aW5nIGltcGxlbWVudGF0aW9ucyB3aWxsIGV4cGVj dCB0byBzZWUgYSBtdWx0aXBhcnQgYW5kIHRodXMgcmVmdXNlIHRvIGFjY2VwdCB0aGUgbWVzc2Fn ZS4gSXMgdGhhdCBjb3JyZWN0PyBJZiBzbywgaXQgc2VlbXMgbGlrZSBhIGxpbWl0YXRpb24gd2hp Y2ggbmVlZHMgdG8gYmUgY2FsbGVkIG91dCBleHBsaWNpdGx5DQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Q09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhpcyBkb2N1bWVudCBzZWVtcyByYXRoZXIgZ3Jh dHVpdG91cyB0byBtZS4gSSBhZ3JlZSBpdCdzIHNvbWV3aGF0IG9mIGEgbWlzZmVhdHVyZSBub3Qg dG8gYmUgYWJsZSB0byBoYXZlIENvbnRlbnQtSUQgaW4gdGhlIFNJUCBoZWFkZXJzLCBidXQgYXMg dGhlIGV4YW1wbGVzIGluIHRoaXMgZG9jdW1lbnQgbWFrZSBjbGVhciwgdGhlcmUncyBhIHN0cmFp Z2h0Zm9yd2FyZCB3b3JrYXJvdW5kLg0KSXQncyB1bmNsZWFyIHRvIG1lIHRoYXQgdGhlcmUgaXMg YWN0dWFsbHkgc3VmZmljaWVudCBiZW5lZml0IHRvIHRoaXMgbWVjaGFuaXNtIHRvIHB1Ymxpc2hp bmcgYSBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQgd2l0aCB0aGlzIGNoYW5nZS4NCg0KDQo= From nobody Wed Jul 5 12:29: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 4905A131701 for ; Wed, 5 Jul 2017 12:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] 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 xvL1kQSJQ4kG for ; Wed, 5 Jul 2017 12:29:25 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0890712EC55 for ; Wed, 5 Jul 2017 12:29:25 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id l21so88220410ywb.1 for ; Wed, 05 Jul 2017 12:29:25 -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=0bTFImMl4QhuNVF/Ca70oLD3TkrIlOSk82TygH4EGIE=; b=VmF7Lsg4Yey6/uZtM6uzD+jBbEi+al8Ilvv72JYfX0rjzyNM/i66KdOzAgx+kREHaw AYjbWDfKCqO+mO7zy9VgpXwz1nqkklbeoOnvn5stuFFMmoFYKbcBHiY2PrWYKeMPLuAU ja/VZgnuOk5aDyb7DbHZ0oz2NieS/40v3RWMGPMY2qwakgYWFnX8hRYAZdK6o5ffdZJM UdBtyuo+fGk79a7VrF0DIxOnEJxhN7BEtvac3UNqP7VkQGz2ChgTiggdumi3jRWH5HTs 8ZQpRURfusoQ6kXXPWkggxVYHL4bxJFk9wiMPd0xH6bCx2mQHVSBgUKBd5KdtoUViiXF rStQ== 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=0bTFImMl4QhuNVF/Ca70oLD3TkrIlOSk82TygH4EGIE=; b=ZdtC1vFJYwKTu5tTLM/lTNhyLgAWCytcCQhfEggKofm0v/+QdgiBmi1vq+sTVdvGv3 2nArDfgwnPEQFkLbfzRGOY3hjWCSrQu2Rdu++XPmhLNYa0pYhiLdBcF7ZNjznUk5l/vx A9GC2eSO6LnQFV/psiHIYpDX7az8kzuBIrwtWc3kWfs2fWRtaAyRcHbIr9Zl1BJU3lMS E/pXXKUhuRpJyFB4X6Me6XScVm6zG7kuPnj2OC2VaOuhS0D1R/HM4R4HaL41yIcjIoGI CcaMcDyyz7Uo1ll01Tl4vi159j6ymBAff6YlpReHlYCVpC6WiaUH/bFKfiFrVWuRes5b xTMg== X-Gm-Message-State: AKS2vOwZTg0RPtilgcJiKxM4OBY24jKz+5Cy3ifQUEewmmEmnmaM4FPi y3+B+xF8MmiGVIpFEnugtonc43fGauHx X-Received: by 10.129.202.71 with SMTP id y7mr33705242ywk.74.1499282964273; Wed, 05 Jul 2017 12:29:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Wed, 5 Jul 2017 12:28:43 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CC516C7@ESESSMB109.ericsson.se> References: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CC50BB3@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CC516C7@ESESSMB109.ericsson.se> From: Eric Rescorla Date: Wed, 5 Jul 2017 12:28:43 -0700 Message-ID: To: Christer Holmberg Cc: The IESG , "draft-ietf-sipcore-content-id@ietf.org" , "sipcore-chairs@ietf.org" , "mahoney@nostrum.com" , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="089e0825978080ef500553970415" Archived-At: Subject: Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and 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, 05 Jul 2017 19:29:28 -0000 --089e0825978080ef500553970415 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 5, 2017 at 12:25 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>Note that the draft does not update the existing multipart usages (RFC > 5368 and 6442). So, the draft does not cause any backward compatibility > issues. > > > >I must have missed this. Can you point me to where I can find that? > > The draft does NOT update those RFCs, so there is nothing to find :) > > The draft uses those RFCs to show how things have to be done without the > draft. Yeah, I think given these examples, one might naturally infer that the rule was being relaxed for them. The draft needs to be clear about its scope, and not just rely on people looking at "Updates:" >>(Now, IF people want to change existing multipart usages, I agree there > needs to be a mechanism to ensure that the endpoints understand it. We can > add some text about >>that. I think that is also what Paul indicated.) > >> > >>The draft allows any new usages not having to use multipart (if there is > only one body part), and (as pointed out by Adam) makes existing usages > (RFC 5368 and 6080) of >>Content-ID > > > > Now I'm confused about the status of 5368.... > > In RFC 5368 Content-ID is used as a SIP header field. > So then this is retrospectively changing the status of this. -Ekr > > Regards, > > Christer > > > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: 05 July 2017 14:10 > To: The IESG > Cc: draft-ietf-sipcore-content-id@ietf.org; Jean Mahoney < > mahoney@nostrum.com>; sipcore-chairs@ietf.org; mahoney@nostrum.com; > sipcore@ietf.org > Subject: Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: > (with DISCUSS and COMMENT) > > Eric Rescorla has entered the following ballot position for > draft-ietf-sipcore-content-id-07: Discuss > > 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-content-id/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This document really needs some discussion of the interoperability > implications of this change. Assuming I understand correctly, it is not > possible to use this mechanism with any existing content type, because > receiving implementations will expect to see a multipart and thus refuse to > accept the message. Is that correct? If so, it seems like a limitation > which needs to be called out explicitly > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This document seems rather gratuitous to me. I agree it's somewhat of a > misfeature not to be able to have Content-ID in the SIP headers, but as the > examples in this document make clear, there's a straightforward workaround. > It's unclear to me that there is actually sufficient benefit to this > mechanism to publishing a standards track document with this change. > > > --089e0825978080ef500553970415 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 5, 2017 at 12:25 PM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:
Hi,

>>Note that the draft does not update the existing multipart usages (= RFC 5368 and 6442). So, the draft does not cause any backward compatibility= issues.
>
>I must have missed this. Can you point me to where I can find that?

The draft does NOT update those RFCs, so there is nothing to find :)=

The draft uses those RFCs to show how things have to be done without the dr= aft.

Yeah, I think given these examples, on= e might naturally infer that the rule was being
relaxed for them.= The draft needs to be clear about its scope, and not just rely on
people looking at "Updates:"


>>(Now, IF people want to change existing multipart usages, I agree t= here needs to be a mechanism to ensure that the endpoints understand it. We= can add some text about >>that. I think that is also what Paul indic= ated.)
>>
>>The draft allows any new usages not having to use multipart (if the= re is only one body part), and (as pointed out by Adam) makes existing usag= es (RFC 5368 and 6080) of >>Content-ID
>
> Now I'm confused about the status of 5368....

In RFC 5368 Content-ID is used as a SIP header field.

So then this is retrospectively changing the status o= f this.

-Ekr
=C2=A0

Regards,

Christer


-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: 05 July 2017 14:10
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-si= pcore-content-id@ietf.org; Jean Mahoney <mahoney@nostrum.com>; sipcore-chairs@ietf.org; mahoney@nostrum.com; sipcore= @ietf.org
Subject: Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-= 07: (with DISCUSS and COMMENT)

Eric Rescorla has entered the following ballot position for
draft-ietf-sipcore-content-id-07: Discuss

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://www.ietf.org/iesg/<= wbr>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-content-id/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

This document really needs some discussion of the interoperability implicat= ions of this change. Assuming I understand correctly, it is not possible to= use this mechanism with any existing content type, because receiving imple= mentations will expect to see a multipart and thus refuse to accept the mes= sage. Is that correct? If so, it seems like a limitation which needs to be = called out explicitly


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

This document seems rather gratuitous to me. I agree it's somewhat of a= misfeature not to be able to have Content-ID in the SIP headers, but as th= e examples in this document make clear, there's a straightforward worka= round.
It's unclear to me that there is actually sufficient benefit to this me= chanism to publishing a standards track document with this change.



--089e0825978080ef500553970415-- From nobody Wed Jul 5 12:35: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 3FF5E13154F; Wed, 5 Jul 2017 12:35:01 -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 M_SY3-JL67o5; Wed, 5 Jul 2017 12:34:58 -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 1A6FB12EC55; Wed, 5 Jul 2017 12:34:57 -0700 (PDT) X-AuditID: c1b4fb2d-7ebff70000005faa-a3-595d3f603395 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 37.F9.24490.06F3D595; Wed, 5 Jul 2017 21:34:56 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Wed, 5 Jul 2017 21:34:55 +0200 From: Christer Holmberg To: Eric Rescorla CC: The IESG , "draft-ietf-sipcore-content-id@ietf.org" , "sipcore-chairs@ietf.org" , "mahoney@nostrum.com" , "sipcore@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and COMMENT) Thread-Index: AQHS9YeSl7jlBr6gNkqjMJoiy+ImKKJFklVA///mywCAACOk4P//4HmAgAAiMaA= Date: Wed, 5 Jul 2017 19:34:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC51750@ESESSMB109.ericsson.se> References: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CC50BB3@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CC516C7@ESESSMB109.ericsson.se> In-Reply-To: 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7jW6CfWykQdsLKYvTX2cwWax4fY7d YsaficwWDZ0rWS16Py9ktvj6YxObA5vHkiU/mTxm7XzC4jH5cRtzAHMUl01Kak5mWWqRvl0C V8bk/n8sBdPUKjru9TM3MM5Q7WLk5JAQMJGYeWEzUxcjF4eQwBFGiZ/7ljFCOIsYJQ6cmMDW xcjBwSZgIdH9TxukQURAQeLXnxMsIDXMAv8YJe7O+8sGkhAWSJM4/e4iC0RRusTNw+ugbD+J 6e/XgNWwCKhIXN/wlR3E5hXwlXiy8wHU5sdMErfuvwEr4hQIlFjy+zJYEaOAmMT3U2uYQGxm AXGJW0/mM0GcLSCxZM95ZghbVOLl43+sELaSROOSJ6wgRzMLaEqs36UP0aooMaX7IdReQYmT M5+wTGAUnYVk6iyEjllIOmYh6VjAyLKKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzCyDm75 rbuDcfVrx0OMAhyMSjy85yxiI4VYE8uKK3MPMUpwMCuJ8E7VAwrxpiRWVqUW5ccXleakFh9i lOZgURLnddh3IUJIID2xJDU7NbUgtQgmy8TBKdXAyGziKTrjadaypnWxHoY/wl9k3gpd5rZH 9NyvbmEL18mCuUaPLWLl3++YGq+S2XFjV3mjaZrK0tve7VVLFxi8ecWU5VG4p6elL+zAFdMs LTnD7Spmi9wjHp/xlPpsNvfydHmxiItMWldmSNyqXzJ/u7jCTKmON3sa++/rzD2i+edrw9b6 jjxOJZbijERDLeai4kQAPqkKf6gCAAA= Archived-At: Subject: Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and 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, 05 Jul 2017 19:35:01 -0000 SGksDQoNCj4+Pk5vdGUgdGhhdCB0aGUgZHJhZnQgZG9lcyBub3QgdXBkYXRlIHRoZSBleGlzdGlu ZyBtdWx0aXBhcnQgdXNhZ2VzIChSRkMgNTM2OCBhbmQgNjQ0MikuIFNvLCB0aGUgZHJhZnQgZG9l cyBub3QgY2F1c2UgYW55IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWVzLg0KPj4NCj4+SSBt dXN0IGhhdmUgbWlzc2VkIHRoaXMuIENhbiB5b3UgcG9pbnQgbWUgdG8gd2hlcmUgSSBjYW4gZmlu ZCB0aGF0Pw0KPj4NCj4+VGhlIGRyYWZ0IGRvZXMgTk9UIHVwZGF0ZSB0aG9zZSBSRkNzLCBzbyB0 aGVyZSBpcyBub3RoaW5nIHRvIGZpbmQgOikNCj4+DQo+PlRoZSBkcmFmdCB1c2VzIHRob3NlIFJG Q3MgdG8gc2hvdyBob3cgdGhpbmdzIGhhdmUgdG8gYmUgZG9uZSB3aXRob3V0IHRoZSBkcmFmdC4N Cj4NCj5ZZWFoLCBJIHRoaW5rIGdpdmVuIHRoZXNlIGV4YW1wbGVzLCBvbmUgbWlnaHQgbmF0dXJh bGx5IGluZmVyIHRoYXQgdGhlIHJ1bGUgd2FzIGJlaW5nDQo+cmVsYXhlZCBmb3IgdGhlbS4gVGhl IGRyYWZ0IG5lZWRzIHRvIGJlIGNsZWFyIGFib3V0IGl0cyBzY29wZSwgYW5kIG5vdCBqdXN0IHJl bHkgb24NCj5wZW9wbGUgbG9va2luZyBhdCAiVXBkYXRlczoiDQoNCldlIHdpbGwgYWRkIHNvbWUg dGV4dCwgc2F5aW5nIHRoYXQgdGhlIGRyYWZ0IGRvZXMgbm90IGNoYW5nZSB0aGUgZXhpc3Rpbmcg dXNhZ2VzLg0KDQoNCj4+Pj4oTm93LCBJRiBwZW9wbGUgd2FudCB0byBjaGFuZ2UgZXhpc3Rpbmcg bXVsdGlwYXJ0IHVzYWdlcywgSSBhZ3JlZSB0aGVyZSBuZWVkcyB0byBiZSBhIG1lY2hhbmlzbSB0 byANCj4+Pj5lbnN1cmUgdGhhdCB0aGUgZW5kcG9pbnRzIHVuZGVyc3RhbmQgaXQuIFdlIGNhbiBh ZGQgc29tZSB0ZXh0IGFib3V0ID4+dGhhdC4gSSB0aGluayB0aGF0IGlzIGFsc28gd2hhdCBQYXVs IGluZGljYXRlZC4pDQo+Pj4+DQo+Pj4+VGhlIGRyYWZ0IGFsbG93cyBhbnkgbmV3IHVzYWdlcyBu b3QgaGF2aW5nIHRvIHVzZSBtdWx0aXBhcnQgKGlmIHRoZXJlIGlzIG9ubHkgb25lIGJvZHkgcGFy dCksIGFuZCAoYXMgcG9pbnRlZCANCj4+Pj5vdXQgYnkgQWRhbSkgbWFrZXMgZXhpc3RpbmcgdXNh Z2VzIChSRkMgNTM2OCBhbmQgNjA4MCkgb2YgPj5Db250ZW50LUlEDQo+Pj4NCj4+PiBOb3cgSSdt IGNvbmZ1c2VkIGFib3V0IHRoZSBzdGF0dXMgb2YgNTM2OC4uLi4NCj4+DQo+PkluIFJGQyA1MzY4 IENvbnRlbnQtSUQgaXMgdXNlZCBhcyBhIFNJUCBoZWFkZXIgZmllbGQuDQo+DQo+IFNvIHRoZW4g dGhpcyBpcyByZXRyb3NwZWN0aXZlbHkgY2hhbmdpbmcgdGhlIHN0YXR1cyBvZiB0aGlzLg0KDQpU aGUgZHJhZnQgZGVmaW5lcyBDb250ZW50LUlEIGFzIGEgU0lQIGhlYWRlciBmaWVsZCwgd2hpY2gg aXQgd2Fzbid0IHdoZW4gUkZDIDUzNjggd2FzIHB1Ymxpc2hlZCAtIGFsdGhvdWdoIHBlb3BsZSBz ZWVtZWQgdG8gaGF2ZSBhc3N1bWVkIGl0IHdhcywgYXMgaXQgaXMgdXNlZCBhcyBhIFNJUCBoZWFk ZXIgZmllbGQgYm90aCBpbiA1MzY4IGFuZCA2MDgwLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEVyaWMgUmVzY29ybGEgW21h aWx0bzpla3JAcnRmbS5jb21dDQpTZW50OiAwNSBKdWx5IDIwMTcgMTQ6MTANClRvOiBUaGUgSUVT RyA8aWVzZ0BpZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLXNpcGNvcmUtY29udGVudC1pZEBpZXRm Lm9yZzsgSmVhbiBNYWhvbmV5IDxtYWhvbmV5QG5vc3RydW0uY29tPjsgc2lwY29yZS1jaGFpcnNA aWV0Zi5vcmc7IG1haG9uZXlAbm9zdHJ1bS5jb207IHNpcGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6 IEVyaWMgUmVzY29ybGEncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1jb250ZW50LWlk LTA3OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpFcmljIFJlc2NvcmxhIGhhcyBlbnRl cmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1zaXBjb3Jl LWNvbnRlbnQtaWQtMDc6IERpc2N1c3MNCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0 aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBp bmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGlu dHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRw czovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZv ciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlv bnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMs IGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1zaXBjb3JlLWNvbnRlbnQtaWQvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpESVNDVVNT Og0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGlzIGRvY3VtZW50IHJlYWxseSBuZWVkcyBzb21lIGRpc2N1 c3Npb24gb2YgdGhlIGludGVyb3BlcmFiaWxpdHkgaW1wbGljYXRpb25zIG9mIHRoaXMgY2hhbmdl LiBBc3N1bWluZyBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCBpdCBpcyBub3QgcG9zc2libGUgdG8g dXNlIHRoaXMgbWVjaGFuaXNtIHdpdGggYW55IGV4aXN0aW5nIGNvbnRlbnQgdHlwZSwgYmVjYXVz ZSByZWNlaXZpbmcgaW1wbGVtZW50YXRpb25zIHdpbGwgZXhwZWN0IHRvIHNlZSBhIG11bHRpcGFy dCBhbmQgdGh1cyByZWZ1c2UgdG8gYWNjZXB0IHRoZSBtZXNzYWdlLiBJcyB0aGF0IGNvcnJlY3Q/ IElmIHNvLCBpdCBzZWVtcyBsaWtlIGEgbGltaXRhdGlvbiB3aGljaCBuZWVkcyB0byBiZSBjYWxs ZWQgb3V0IGV4cGxpY2l0bHkNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5UOg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQpUaGlzIGRvY3VtZW50IHNlZW1zIHJhdGhlciBncmF0dWl0b3VzIHRvIG1lLiBJIGFn cmVlIGl0J3Mgc29tZXdoYXQgb2YgYSBtaXNmZWF0dXJlIG5vdCB0byBiZSBhYmxlIHRvIGhhdmUg Q29udGVudC1JRCBpbiB0aGUgU0lQIGhlYWRlcnMsIGJ1dCBhcyB0aGUgZXhhbXBsZXMgaW4gdGhp cyBkb2N1bWVudCBtYWtlIGNsZWFyLCB0aGVyZSdzIGEgc3RyYWlnaHRmb3J3YXJkIHdvcmthcm91 bmQuDQpJdCdzIHVuY2xlYXIgdG8gbWUgdGhhdCB0aGVyZSBpcyBhY3R1YWxseSBzdWZmaWNpZW50 IGJlbmVmaXQgdG8gdGhpcyBtZWNoYW5pc20gdG8gcHVibGlzaGluZyBhIHN0YW5kYXJkcyB0cmFj ayBkb2N1bWVudCB3aXRoIHRoaXMgY2hhbmdlLg0KDQoNCg== From nobody Wed Jul 5 23:25: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 50D58127419; Wed, 5 Jul 2017 23:25:15 -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 v4afxM_IO5Yf; Wed, 5 Jul 2017 23:25:13 -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 C3A4F127076; Wed, 5 Jul 2017 23:25:12 -0700 (PDT) X-AuditID: c1b4fb3a-bea2a9c000001b2f-8b-595dd7c63330 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EC.76.06959.6C7DD595; Thu, 6 Jul 2017 08:25:11 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Thu, 6 Jul 2017 08:25:10 +0200 From: Christer Holmberg To: Elwyn Davies , "gen-art@ietf.org" CC: "draft-ietf-sipcore-content-id.all@ietf.org" , "sipcore@ietf.org" , "ietf@ietf.org" Thread-Topic: Genart telechat review of draft-ietf-sipcore-content-id-07 Thread-Index: AQHS9Kv2eEN+imnuHUCXFFEalQVB+aJGV7yQ Date: Thu, 6 Jul 2017 06:25:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC5278F@ESESSMB109.ericsson.se> References: <149916225425.16088.10318703158229973440@ietfa.amsl.com> In-Reply-To: <149916225425.16088.10318703158229973440@ietfa.amsl.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbFdWvf49dhIg8cvOS1mnt3FYrHtuKDF 1VefWSyebZzPYvH1xyY2B1aP4yt2snssWfKTKYApissmJTUnsyy1SN8ugSvj4LNW1oIlvBW7 GnaxNjD+4Oli5OSQEDCROLjvOHsXIxeHkMARRol1b39BOYsYJX6dW8HaxcjBwSZgIdH9Txuk QUQgUGLm6gmsIDXMAisZJa5MaWEBSQgLuEt8urSIEaLIQ+LRpt9MELaRxLbuVewgc1gEVCRa T5WBhHkFfCXWL3vHBmILCbhINO2ewAxicwq4Srz8OpsdxGYUEJP4fmoN2BhmAXGJW0/mM0Ec LSCxZM95ZghbVOLl43+sELaSROOSJ2AnMwtoSqzfpQ/RqigxpfshO8RaQYmTM5+wTGAUnYVk 6iyEjllIOmYh6VjAyLKKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzB+Dm75bbWD8eBzx0OM AhyMSjy8xcdiI4VYE8uKK3MPMUpwMCuJ8B46CRTiTUmsrEotyo8vKs1JLT7EKM3BoiTO67Dv QoSQQHpiSWp2ampBahFMlomDU6qBseZG8ZvPKzRkLj1bxuIU+PfgjcnWbusrls9dWt6efffb C+sVBz5on2Rete6qC4tFYk+z1XpWTuEr+xTblrQf5wi0TI665a/1VjIwcaq0wueIyPKTaRoM FkXnfE87Z/6wkz+VtfaLye3oN7MuPGFPFl8cyLZZPU+AT75BP+nYql0RF/lLvO96K7EUZyQa ajEXFScCAL3I4vibAgAA Archived-At: Subject: Re: [sipcore] Genart telechat review of draft-ietf-sipcore-content-id-07 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 Jul 2017 06:25:15 -0000 SGkgRWx3eW4sDQoNCldlIHdpbGwgbWFrZSB0aGUgcmVmZXJlbmNlcyBiZWxvdyBpbmZvcm1hdGl2 ZSBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRWx3eW4gRGF2aWVzIFttYWlsdG86ZWx3eW5kQGRp YWwucGlwZXguY29tXSANClNlbnQ6IDA0IEp1bHkgMjAxNyAxMTo1OA0KVG86IGdlbi1hcnRAaWV0 Zi5vcmcNCkNjOiBkcmFmdC1pZXRmLXNpcGNvcmUtY29udGVudC1pZC5hbGxAaWV0Zi5vcmc7IHNp cGNvcmVAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmcNClN1YmplY3Q6IEdlbmFydCB0ZWxlY2hhdCBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1zaXBjb3JlLWNvbnRlbnQtaWQtMDcNCg0KUmV2aWV3ZXI6IEVs d3luIERhdmllcw0KUmV2aWV3IHJlc3VsdDogUmVhZHkNCg0KSSBhbSB0aGUgYXNzaWduZWQgR2Vu LUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdlbmVyYWwgQXJlYSBSZXZpZXcgVGVh bSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5 IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4gUGxlYXNlIHdhaXQgZm9yIGRpcmVjdGlvbiBm cm9tIHlvdXIgZG9jdW1lbnQgc2hlcGhlcmQgb3IgQUQgYmVmb3JlIHBvc3RpbmcgYSBuZXcgdmVy c2lvbiBvZiB0aGUgZHJhZnQuDQoNCkZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRo ZSBGQVEgYXQNCg0KPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFydGZh cT4uDQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLXNpcGNvcmUtY29udGVudC1pZC0wNw0KUmV2aWV3 ZXI6IEVsd3luIERhdmllcw0KUmV2aWV3IERhdGU6IDIwMTctMDctMDQNCklFVEYgTEMgRW5kIERh dGU6IDIwMTctMDYtMjcNCklFU0cgVGVsZWNoYXQgZGF0ZTogMjAxNy0wNy0wNg0KDQpTdW1tYXJ5 Og0KUmVhZHkuICBUaGFuayB5b3UgZm9yIGFkZHJlc3NpbmcgdGhlIGNvbW1lbnRzIGluIG15IGxh c3QgY2FsbCByZXZpZXcuDQoNCk1ham9yIGlzc3VlczoNCg0KTWlub3IgaXNzdWVzOg0KDQpOaXRz L2VkaXRvcmlhbCBjb21tZW50czoNClRoZSByZWZlcmVuY2VzIHRvIFJGQyA1MzY4IGFuZCBSRkMg NjQ0MiBhcmUgaW5mb3JtYXRpdmUgcmF0aGVyIHRoYW4gbm9ybWF0aXZlIC0geW91IGRvbid0IG5l ZWQgdGhlIGRldGFpbHMgdG8gaW1wbGVtZW50IHRoaXMgdXBkYXRlLg0KDQo= From nobody Thu Jul 6 02:47:15 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 11EF6120721; Thu, 6 Jul 2017 02:47:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-sipcore-content-id@ietf.org, Jean Mahoney , sipcore-chairs@ietf.org, mahoney@nostrum.com, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149933443406.22725.16034978116082240716.idtracker@ietfa.amsl.com> Date: Thu, 06 Jul 2017 02:47:14 -0700 Archived-At: Subject: [sipcore] Alexey Melnikov's No Objection on draft-ietf-sipcore-content-id-07: (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: Thu, 06 Jul 2017 09:47:14 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-sipcore-content-id-07: 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-content-id/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I've checked whether this is consistent with email use and it seems to be. Note that RFC 2392 says: The Content-ID of a MIME body part is required to be globally unique. and this document only requires it to be unique within a message. I don't think the difference in restrictions makes any real world difference, because I don't think applications enforce uniqueness of Content-IDs between different messages. From nobody Thu Jul 6 03:17: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 89F60129A9C; Thu, 6 Jul 2017 03:16:59 -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 QlnKZfjBxToF; Thu, 6 Jul 2017 03:16:57 -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 E7A2812702E; Thu, 6 Jul 2017 03:16:56 -0700 (PDT) X-AuditID: c1b4fb2d-bcf0a9c000005faa-3a-595e0e16213f Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 36.72.24490.61E0E595; Thu, 6 Jul 2017 12:16:55 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Thu, 6 Jul 2017 12:16:54 +0200 From: Christer Holmberg To: Alexey Melnikov CC: The IESG , "draft-ietf-sipcore-content-id@ietf.org" , Jean Mahoney , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" Thread-Topic: Alexey Melnikov's No Objection on draft-ietf-sipcore-content-id-07: (with COMMENT) Thread-Index: AQHS9jzaKz9WszBBaE2Upg38v2jG8KJGc/gA Date: Thu, 6 Jul 2017 10:16:54 +0000 Message-ID: References: <149933443406.22725.16034978116082240716.idtracker@ietfa.amsl.com> In-Reply-To: <149933443406.22725.16034978116082240716.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-60DC34EA-A18B-4DE4-8AF9-2CA11F2AFE85"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUyM2K7pa44X1ykwfkvnBb73x9isjj9dQaT xYw/E5ktGjpXslr0fl7IbPH1xyY2BzaPnacOsHksWfKTyWPWzicsAcxRXDYpqTmZZalF+nYJ XBlHl55gKvjsUbFz/l/2Bsa3Ll2MnBwSAiYSZ/91MnUxcnEICRxhlFjz8TYbhLOIUWJt12vG LkYODjYBC4nuf9ogDSICOhLHDr8Ea2AW+Moosb99BQtIQlggUeLpyxuMEEVJEts/rGGFsI0k Zpz+ygxiswioSFz/ex8szitgL/F7aRMTiC0k4Cfx7tUEsBpOAX+JTfdPgM1kFBCT+H5qDVgN s4C4xK0n85kgrhaReHjxNBuELSrx8vE/VoiDJjNKrLrRwAixQFDi5MwnLBMYhWch6Z+FrG4W krpZQI8yA303eSEjRL22xLKFr5khbGuJGb8OskHYphKvj36EqlGUmNL9kH0BI8cqRtHi1OLi 3HQjY73Uoszk4uL8PL281JJNjMBoPLjlt+4OxtWvHQ8xCnAwKvHwfmSJixRiTSwrrsw9xKgC NOfRhtUXGKVY8vLzUpVEeE/9iI0U4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuuw70KEkEB6Yklq dmpqQWoRTJaJg1OqgVHj0JL/l5rbG58b8VuLpC2Z99ON7eqhAKtHix7LBmh3bBOsj5F6w/WT W1vUf0dXu/j8yl08B9r5NHT6jF7euyDx77j/n8gX7YZWQR+M7/MWmm6fJvqNsyxlKqOv1M4r Fs1bVn3PNln73Heh5NePeee0MudPfZCqo7/rzGPZB95/V3Tce8AR3qrEUpyRaKjFXFScCAAU pVIpzgIAAA== Archived-At: Subject: Re: [sipcore] Alexey Melnikov's No Objection on draft-ietf-sipcore-content-id-07: (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, 06 Jul 2017 10:17:00 -0000 --Apple-Mail-60DC34EA-A18B-4DE4-8AF9-2CA11F2AFE85 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Alexey, Initially the draft a dated the value to be globally unique. But, based on the assumption that the value is only used within the scope of= a given message, we decided to only mandate uniqueness within a given messa= ge. Regards, Christer Sent from my iPhone > On 6 Jul 2017, at 12.47, Alexey Melnikov wrote: >=20 > Alexey Melnikov has entered the following ballot position for > draft-ietf-sipcore-content-id-07: No Objection >=20 > 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.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-content-id/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I've checked whether this is consistent with email use and it seems to be.= >=20 > Note that RFC 2392 says: >=20 > The Content-ID of a MIME body part is required to be globally unique. >=20 > and this document only requires it to be unique within a message. >=20 > I don't think the difference in restrictions makes any real world differen= ce, > because I don't think applications enforce uniqueness of Content-IDs betwe= en > different messages. >=20 >=20 --Apple-Mail-60DC34EA-A18B-4DE4-8AF9-2CA11F2AFE85 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8zCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF+TCCA+GgAwIBAgIQMQ1yPcGTNYDzhYWhrkFQyDAN BgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MjAeFw0xNDExMDQxMjI4MTlaFw0xNzExMDQxMjI4MThaMG8xETAPBgNV BAoMCEVyaWNzc29uMRowGAYDVQQDDBFDaHJpc3RlciBIb2xtYmVyZzEtMCsGCSqGSIb3DQEJARYe Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tMQ8wDQYDVQQFEwZMTUZDSEgwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCMb7fHWIV9CIFYYov86NR/6ibdVV0I+ZqVLE21zQB7otFv 6DTKlVXE7iiC4HCvMhlGkg3/qFmAhAti5Z1Z7+5eEMEIP5JJEZ7fMm6BME33Bkdgg4EfJrq4FUG2 8Hw2//0qx3jZWvK2W751AmEuUJ5nkZ6F00GnzJmOhbveadC8E5keqwow9ria0/WazHiK3wxzjban oQaZIA+oCKj5YyCv8cCTaSk4pEAbXwxthJ97BaZPahsnb4EZEP08gxR5IE9NRi47Eqh6LtBjiWpa B42EmCEBxc2uIQ87tlJ0e2SvCo74rqxndXtUeaWauMjjt4DnhJdiXZY244D5J1gWssRFAgMBAAGj ggHEMIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmlj c3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNlcjApBgNVHREEIjAggR5j aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIw OjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9D UFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBRUo03/DrRAW2xpMmhN 2uGkvDgx6jAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAw DQYJKoZIhvcNAQEFBQADggIBALbwqG5inhl/xPxsuQWcH7GOUZIPAw0JlKltVQ/TlsF7ig0J1iyz ao6GsXItJ9H3WZPrCy5EQchJm7qcn2kKX8OGb+Yr53FisLR2gx+qkrQMDOdix9Was0cvIjDWjAQn EZbxz/a+dzdAP0TrwNvD8282bIy0fCt/3uoBfzMnvQG+4wG018bDunc+NCj1FkSKkSRb9fP2Z2li 65pfJcxtGIfb5zsXJZG4Gtbe0/hxlj3NccjB/zVPO7PQ+lnWmxtOiJQ2loA+62vQreUQr328XK4I HFnoU+zXiVfUN2urvvirQH7Ha70TBMa20J8Nn2aEvY6QYMEQJhAiVmNTiv4EGGv5heX5vb8yaj7p r4YIvb6D0r+pwpvfEE8YhAEWJgCZP7k5zQwhrpuSF/s+wEruXo59sq9bOCefghktc5fwDu8ved98 cifRPUnuT/c5slJJ8LjFn8d+LnGklUdFA9kLjIJVVx+TM4D/OTaRG+mPFbY2pTyR0V84PG7HLeku pNsFzcme7IBkQ+1zkb9hjz6pyiodf6rh7ph+8XHWNgzbC5PdGCANg8fVWrxqqOoEzvcUcPMy6XXJ s0JWhWas8mJdHq2kGDDEpA7BbBatmtEqziXRnYGJeQK3eMDXXtmOeBSA4y7YZ47y+CxvbknSQ5dy ghwkEq+a7ORPGVjsjtWJYJ6dMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZI hvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJv b3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmlj c3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcN AQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/yQori I+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8GoFOvtuV HNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAU bmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq5/yHaS48jCsOBAU0 TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9 dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpa mOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA141dhCy5EScOyNajrAXQupsDn vr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6MqeaTS9HchPtBvOrah/cTWzXzGj wMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUF BzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6 Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNl cjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYB BQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1Ud HwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25l cmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQE AwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+a lgzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUieg mAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGagdRc mH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/O zFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr /oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko 3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8 b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NY sjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+ 9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApICAQEwTjA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQMQ1yPcGTNYDz hYWhrkFQyDAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA3MDYxMDE2NTNaMCMGCSqGSIb3DQEJBDEWBBRqMVr/D4Y+NNr9IG7T7i3m1BTV sTBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYyAhAxDXI9wZM1gPOFhaGuQVDIMF8GCyqGSIb3DQEJEAILMVCg TjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MgIQMQ1yPcGTNYDzhYWhrkFQyDANBgkqhkiG9w0BAQEFAASCAQCFnKnAi7sceb90qL60J1zd fO6NIEuKBS4fHUxR9r6AqdxC6ElBRrS/HFlxqpS2JZTfv/s6Mp7h3dwwn/0xH7/+jPaa382g8y/a OrLfnDzgkpxDXuLSu7yULWhvOKWSMJ3gfYH9q5cNd9AyJAORVP+FAy0dOhgQmcRiCwIP0pDNSAKl 9YPSzsA/EYgyL1emAlKHwva2JF/jBd2YumoQZWu7pDPDxRIHANOoqEHchzIBIY2f/K/hjk3dtbA0 O1kNfmOyVbyrCvuXQVWS7/qLUs/e4yXYsZmMl8DhJtXt7NC+0IM+8X99sR4SkMLsj7WfOTU7PV9o Le+3U+4tMV58qGQyAAAAAAAA --Apple-Mail-60DC34EA-A18B-4DE4-8AF9-2CA11F2AFE85-- From nobody Thu Jul 6 08:19:59 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333661315F7; Thu, 6 Jul 2017 08:19:58 -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=unavailable 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 RPuuSwvv37BL; Thu, 6 Jul 2017 08:19:57 -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 3C51E13165E; Thu, 6 Jul 2017 08:19:57 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v66FJq3o079925 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 6 Jul 2017 10:19:52 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Christer Holmberg , Eric Rescorla , The IESG Cc: "sipcore@ietf.org" , "draft-ietf-sipcore-content-id@ietf.org" , "mahoney@nostrum.com" , "sipcore-chairs@ietf.org" References: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CC50BB3@ESESSMB109.ericsson.se> From: Adam Roach Message-ID: <4c10a5e5-e2e0-a8bd-c038-2f2ef342daeb@nostrum.com> Date: Thu, 6 Jul 2017 10:19:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CC50BB3@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and 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, 06 Jul 2017 15:19:58 -0000 On 7/5/17 13:53, Christer Holmberg wrote: > Note that the draft does not update the existing multipart usages (RFC 5368 and 6442). So, the draft does not cause any backward compatibility issues. > > (Now, IF people want to change existing multipart usages, I agree there needs to be a mechanism to ensure that the endpoints understand it. We can add some text about that. I think that is also what Paul indicated.) Right. I think this document really needs to contain text that normatively says that implementations can't use Content-ID as a SIP header field (and elide the multipart top-level type) except with those mechanisms that have explicitly "opted in" -- which is to say, the corresponding protocol document needs to contain text saying that this is an okay thing to do. Example 1, in particular, needs a clear disclaimer that the described mechanism *cannot* be used with this example unless and until RFC6442 is updated. > The draft allows any new usages not having to use multipart (if there is only one body part), and (as pointed out by Adam) makes existing usages (RFC 5368 and 6080) of Content-ID as a SIP header field standards compliant. I'll note that these two documents didn't explicitly say that they could use Content-ID as a SIP header field; they only showed doing so in examples. For the sake of normative tidiness, I would suggest that sipcore-content-id specifically update these two RFCs, and have text that explicitly and normatively allows the use of non-multipart top-level content types for multiple-target REFER requests and for device profile NOTIFY messages. /a From nobody Thu Jul 6 10:46: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 69FC413186B; Thu, 6 Jul 2017 10:46: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 7pfHglawttps; Thu, 6 Jul 2017 10:46:02 -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 9381013184A; Thu, 6 Jul 2017 10:45:55 -0700 (PDT) X-AuditID: c1b4fb25-607ff70000001eeb-ab-595e775129aa Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 68.62.07915.1577E595; Thu, 6 Jul 2017 19:45:53 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Thu, 6 Jul 2017 19:45:52 +0200 From: Christer Holmberg To: Adam Roach , Eric Rescorla , The IESG CC: "sipcore@ietf.org" , "draft-ietf-sipcore-content-id@ietf.org" , "mahoney@nostrum.com" , "sipcore-chairs@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and COMMENT) Thread-Index: AQHS9YeSl7jlBr6gNkqjMJoiy+ImKKJFklVAgAE3rgCAAD3L8A== Date: Thu, 6 Jul 2017 17:45:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC53AE4@ESESSMB109.ericsson.se> References: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CC50BB3@ESESSMB109.ericsson.se> <4c10a5e5-e2e0-a8bd-c038-2f2ef342daeb@nostrum.com> In-Reply-To: <4c10a5e5-e2e0-a8bd-c038-2f2ef342daeb@nostrum.com> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7hG5geVykwaK1YhZ7/i5itzj9dQaT xYrX59gtZvyZyGzR0LmS1aL380Jmi68/NrE5sHssWfKTyWPWzicsHpMftzEHMEdx2aSk5mSW pRbp2yVwZfSe+ctcsEin4te/92wNjBO0uxg5OSQETCQ2vZzI0sXIxSEkcIRR4uestcwQziJG iTkf2oAyHBxsAhYS3f/AGkQEoiWuXHvHCFLDLPCEUWJB+3M2kISwQJrE6XcXWSCK0iVuHl4H ZTtJ7FzewgYyh0VAReLn9CqQMK+Ar8SJa+cYIXYdY5To37CRGSTBKWAv8fjYb7BeRgExie+n 1jCB2MwC4hK3nsxngrhaQGLJnvPMELaoxMvH/1ghbCWJFdsvMYLsYhbQlFi/Sx+iVVFiSvdD doi9ghInZz5hmcAoOgvJ1FkIHbOQdMxC0rGAkWUVo2hxanFSbrqRsV5qUWZycXF+nl5easkm RmCEHdzyW3UH4+U3jocYBTgYlXh4j0fFRQqxJpYVV+YeYpTgYFYS4d0qCRTiTUmsrEotyo8v Ks1JLT7EKM3BoiTO67jvQoSQQHpiSWp2ampBahFMlomDU6qBsddpQY+4nPrlSa7LJPTnpyfW 3o67yfxXIUVzb2Ts9AKjp3yejra6Ew6yn2NUVbad0PXHdV1o/YmSzzyn8107c84snOfnvbNV fcrCdVwlGf4z47LXLLpisWjOTdWXS88/YlITytYrKPM/ctyy9znjjjW/3NZO35PrGfnryoYT Rt8XH46PFrZXVmIpzkg01GIuKk4EAKaw8n+sAgAA Archived-At: Subject: Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and 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, 06 Jul 2017 17:46:05 -0000 SGksDQoNCj4+IE5vdGUgdGhhdCB0aGUgZHJhZnQgZG9lcyBub3QgdXBkYXRlIHRoZSBleGlzdGlu ZyBtdWx0aXBhcnQgdXNhZ2VzIChSRkMgNTM2OCBhbmQgNjQ0MikuIFNvLCB0aGUgZHJhZnQgZG9l cyBub3QgY2F1c2UgYW55IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWVzLg0KPj4NCj4+IChO b3csIElGIHBlb3BsZSB3YW50IHRvIGNoYW5nZSBleGlzdGluZyBtdWx0aXBhcnQgdXNhZ2VzLCBJ IGFncmVlIA0KPj4gdGhlcmUgbmVlZHMgdG8gYmUgYSBtZWNoYW5pc20gdG8gZW5zdXJlIHRoYXQg dGhlIGVuZHBvaW50cyB1bmRlcnN0YW5kIA0KPj4gaXQuIFdlIGNhbiBhZGQgc29tZSB0ZXh0IGFi b3V0IHRoYXQuIEkgdGhpbmsgdGhhdCBpcyBhbHNvIHdoYXQgUGF1bCANCj4+IGluZGljYXRlZC4p DQo+DQo+UmlnaHQuIEkgdGhpbmsgdGhpcyBkb2N1bWVudCByZWFsbHkgbmVlZHMgdG8gY29udGFp biB0ZXh0IHRoYXQgbm9ybWF0aXZlbHkgc2F5cyB0aGF0IGltcGxlbWVudGF0aW9ucyBjYW4ndCB1 c2UgQ29udGVudC1JRCBhcyBhIFNJUCBoZWFkZXIgZmllbGQgKGFuZCBlbGlkZSB0aGUgbXVsdGlw YXJ0IHRvcC0+bGV2ZWwgdHlwZSkgZXhjZXB0IHdpdGggdGhvc2UgbWVjaGFuaXNtcyB0aGF0IGhh dmUgZXhwbGljaXRseSAib3B0ZWQgaW4iIC0tIHdoaWNoIGlzIHRvIHNheSwgdGhlIGNvcnJlc3Bv bmRpbmcgcHJvdG9jb2wgZG9jdW1lbnQgbmVlZHMgdG8gY29udGFpbiB0ZXh0IHNheWluZyB0aGF0 IHRoaXMgaXMgYW4gPm9rYXkgdGhpbmcgdG8gZG8uIEV4YW1wbGUgMSwgaW4gcGFydGljdWxhciwg bmVlZHMgYSBjbGVhciBkaXNjbGFpbWVyIHRoYXQgdGhlIGRlc2NyaWJlZCBtZWNoYW5pc20gKmNh bm5vdCogYmUgdXNlZCB3aXRoIHRoaXMgZXhhbXBsZSB1bmxlc3MgYW5kIHVudGlsIFJGQzY0NDIg aXMgdXBkYXRlZC4NCg0KV2hhdCBhYm91dCB0aGUgZm9sbG93aW5nIG5ldyBzZWN0aW9uOg0KDQog ICAgICA8c2VjdGlvbiB0aXRsZT0iQmFja3dhcmQgY29tcGF0aWJpbGl0eSIgdG9jPSJkZWZhdWx0 Ij4NCiAgICAgICAgPHQ+DQogICAgICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IHVw ZGF0ZSBhbnkgb2YgdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlvbnMgZGVmaW5pbmcgdXNhZ2Ugb2Yg Q29udGVudC1JRA0KICAgICAgICAgIFVSTHMgZm9yIHJlZmVyZW5jaW5nIGJvZHkgcGFydHMsIGFu ZCBpbXBsZW1lbnRhdGlvbnMgb2Ygc3VjaCBzcGVjaWZpY2F0aW9ucyBNVVNUIE5PVCBiZSBtb2Rp ZmllZCBpbiANCiAgICAgICAgICBhIGJhY2t3YXJkIGluY29tcGF0aWJsZSB3YXkgKGV2ZW4gaWYg dGhlIHB1YmxpY2F0aW9uIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiB3b3VsZCBhbGxvdyBzdWNoIGNo YW5nZSksIA0KICAgICAgICAgIHVubGVzcyB0aGVyZSBpcyBhIG1lY2hhbmlzbSB0byBlbnN1cmUg dGhhdCB0aGUgZW5kcG9pbnRzIHN1cHBvcnQgc3VjaCBtb2RpZmljYXRpb24uIA0KICAgICAgICA8 L3Q+DQogICAgICA8L3NlY3Rpb24+DQoNCj4+IFRoZSBkcmFmdCBhbGxvd3MgYW55IG5ldyB1c2Fn ZXMgbm90IGhhdmluZyB0byB1c2UgbXVsdGlwYXJ0IChpZiB0aGVyZSBpcyBvbmx5IG9uZSBib2R5 IHBhcnQpLCANCj4+IGFuZCAoYXMgcG9pbnRlZCBvdXQgYnkgQWRhbSkgbWFrZXMgZXhpc3Rpbmcg dXNhZ2VzIChSRkMgNTM2OCBhbmQgNjA4MCkgb2YgQ29udGVudC1JRCBhcyBhIA0KPj4gU0lQIGhl YWRlciBmaWVsZCBzdGFuZGFyZHMgY29tcGxpYW50Lg0KPg0KPiBJJ2xsIG5vdGUgdGhhdCB0aGVz ZSB0d28gZG9jdW1lbnRzIGRpZG4ndCBleHBsaWNpdGx5IHNheSB0aGF0IHRoZXkgY291bGQgdXNl IENvbnRlbnQtSUQgYXMgYSBTSVAgaGVhZGVyIGZpZWxkOyB0aGV5IG9ubHkgc2hvd2VkIA0KPiBk b2luZyBzbyBpbiBleGFtcGxlcy4gRm9yIHRoZSBzYWtlIG9mIG5vcm1hdGl2ZSB0aWRpbmVzcywg SSB3b3VsZCBzdWdnZXN0IHRoYXQgc2lwY29yZS1jb250ZW50LWlkIHNwZWNpZmljYWxseSB1cGRh dGUgdGhlc2UgdHdvIA0KPiBSRkNzLCBhbmQgaGF2ZSB0ZXh0IHRoYXQgZXhwbGljaXRseSBhbmQg bm9ybWF0aXZlbHkgYWxsb3dzIHRoZSB1c2Ugb2Ygbm9uLW11bHRpcGFydCB0b3AtbGV2ZWwgY29u dGVudCB0eXBlcyBmb3IgbXVsdGlwbGUtdGFyZ2V0IA0KPiBSRUZFUiByZXF1ZXN0cyBhbmQgZm9y IGRldmljZSBwcm9maWxlIE5PVElGWSBtZXNzYWdlcy4NCg0KV2UgY291bGQgdXBkYXRlIFJGQyA1 MzY4IGJ5IHVwZGF0aW5nIHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24gNzoNCg0KT0xE Og0KDQogICAiVGhlIFJlZmVyLVRvIGhlYWRlciBmaWVsZCBvZiBhIFJFRkVSIHJlcXVlc3Qgd2l0 aCBtdWx0aXBsZSBSRUZFUi0NCiAgIFRhcmdldHMgTVVTVCBjb250YWluIGEgcG9pbnRlciAoaS5l LiwgYSBDb250ZW50LUlEIFVuaWZvcm0gUmVzb3VyY2UNCiAgIExvY2F0b3IgKFVSTCkgYXMgcGVy IFJGQyAyMzkyIFtSRkMyMzkyXSkgdGhhdCBwb2ludHMgdG8gdGhlIGJvZHkgcGFydA0KICAgdGhh dCBjYXJyaWVzIHRoZSBVUkkgbGlzdC4gIFRoZSBSRUZFUi1Jc3N1ZXIgU0hPVUxEIE5PVCBpbmNs dWRlIGFueQ0KICAgcGFydGljdWxhciBVUkkgbW9yZSB0aGFuIG9uY2UgaW4gdGhlIFVSSSBsaXN0 LiINCg0KTkVXOg0KDQogICAiVGhlIFJlZmVyLVRvIGhlYWRlciBmaWVsZCBvZiBhIFJFRkVSIHJl cXVlc3Qgd2l0aCBtdWx0aXBsZSBSRUZFUi0NCiAgIFRhcmdldHMgTVVTVCBjb250YWluIGEgcG9p bnRlciAoaS5lLiwgYSBDb250ZW50LUlEIFVuaWZvcm0gUmVzb3VyY2UNCiAgIExvY2F0b3IgKFVS TCkgYXMgcGVyIFJGQyAyMzkyIFtSRkMyMzkyXSkgdGhhdCBwb2ludHMgdG8gdGhlIGJvZHkgcGFy dA0KICAgdGhhdCBjYXJyaWVzIHRoZSBVUkkgbGlzdC4gIFRoZSBSRUZFUi1Jc3N1ZXIgU0hPVUxE IE5PVCBpbmNsdWRlIGFueQ0KICAgcGFydGljdWxhciBVUkkgbW9yZSB0aGFuIG9uY2UgaW4gdGhl IFVSSSBsaXN0LiBUaGUgUkVGRVINCiAgIHJlcXVlc3QgY2FuIGNvbnRhaW4gYSBTSVAgQ29udGVu dC1JRCBoZWFkZXIgZmllbGQgcmVmZXJlbmNpbmcgdGhlDQogICBtZXNzYWdlLWJvZHkuIg0KDQoN CldlIGNvdWxkIHVwZGF0ZSBSRkMgNjA4MCBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBuZXcgcGFy YWdyYXBoIHRvIHNlY3Rpb24gNi41Og0KDQpORVc6DQoNCiAgICJUaGUgTk9USUZZIHJlcXVlc3Qg Y2FuIGNvbnRhaW4gYSBTSVAgQ29udGVudC1JRCBoZWFkZXIgZmllbGQgcmVmZXJlbmNpbmcgdGhl DQogICBtZXNzYWdlLWJvZHkuIg0KDQoNCkluIGFkZGl0aW9uLCBJIHN1Z2dlc3QgYWRkaW5nIHRo ZSBmb2xsb3dpbmcgcGFyYWdyYXBoIHRvIHRoZSAnUHJvYmxlbSBzdGF0ZW1lbnQnIHNlY3Rpb246 DQoNCiAgICAgICAgPHQ+DQogICAgICAgICAgPHhyZWYgdGFyZ2V0PSJSRkM1MzY4IiBwYWdlbm89 ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiLz4gYW5kIDx4cmVmIHRhcmdldD0iUkZDNjA4MCINCiAg ICAgICAgICBwYWdlbm89ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiLz4gY29udGFpbiBleGFtcGxl cyB0aGF0IHNob3cgdXNhZ2Ugb2YgYSBTSVAgQ29udGVudC1JRCANCiAgICAgICAgICBoZWFkZXIg ZmllbGQgcmVmZXJlbmNpbmcgYSBjb21wbGV0ZSBtZXNzYWdlLWJvZHksIGV2ZW50aG91Z2ggc3Vj aCB1c2FnZSBoYWQgbm90IGJlZW4NCiAgICAgICAgICBzcGVjaWZpZWQgd2hlbiB0aG9zZSBSRkNz IHdlcmUgcHVibGlzaGVkLg0KICAgICAgICA8L3Q+DQoNCi4uLmFuZCB0byBhZGQgdGhlIGZvbGxv d2luZyBidWxsZXQgdG8gdGhlICdTb2x1dGlvbicgc2VjdGlvbjoNCg0KICAgICAgICAgICAgICA8 dD4NCiAgICAgICAgICAgICAgICAgICAgVXBkYXRlcyA8eHJlZiB0YXJnZXQ9IlJGQzUzNjgiIHBh Z2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIvPiBhbmQgPHhyZWYgdGFyZ2V0PSJSRkM2MDgw Ig0KICAgICAgICAgICAgICAgICAgICBwYWdlbm89ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiLz4g YnkgYWRkaW5nIGV4cGxpY2l0IHRleHQgc2F5aW5nIHRoYXQgYSBTSVAgQ29udGVudC1JRCBoZWFk ZXIgDQogICAgICAgICAgICAgICAgICAgIGZpZWxkIGNhbiBiZSB1c2VkLg0KICAgICAgICAgICAg ICA8L3Q+IA0KDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From nobody Thu Jul 6 14:23: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 D00C312EA6A; Thu, 6 Jul 2017 14:23:54 -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=unavailable 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 hQ2RNEl0gCua; Thu, 6 Jul 2017 14:23:53 -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 9CEC312EC2B; Thu, 6 Jul 2017 14:23:53 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v66LNmaG041196 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 6 Jul 2017 16:23:49 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Christer Holmberg , Eric Rescorla , The IESG Cc: "sipcore@ietf.org" , "draft-ietf-sipcore-content-id@ietf.org" , "mahoney@nostrum.com" , "sipcore-chairs@ietf.org" References: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CC50BB3@ESESSMB109.ericsson.se> <4c10a5e5-e2e0-a8bd-c038-2f2ef342daeb@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CC53AE4@ESESSMB109.ericsson.se> From: Adam Roach Message-ID: <4421323a-7bc8-d8af-7072-8ec3ca438f0b@nostrum.com> Date: Thu, 6 Jul 2017 16:23:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CC53AE4@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and 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, 06 Jul 2017 21:23:55 -0000 On 7/6/17 12:45, Christer Holmberg wrote: > Hi, > >>> Note that the draft does not update the existing multipart usages (RFC 5368 and 6442). So, the draft does not cause any backward compatibility issues. >>> >>> (Now, IF people want to change existing multipart usages, I agree >>> there needs to be a mechanism to ensure that the endpoints understand >>> it. We can add some text about that. I think that is also what Paul >>> indicated.) >> Right. I think this document really needs to contain text that normatively says that implementations can't use Content-ID as a SIP header field (and elide the multipart top->level type) except with those mechanisms that have explicitly "opted in" -- which is to say, the corresponding protocol document needs to contain text saying that this is an >okay thing to do. Example 1, in particular, needs a clear disclaimer that the described mechanism *cannot* be used with this example unless and until RFC6442 is updated. > What about the following new section: > >
> > This specification does not update any of the current specifications defining usage of Content-ID > URLs for referencing body parts, and implementations of such specifications MUST NOT be modified in > a backward incompatible way (even if the publication of this specification would allow such change), > unless there is a mechanism to ensure that the endpoints support such modification. > >
That looks good, with two minor adjustments. 1. "Except as noted in section , this specification does not update..." where "section " refers to the updates you propose below. 2. In section 1.4.1, add a "Note that this example cannot be used with the mechanism described in this document unless and until [RFC6442] is updated; see section for details." >>> The draft allows any new usages not having to use multipart (if there is only one body part), >>> and (as pointed out by Adam) makes existing usages (RFC 5368 and 6080) of Content-ID as a >>> SIP header field standards compliant. >> I'll note that these two documents didn't explicitly say that they could use Content-ID as a SIP header field; they only showed >> doing so in examples. For the sake of normative tidiness, I would suggest that sipcore-content-id specifically update these two >> RFCs, and have text that explicitly and normatively allows the use of non-multipart top-level content types for multiple-target >> REFER requests and for device profile NOTIFY messages. > We could update RFC 5368 by updating the second paragraph of section 7: > > OLD: > > "The Refer-To header field of a REFER request with multiple REFER- > Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource > Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part > that carries the URI list. The REFER-Issuer SHOULD NOT include any > particular URI more than once in the URI list." > > NEW: > > "The Refer-To header field of a REFER request with multiple REFER- > Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource > Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part > that carries the URI list. The REFER-Issuer SHOULD NOT include any > particular URI more than once in the URI list. The REFER > request can contain a SIP Content-ID header field referencing the > message-body." I'd make it a normative "...request MAY contain...", but aside from that, it looks fine. > > We could update RFC 6080 by adding the following new paragraph to section 6.5: > > NEW: > > "The NOTIFY request can contain a SIP Content-ID header field referencing the > message-body." Same comment regarding "MAY," but that looks fine. > > In addition, I suggest adding the following paragraph to the 'Problem statement' section: > > > and pageno="false" format="default"/> contain examples that show usage of a SIP Content-ID > header field referencing a complete message-body, eventhough such usage had not been > specified when those RFCs were published. > > > ...and to add the following bullet to the 'Solution' section: > > > Updates and pageno="false" format="default"/> by adding explicit text saying that a SIP Content-ID header > field can be used. > > That looks reasonable; but do note that RFC5368 and RFC6080 need to appear in the document metadata (as "Updates"), and they need to be mentioned in the Abstract ("This document updates RFC 5368 and RFC 6080 to clarify their use of Content-ID.") /a From nobody Thu Jul 6 14:35:20 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 9408C12EB9B; Thu, 6 Jul 2017 14:35:19 -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 O_LbSupSBB4n; Thu, 6 Jul 2017 14:35:17 -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 BCC5E129B43; Thu, 6 Jul 2017 14:35:17 -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 v66LZBfp043223 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 6 Jul 2017 16:35:13 -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] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CC53AE4@ESESSMB109.ericsson.se> Date: Thu, 6 Jul 2017 16:35:11 -0500 Cc: Adam Roach , Eric Rescorla , The IESG , "sipcore@ietf.org" , "draft-ietf-sipcore-content-id@ietf.org" , "A. Jean Mahoney" , "sipcore-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <46C1E67C-03F8-4A79-9597-E3996B531B95@nostrum.com> References: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CC50BB3@ESESSMB109.ericsson.se> <4c10a5e5-e2e0-a8bd-c038-2f2ef342daeb@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CC53AE4@ESESSMB109.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and 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, 06 Jul 2017 21:35:20 -0000 Some comments inline.=20 BTW, I think updates to 5368 and 6080 would be material enough to = require WG approval. (Read: sipcore participants, please pay attention) > On Jul 6, 2017, at 12:45 PM, Christer Holmberg = wrote: >=20 > Hi, >=20 >>> Note that the draft does not update the existing multipart usages = (RFC 5368 and 6442). So, the draft does not cause any backward = compatibility issues. >>>=20 >>> (Now, IF people want to change existing multipart usages, I agree=20 >>> there needs to be a mechanism to ensure that the endpoints = understand=20 >>> it. We can add some text about that. I think that is also what Paul=20= >>> indicated.) >>=20 >> Right. I think this document really needs to contain text that = normatively says that implementations can't use Content-ID as a SIP = header field (and elide the multipart top->level type) except with those = mechanisms that have explicitly "opted in" -- which is to say, the = corresponding protocol document needs to contain text saying that this = is an >okay thing to do. Example 1, in particular, needs a clear = disclaimer that the described mechanism *cannot* be used with this = example unless and until RFC6442 is updated. >=20 > What about the following new section: >=20 >
> > This specification does not update any of the current = specifications defining usage of Content-ID > URLs for referencing body parts, and implementations of such = specifications MUST NOT be modified in=20 > a backward incompatible way (even if the publication of this = specification would allow such change),=20 > unless there is a mechanism to ensure that the endpoints = support such modification.=20 > >
Won=E2=80=99t the =E2=80=9Cdoes not update=E2=80=9D bit become untrue if = we add the proposed updates (below)? >=20 >>> The draft allows any new usages not having to use multipart (if = there is only one body part),=20 >>> and (as pointed out by Adam) makes existing usages (RFC 5368 and = 6080) of Content-ID as a=20 >>> SIP header field standards compliant. >>=20 >> I'll note that these two documents didn't explicitly say that they = could use Content-ID as a SIP header field; they only showed=20 >> doing so in examples. For the sake of normative tidiness, I would = suggest that sipcore-content-id specifically update these two=20 >> RFCs, and have text that explicitly and normatively allows the use of = non-multipart top-level content types for multiple-target=20 >> REFER requests and for device profile NOTIFY messages. >=20 > We could update RFC 5368 by updating the second paragraph of section = 7: >=20 > OLD: >=20 > "The Refer-To header field of a REFER request with multiple REFER- > Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource > Locator (URL) as per RFC 2392 [RFC2392]) that points to the body = part > that carries the URI list. The REFER-Issuer SHOULD NOT include any > particular URI more than once in the URI list." >=20 > NEW: >=20 > "The Refer-To header field of a REFER request with multiple REFER- > Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource > Locator (URL) as per RFC 2392 [RFC2392]) that points to the body = part > that carries the URI list. The REFER-Issuer SHOULD NOT include any > particular URI more than once in the URI list. The REFER > request can contain a SIP Content-ID header field referencing the > message-body.=E2=80=9D >=20 I=E2=80=99m not sure I agree there=E2=80=99s a need to update 5386, = since as far as I can find, it doesn=E2=80=99t have text that says = anything about how the content-ID is labeled other than in the example. = But I don=E2=80=99t object if other=E2=80=99s feel strongly. If w do = update it, I suggest the following variation (or something to it=E2=80=99s= effect): NEW: "The Refer-To header field of a REFER request with multiple REFER- Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource Locator (URL) as per RFC 2392 [RFC2392]) that points to the message = body=20 or body part that carries the URI list. The REFER-Issuer SHOULD NOT=20= include any particular URI more than once in the URI list. The REFER request can use either a MIME Content-ID header field [RFC4483 ] or a=20= SIP Content-ID header field [RFCTHIS] to label the message-body.=E2=80=9D= >=20 > We could update RFC 6080 by adding the following new paragraph to = section 6.5: >=20 > NEW: >=20 > "The NOTIFY request can contain a SIP Content-ID header field = referencing the > message-body.=E2=80=9D >=20 I=E2=80=99m not sure that quite works, since there=E2=80=99s already = text in 6.5 saying it MUST use the Content-ID MIME header field. How about this for the second sentence of the first paragraph: OLD: For profile data delivered via content indirection, i.e., a pointer = to a PCC, then=20 the Content-ID MIME header, as described in [RFC4483 ], MUST be used=20= for each profile document URI. NEW For profile data delivered via content indirection, i.e., a pointer = to a PCC, then=20 either a Content-ID MIME header field [RFC4483 ] or the Content-ID = SIP header field [RFCTHIS] MUST be used for each profile document URI. >=20 > In addition, I suggest adding the following paragraph to the 'Problem = statement' section: >=20 > > = and pageno=3D"false" format=3D"default"/> contain examples that = show usage of a SIP Content-ID=20 > header field referencing a complete message-body, eventhough = such usage had not been > specified when those RFCs were published. > >=20 > ...and to add the following bullet to the 'Solution' section: >=20 > > Updates and pageno=3D"false" format=3D"default"/> by adding = explicit text saying that a SIP Content-ID header=20 > field can be used. > =20 >=20 >=20 > Regards, >=20 > Christer From nobody Thu Jul 6 14: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 8F759131CCC; Thu, 6 Jul 2017 14:42:37 -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 Qmc1b5S7nXUX; Thu, 6 Jul 2017 14:42:36 -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 D672C131CCB; Thu, 6 Jul 2017 14:42:35 -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 v66LgU5i044381 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 6 Jul 2017 16:42:30 -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] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <4421323a-7bc8-d8af-7072-8ec3ca438f0b@nostrum.com> Date: Thu, 6 Jul 2017 16:42:29 -0500 Cc: Christer Holmberg , Eric Rescorla , The IESG , "sipcore@ietf.org" , "draft-ietf-sipcore-content-id@ietf.org" , "A. Jean Mahoney" , "sipcore-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CC50BB3@ESESSMB109.ericsson.se> <4c10a5e5-e2e0-a8bd-c038-2f2ef342daeb@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CC53AE4@ESESSMB109.ericsson.se> <4421323a-7bc8-d8af-7072-8ec3ca438f0b@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and 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, 06 Jul 2017 21:42:37 -0000 > On Jul 6, 2017, at 4:23 PM, Adam Roach wrote: >=20 > On 7/6/17 12:45, Christer Holmberg wrote: >> Hi, >>=20 >>>> Note that the draft does not update the existing multipart usages = (RFC 5368 and 6442). So, the draft does not cause any backward = compatibility issues. >>>>=20 >>>> (Now, IF people want to change existing multipart usages, I agree >>>> there needs to be a mechanism to ensure that the endpoints = understand >>>> it. We can add some text about that. I think that is also what Paul >>>> indicated.) >>> Right. I think this document really needs to contain text that = normatively says that implementations can't use Content-ID as a SIP = header field (and elide the multipart top->level type) except with those = mechanisms that have explicitly "opted in" -- which is to say, the = corresponding protocol document needs to contain text saying that this = is an >okay thing to do. Example 1, in particular, needs a clear = disclaimer that the described mechanism *cannot* be used with this = example unless and until RFC6442 is updated. >> What about the following new section: >>=20 >>
>> >> This specification does not update any of the current = specifications defining usage of Content-ID >> URLs for referencing body parts, and implementations of = such specifications MUST NOT be modified in >> a backward incompatible way (even if the publication of = this specification would allow such change), >> unless there is a mechanism to ensure that the endpoints = support such modification. >> >>
>=20 > That looks good, with two minor adjustments. >=20 > 1. "Except as noted in section , this specification does not = update..." where "section " refers to the updates you propose below. >=20 > 2. In section 1.4.1, add a "Note that this example cannot be used with = the mechanism described in this document unless and until [RFC6442] is = updated; see section for details.=E2=80=9D +1 on both >=20 >>>> The draft allows any new usages not having to use multipart (if = there is only one body part), >>>> and (as pointed out by Adam) makes existing usages (RFC 5368 and = 6080) of Content-ID as a >>>> SIP header field standards compliant. >>> I'll note that these two documents didn't explicitly say that they = could use Content-ID as a SIP header field; they only showed >>> doing so in examples. For the sake of normative tidiness, I would = suggest that sipcore-content-id specifically update these two >>> RFCs, and have text that explicitly and normatively allows the use = of non-multipart top-level content types for multiple-target >>> REFER requests and for device profile NOTIFY messages. >> We could update RFC 5368 by updating the second paragraph of section = 7: >>=20 >> OLD: >>=20 >> "The Refer-To header field of a REFER request with multiple REFER- >> Targets MUST contain a pointer (i.e., a Content-ID Uniform = Resource >> Locator (URL) as per RFC 2392 [RFC2392]) that points to the body = part >> that carries the URI list. The REFER-Issuer SHOULD NOT include = any >> particular URI more than once in the URI list." >>=20 >> NEW: >>=20 >> "The Refer-To header field of a REFER request with multiple REFER- >> Targets MUST contain a pointer (i.e., a Content-ID Uniform = Resource >> Locator (URL) as per RFC 2392 [RFC2392]) that points to the body = part >> that carries the URI list. The REFER-Issuer SHOULD NOT include = any >> particular URI more than once in the URI list. The REFER >> request can contain a SIP Content-ID header field referencing the >> message-body." >=20 > I'd make it a normative "...request MAY contain...", but aside from = that, it looks fine. I had a slightly different take (my mail crossed yours in my mailbox): I = don=E2=80=99t see any text that says you also [can/MAY] use the mime = header. So if this becomes normative, the question I have is do we want = to say you MAY use the sip header or the mime header or something else, = or say you MUST use either the sip header or the mime header? >=20 >>=20 >> We could update RFC 6080 by adding the following new paragraph to = section 6.5: >>=20 >> NEW: >>=20 >> "The NOTIFY request can contain a SIP Content-ID header field = referencing the >> message-body." >=20 > Same comment regarding "MAY," but that looks fine. Same comment to your comment (except there=E2=80=99s already text in = 6080 6.5 that says MUST use the mime header.) >=20 >>=20 >> In addition, I suggest adding the following paragraph to the 'Problem = statement' section: >>=20 >> >> and > pageno=3D"false" format=3D"default"/> contain examples that = show usage of a SIP Content-ID >> header field referencing a complete message-body, = eventhough such usage had not been >> specified when those RFCs were published. >> >>=20 >> ...and to add the following bullet to the 'Solution' section: >>=20 >> >> Updates and > pageno=3D"false" format=3D"default"/> by adding = explicit text saying that a SIP Content-ID header >> field can be used. >> >>=20 >=20 > That looks reasonable; but do note that RFC5368 and RFC6080 need to = appear in the document metadata (as "Updates"), and they need to be = mentioned in the Abstract ("This document updates RFC 5368 and RFC 6080 = to clarify their use of Content-ID.") >=20 > /a >=20 From nobody Fri Jul 7 12:39:20 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 0AD0E13155E; Fri, 7 Jul 2017 12:39:20 -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 Zao4UtVqPV1h; Fri, 7 Jul 2017 12:39:17 -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 D1673127337; Fri, 7 Jul 2017 12:39:16 -0700 (PDT) X-AuditID: c1b4fb2d-7ebff70000005faa-01-595fe3629666 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3A.16.24490.263EF595; Fri, 7 Jul 2017 21:39:14 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Fri, 7 Jul 2017 21:39:14 +0200 From: Christer Holmberg To: Adam Roach , Eric Rescorla , The IESG CC: "sipcore@ietf.org" , "draft-ietf-sipcore-content-id@ietf.org" , "mahoney@nostrum.com" , "sipcore-chairs@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and COMMENT) Thread-Index: AQHS9YeSl7jlBr6gNkqjMJoiy+ImKKJFklVAgAE3rgCAAD3L8IAAJ+WAgAGSW8A= Date: Fri, 7 Jul 2017 19:39:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC55723@ESESSMB109.ericsson.se> References: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CC50BB3@ESESSMB109.ericsson.se> <4c10a5e5-e2e0-a8bd-c038-2f2ef342daeb@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CC53AE4@ESESSMB109.ericsson.se> <4421323a-7bc8-d8af-7072-8ec3ca438f0b@nostrum.com> In-Reply-To: <4421323a-7bc8-d8af-7072-8ec3ca438f0b@nostrum.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7rm7S4/hIg1kXrC32/F3EbnH66wwm ixWvz7FbzPgzkdmioXMlq0Xv54XMFl9/bGJzYPdYsuQnk8esnU9YPCY/bmMOYI7isklJzcks Sy3St0vgyjjwnbNgl3PF0RM/WRoY7zh2MXJwSAiYSFzcpdvFyMUhJHCEUWLC4yYmCGcRo8Tk QzfYQIrYBCwkuv9pdzFycogIREtcufaOEaSGWeAJo8SC9udsIAlhgTSJ0+8uskAUpUvcPLwO yvaTWPnjPCuIzSKgIvFhynsmEJtXwFfi3sOtUMv2M0l0T50KNohTwF7i9b71zCA2o4CYxPdT a8AamAXEJW49mQ9mSwgISCzZc54ZwhaVePn4HyuErSTRuOQJK8jRzAKaEut36UO0KkpM6X7I DrFXUOLkzCcsExhFZyGZOguhYxaSjllIOhYwsqxiFC1OLS7OTTcy1kstykwuLs7P08tLLdnE CIyvg1t+6+5gXP3a8RCjAAejEg/vzHPxkUKsiWXFlbmHGCU4mJVEeJu9gUK8KYmVValF+fFF pTmpxYcYpTlYlMR5HfZdiBASSE8sSc1OTS1ILYLJMnFwSjUwMukLBp7KvqvXEPrR+8BCwfJf ZpMMF/CXfGd7JTeR12Edy/YNOx53LhQ6v+kqZ6/LjV3ayy+/DLzLpmiUt6d2ycWLe5z8Xfav mbNo6p0nYve+rHVN3Py9QK4s1ftOYM+FjK27Ni2/Kf8qXj5gmezX63N+LuQxnLrn0SqxuQqW h4qj0jb9uPjoaYQSS3FGoqEWc1FxIgD7Ta/dqwIAAA== Archived-At: Subject: Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and 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, 07 Jul 2017 19:39:20 -0000 SGksDQoNCk9uZSB0aGluZyB0aGF0IEkgZm9yZ290IGVhcmxpZXI6DQoNClVubGlrZSB0aGUgb3Ro ZXIgUkZDcyBkZWZpbmluZyBDb250ZW50LUlEIHVzYWdlcywgUkZDIDY0NDIgYWN0dWFsbHkgZG9l c24ndCBjb250YWluIGV4YW1wbGVzIHdpdGggYSBzaW5nbGUgYm9keSBwYXJ0IC0gYWxsIGV4YW1w bGVzIGNvbnRhaW4gbXVsdGlwYXJ0IGJvZGllcyB3aXRoIHR3byBib2R5IHBhcnRzOiBTRFAgYW5k IGxvY2F0aW9uLg0KDQpTbywgdGhlIHF1ZXN0aW9uIGlzIHdoYXQgYW4gaW1wbGVtZW50YXRpb24g d291bGQgZG8gaWYgaXQgT05MWSBzZW5kcyBsb2NhdGlvbj8gV291bGQgaXQgdXNlIGEgU0lQIENv bnRlbnQtSUQgaGVhZGVyIGZpZWxkLCBvciB3aWxsIGl0IHVzZSBhIG11bHRpcGFydCBib2R5IHdp dGggYSBzaW5nbGUgYm9keSBwYXJ0PyANCg0KU28sIHNpbmNlIHdlIFdJTEwgYWxsb3cgU0lQIENv bnRlbnQtSUQgaGVhZGVyIGZpZWxkICh3aXRoIGEgbm9uLW11bHRpcGFydCBib2R5KSBmb3IgUkZD IDU2MzggYW5kIFJGQyA2MDgwLCBzaG91bGRuJ3Qgd2UgZG8gaXQgYWxzbyBmb3IgUkZDIDY0NDI/ IEkgcGVyc29uYWxseSB0aGluayBpdCB3b3VsZCBiZSBzYWZlIHRvIGRvIHNvLCBiZWNhdXNlIHRo ZSBvbmx5IGNhc2Ugd2hlcmUgaXQgY291bGQgY2F1c2UgcHJvYmxlbSBpcyBpZiBzb21lb25lIE9O TFkgc2VuZHMgbG9jYXRpb24gKGkuZS4sIG5vIFNEUCBvciBhbnkgb3RoZXIgYm9keSBwYXJ0KSwg YW5kIGRvZXMgbm90IHVzZSBtdWx0aXBhcnQuIA0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1A bm9zdHJ1bS5jb21dIA0KU2VudDogMDYgSnVseSAyMDE3IDIzOjI0DQpUbzogQ2hyaXN0ZXIgSG9s bWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT47IEVyaWMgUmVzY29ybGEgPGVr ckBydGZtLmNvbT47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IHNpcGNvcmVAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtc2lwY29yZS1jb250ZW50LWlkQGlldGYub3JnOyBtYWhvbmV5QG5vc3Ry dW0uY29tOyBzaXBjb3JlLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IEVyaWMgUmVzY29y bGEncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1jb250ZW50LWlkLTA3OiAod2l0aCBE SVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpPbiA3LzYvMTcgMTI6NDUsIENocmlzdGVyIEhvbG1iZXJn IHdyb3RlOg0KPiBIaSwNCj4NCj4+PiBOb3RlIHRoYXQgdGhlIGRyYWZ0IGRvZXMgbm90IHVwZGF0 ZSB0aGUgZXhpc3RpbmcgbXVsdGlwYXJ0IHVzYWdlcyAoUkZDIDUzNjggYW5kIDY0NDIpLiBTbywg dGhlIGRyYWZ0IGRvZXMgbm90IGNhdXNlIGFueSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzc3Vl cy4NCj4+Pg0KPj4+IChOb3csIElGIHBlb3BsZSB3YW50IHRvIGNoYW5nZSBleGlzdGluZyBtdWx0 aXBhcnQgdXNhZ2VzLCBJIGFncmVlIA0KPj4+IHRoZXJlIG5lZWRzIHRvIGJlIGEgbWVjaGFuaXNt IHRvIGVuc3VyZSB0aGF0IHRoZSBlbmRwb2ludHMgDQo+Pj4gdW5kZXJzdGFuZCBpdC4gV2UgY2Fu IGFkZCBzb21lIHRleHQgYWJvdXQgdGhhdC4gSSB0aGluayB0aGF0IGlzIGFsc28gDQo+Pj4gd2hh dCBQYXVsDQo+Pj4gaW5kaWNhdGVkLikNCj4+IFJpZ2h0LiBJIHRoaW5rIHRoaXMgZG9jdW1lbnQg cmVhbGx5IG5lZWRzIHRvIGNvbnRhaW4gdGV4dCB0aGF0IG5vcm1hdGl2ZWx5IHNheXMgdGhhdCBp bXBsZW1lbnRhdGlvbnMgY2FuJ3QgdXNlIENvbnRlbnQtSUQgYXMgYSBTSVAgaGVhZGVyIGZpZWxk IChhbmQgZWxpZGUgdGhlIG11bHRpcGFydCB0b3AtPmxldmVsIHR5cGUpIGV4Y2VwdCB3aXRoIHRo b3NlIG1lY2hhbmlzbXMgdGhhdCBoYXZlIGV4cGxpY2l0bHkgIm9wdGVkIGluIiAtLSB3aGljaCBp cyB0byBzYXksIHRoZSBjb3JyZXNwb25kaW5nIHByb3RvY29sIGRvY3VtZW50IG5lZWRzIHRvIGNv bnRhaW4gdGV4dCBzYXlpbmcgdGhhdCB0aGlzIGlzIGFuID5va2F5IHRoaW5nIHRvIGRvLiBFeGFt cGxlIDEsIGluIHBhcnRpY3VsYXIsIG5lZWRzIGEgY2xlYXIgZGlzY2xhaW1lciB0aGF0IHRoZSBk ZXNjcmliZWQgbWVjaGFuaXNtICpjYW5ub3QqIGJlIHVzZWQgd2l0aCB0aGlzIGV4YW1wbGUgdW5s ZXNzIGFuZCB1bnRpbCBSRkM2NDQyIGlzIHVwZGF0ZWQuDQo+IFdoYXQgYWJvdXQgdGhlIGZvbGxv d2luZyBuZXcgc2VjdGlvbjoNCj4NCj4gICAgICAgIDxzZWN0aW9uIHRpdGxlPSJCYWNrd2FyZCBj b21wYXRpYmlsaXR5IiB0b2M9ImRlZmF1bHQiPg0KPiAgICAgICAgICA8dD4NCj4gICAgICAgICAg ICBUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgdXBkYXRlIGFueSBvZiB0aGUgY3VycmVudCBz cGVjaWZpY2F0aW9ucyBkZWZpbmluZyB1c2FnZSBvZiBDb250ZW50LUlEDQo+ICAgICAgICAgICAg VVJMcyBmb3IgcmVmZXJlbmNpbmcgYm9keSBwYXJ0cywgYW5kIGltcGxlbWVudGF0aW9ucyBvZiBz dWNoIHNwZWNpZmljYXRpb25zIE1VU1QgTk9UIGJlIG1vZGlmaWVkIGluDQo+ICAgICAgICAgICAg YSBiYWNrd2FyZCBpbmNvbXBhdGlibGUgd2F5IChldmVuIGlmIHRoZSBwdWJsaWNhdGlvbiBvZiB0 aGlzIHNwZWNpZmljYXRpb24gd291bGQgYWxsb3cgc3VjaCBjaGFuZ2UpLA0KPiAgICAgICAgICAg IHVubGVzcyB0aGVyZSBpcyBhIG1lY2hhbmlzbSB0byBlbnN1cmUgdGhhdCB0aGUgZW5kcG9pbnRz IHN1cHBvcnQgc3VjaCBtb2RpZmljYXRpb24uDQo+ICAgICAgICAgIDwvdD4NCj4gICAgICAgIDwv c2VjdGlvbj4NCg0KVGhhdCBsb29rcyBnb29kLCB3aXRoIHR3byBtaW5vciBhZGp1c3RtZW50cy4N Cg0KMS4gIkV4Y2VwdCBhcyBub3RlZCBpbiBzZWN0aW9uIDx4PiwgdGhpcyBzcGVjaWZpY2F0aW9u IGRvZXMgbm90IHVwZGF0ZS4uLiIgd2hlcmUgInNlY3Rpb24gPHg+IiByZWZlcnMgdG8gdGhlIHVw ZGF0ZXMgeW91IHByb3Bvc2UgYmVsb3cuDQoNCjIuIEluIHNlY3Rpb24gMS40LjEsIGFkZCBhICJO b3RlIHRoYXQgdGhpcyBleGFtcGxlIGNhbm5vdCBiZSB1c2VkIHdpdGggdGhlIG1lY2hhbmlzbSBk ZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCB1bmxlc3MgYW5kIHVudGlsIFtSRkM2NDQyXSBpcyB1 cGRhdGVkOyBzZWUgc2VjdGlvbiA8QmFja3dhcmRzIGNvbXBhdGliaWxpdHk+IGZvciBkZXRhaWxz LiINCg0KPj4+IFRoZSBkcmFmdCBhbGxvd3MgYW55IG5ldyB1c2FnZXMgbm90IGhhdmluZyB0byB1 c2UgbXVsdGlwYXJ0IChpZiANCj4+PiB0aGVyZSBpcyBvbmx5IG9uZSBib2R5IHBhcnQpLCBhbmQg KGFzIHBvaW50ZWQgb3V0IGJ5IEFkYW0pIG1ha2VzIA0KPj4+IGV4aXN0aW5nIHVzYWdlcyAoUkZD IDUzNjggYW5kIDYwODApIG9mIENvbnRlbnQtSUQgYXMgYSBTSVAgaGVhZGVyIGZpZWxkIHN0YW5k YXJkcyBjb21wbGlhbnQuDQo+PiBJJ2xsIG5vdGUgdGhhdCB0aGVzZSB0d28gZG9jdW1lbnRzIGRp ZG4ndCBleHBsaWNpdGx5IHNheSB0aGF0IHRoZXkgDQo+PiBjb3VsZCB1c2UgQ29udGVudC1JRCBh cyBhIFNJUCBoZWFkZXIgZmllbGQ7IHRoZXkgb25seSBzaG93ZWQgZG9pbmcgc28gDQo+PiBpbiBl eGFtcGxlcy4gRm9yIHRoZSBzYWtlIG9mIG5vcm1hdGl2ZSB0aWRpbmVzcywgSSB3b3VsZCBzdWdn ZXN0IHRoYXQgDQo+PiBzaXBjb3JlLWNvbnRlbnQtaWQgc3BlY2lmaWNhbGx5IHVwZGF0ZSB0aGVz ZSB0d28gUkZDcywgYW5kIGhhdmUgdGV4dCB0aGF0IGV4cGxpY2l0bHkgYW5kIG5vcm1hdGl2ZWx5 IGFsbG93cyB0aGUgdXNlIG9mIG5vbi1tdWx0aXBhcnQgdG9wLWxldmVsIGNvbnRlbnQgdHlwZXMg Zm9yIG11bHRpcGxlLXRhcmdldCBSRUZFUiByZXF1ZXN0cyBhbmQgZm9yIGRldmljZSBwcm9maWxl IE5PVElGWSBtZXNzYWdlcy4NCj4gV2UgY291bGQgdXBkYXRlIFJGQyA1MzY4IGJ5IHVwZGF0aW5n IHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24gNzoNCj4NCj4gT0xEOg0KPg0KPiAgICAg IlRoZSBSZWZlci1UbyBoZWFkZXIgZmllbGQgb2YgYSBSRUZFUiByZXF1ZXN0IHdpdGggbXVsdGlw bGUgUkVGRVItDQo+ICAgICBUYXJnZXRzIE1VU1QgY29udGFpbiBhIHBvaW50ZXIgKGkuZS4sIGEg Q29udGVudC1JRCBVbmlmb3JtIFJlc291cmNlDQo+ICAgICBMb2NhdG9yIChVUkwpIGFzIHBlciBS RkMgMjM5MiBbUkZDMjM5Ml0pIHRoYXQgcG9pbnRzIHRvIHRoZSBib2R5IHBhcnQNCj4gICAgIHRo YXQgY2FycmllcyB0aGUgVVJJIGxpc3QuICBUaGUgUkVGRVItSXNzdWVyIFNIT1VMRCBOT1QgaW5j bHVkZSBhbnkNCj4gICAgIHBhcnRpY3VsYXIgVVJJIG1vcmUgdGhhbiBvbmNlIGluIHRoZSBVUkkg bGlzdC4iDQo+DQo+IE5FVzoNCj4NCj4gICAgICJUaGUgUmVmZXItVG8gaGVhZGVyIGZpZWxkIG9m IGEgUkVGRVIgcmVxdWVzdCB3aXRoIG11bHRpcGxlIFJFRkVSLQ0KPiAgICAgVGFyZ2V0cyBNVVNU IGNvbnRhaW4gYSBwb2ludGVyIChpLmUuLCBhIENvbnRlbnQtSUQgVW5pZm9ybSBSZXNvdXJjZQ0K PiAgICAgTG9jYXRvciAoVVJMKSBhcyBwZXIgUkZDIDIzOTIgW1JGQzIzOTJdKSB0aGF0IHBvaW50 cyB0byB0aGUgYm9keSBwYXJ0DQo+ICAgICB0aGF0IGNhcnJpZXMgdGhlIFVSSSBsaXN0LiAgVGhl IFJFRkVSLUlzc3VlciBTSE9VTEQgTk9UIGluY2x1ZGUgYW55DQo+ICAgICBwYXJ0aWN1bGFyIFVS SSBtb3JlIHRoYW4gb25jZSBpbiB0aGUgVVJJIGxpc3QuIFRoZSBSRUZFUg0KPiAgICAgcmVxdWVz dCBjYW4gY29udGFpbiBhIFNJUCBDb250ZW50LUlEIGhlYWRlciBmaWVsZCByZWZlcmVuY2luZyB0 aGUNCj4gICAgIG1lc3NhZ2UtYm9keS4iDQoNCkknZCBtYWtlIGl0IGEgbm9ybWF0aXZlICIuLi5y ZXF1ZXN0IE1BWSBjb250YWluLi4uIiwgYnV0IGFzaWRlIGZyb20gdGhhdCwgaXQgbG9va3MgZmlu ZS4NCg0KPg0KPiBXZSBjb3VsZCB1cGRhdGUgUkZDIDYwODAgYnkgYWRkaW5nIHRoZSBmb2xsb3dp bmcgbmV3IHBhcmFncmFwaCB0byBzZWN0aW9uIDYuNToNCj4NCj4gTkVXOg0KPg0KPiAgICAgIlRo ZSBOT1RJRlkgcmVxdWVzdCBjYW4gY29udGFpbiBhIFNJUCBDb250ZW50LUlEIGhlYWRlciBmaWVs ZCByZWZlcmVuY2luZyB0aGUNCj4gICAgIG1lc3NhZ2UtYm9keS4iDQoNClNhbWUgY29tbWVudCBy ZWdhcmRpbmcgIk1BWSwiIGJ1dCB0aGF0IGxvb2tzIGZpbmUuDQoNCj4NCj4gSW4gYWRkaXRpb24s IEkgc3VnZ2VzdCBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggdG8gdGhlICdQcm9ibGVt IHN0YXRlbWVudCcgc2VjdGlvbjoNCj4NCj4gICAgICAgICAgPHQ+DQo+ICAgICAgICAgICAgPHhy ZWYgdGFyZ2V0PSJSRkM1MzY4IiBwYWdlbm89ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiLz4gYW5k IDx4cmVmIHRhcmdldD0iUkZDNjA4MCINCj4gICAgICAgICAgICBwYWdlbm89ImZhbHNlIiBmb3Jt YXQ9ImRlZmF1bHQiLz4gY29udGFpbiBleGFtcGxlcyB0aGF0IHNob3cgdXNhZ2Ugb2YgYSBTSVAg Q29udGVudC1JRA0KPiAgICAgICAgICAgIGhlYWRlciBmaWVsZCByZWZlcmVuY2luZyBhIGNvbXBs ZXRlIG1lc3NhZ2UtYm9keSwgZXZlbnRob3VnaCBzdWNoIHVzYWdlIGhhZCBub3QgYmVlbg0KPiAg ICAgICAgICAgIHNwZWNpZmllZCB3aGVuIHRob3NlIFJGQ3Mgd2VyZSBwdWJsaXNoZWQuDQo+ICAg ICAgICAgIDwvdD4NCj4NCj4gLi4uYW5kIHRvIGFkZCB0aGUgZm9sbG93aW5nIGJ1bGxldCB0byB0 aGUgJ1NvbHV0aW9uJyBzZWN0aW9uOg0KPg0KPiAgICAgICAgICAgICAgICA8dD4NCj4gICAgICAg ICAgICAgICAgICAgICAgVXBkYXRlcyA8eHJlZiB0YXJnZXQ9IlJGQzUzNjgiIHBhZ2Vubz0iZmFs c2UiIGZvcm1hdD0iZGVmYXVsdCIvPiBhbmQgPHhyZWYgdGFyZ2V0PSJSRkM2MDgwIg0KPiAgICAg ICAgICAgICAgICAgICAgICBwYWdlbm89ImZhbHNlIiBmb3JtYXQ9ImRlZmF1bHQiLz4gYnkgYWRk aW5nIGV4cGxpY2l0IHRleHQgc2F5aW5nIHRoYXQgYSBTSVAgQ29udGVudC1JRCBoZWFkZXINCj4g ICAgICAgICAgICAgICAgICAgICAgZmllbGQgY2FuIGJlIHVzZWQuDQo+ICAgICAgICAgICAgICAg IDwvdD4NCj4NCg0KVGhhdCBsb29rcyByZWFzb25hYmxlOyBidXQgZG8gbm90ZSB0aGF0IFJGQzUz NjggYW5kIFJGQzYwODAgbmVlZCB0byBhcHBlYXIgaW4gdGhlIGRvY3VtZW50IG1ldGFkYXRhIChh cyAiVXBkYXRlcyIpLCBhbmQgdGhleSBuZWVkIHRvIGJlIG1lbnRpb25lZCBpbiB0aGUgQWJzdHJh Y3QgKCJUaGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDIDUzNjggYW5kIFJGQyA2MDgwIHRvIGNsYXJp ZnkgdGhlaXIgdXNlIG9mIENvbnRlbnQtSUQuIikNCg0KL2ENCg== From nobody Fri Jul 7 14:03:00 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E9713154F; Fri, 7 Jul 2017 14:02:52 -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 zxlJb9LRK5vv; Fri, 7 Jul 2017 14:02:50 -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 BF62212EC19; Fri, 7 Jul 2017 14:02:49 -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 v67L2hAJ076178 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 7 Jul 2017 16:02:44 -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] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CC55723@ESESSMB109.ericsson.se> Date: Fri, 7 Jul 2017 16:02:42 -0500 Cc: Adam Roach , Eric Rescorla , The IESG , "sipcore@ietf.org" , "draft-ietf-sipcore-content-id@ietf.org" , "A. Jean Mahoney" , "sipcore-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8DE41F5F-73B0-4E88-8A1D-0CB7BEA5E9A7@nostrum.com> References: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CC50BB3@ESESSMB109.ericsson.se> <4c10a5e5-e2e0-a8bd-c038-2f2ef342daeb@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CC53AE4@ESESSMB109.ericsson.se> <4421323a-7bc8-d8af-7072-8ec3ca438f0b@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CC55723@ESESSMB109.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and 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, 07 Jul 2017 21:02:52 -0000 > On Jul 7, 2017, at 2:39 PM, Christer Holmberg = wrote: >=20 > Hi, >=20 > One thing that I forgot earlier: >=20 > Unlike the other RFCs defining Content-ID usages, RFC 6442 actually = doesn't contain examples with a single body part - all examples contain = multipart bodies with two body parts: SDP and location. >=20 > So, the question is what an implementation would do if it ONLY sends = location? Would it use a SIP Content-ID header field, or will it use a = multipart body with a single body part?=20 >=20 > So, since we WILL allow SIP Content-ID header field (with a = non-multipart body) for RFC 5638 and RFC 6080, shouldn't we do it also = for RFC 6442? I personally think it would be safe to do so, because the = only case where it could cause problem is if someone ONLY sends location = (i.e., no SDP or any other body part), and does not use multipart. > =20 In general, we should minimize material changes post last-call and IESG = evaluation. That doesn=E2=80=99t mean we can=E2=80=99t do it, just that = we need good reason. In this case, how likely are we to see location = sent without sdp in real life? Do people expect situations where a = sender sends the SIP header field but the receiver only knows about the = MIME header? (That is, does this fall into the interop issue already = discussed?) Otherwise, this seems reasonable, perhaps with something to the effect = of =E2=80=9CWhen sending location with no other body parts=E2=80=A6=E2=80=9D= added. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 06 July 2017 23:24 > To: Christer Holmberg ; Eric Rescorla = ; The IESG > Cc: sipcore@ietf.org; draft-ietf-sipcore-content-id@ietf.org; = mahoney@nostrum.com; sipcore-chairs@ietf.org > Subject: Re: Eric Rescorla's Discuss on = draft-ietf-sipcore-content-id-07: (with DISCUSS and COMMENT) >=20 > On 7/6/17 12:45, Christer Holmberg wrote: >> Hi, >>=20 >>>> Note that the draft does not update the existing multipart usages = (RFC 5368 and 6442). So, the draft does not cause any backward = compatibility issues. >>>>=20 >>>> (Now, IF people want to change existing multipart usages, I agree=20= >>>> there needs to be a mechanism to ensure that the endpoints=20 >>>> understand it. We can add some text about that. I think that is = also=20 >>>> what Paul >>>> indicated.) >>> Right. I think this document really needs to contain text that = normatively says that implementations can't use Content-ID as a SIP = header field (and elide the multipart top->level type) except with those = mechanisms that have explicitly "opted in" -- which is to say, the = corresponding protocol document needs to contain text saying that this = is an >okay thing to do. Example 1, in particular, needs a clear = disclaimer that the described mechanism *cannot* be used with this = example unless and until RFC6442 is updated. >> What about the following new section: >>=20 >>
>> >> This specification does not update any of the current = specifications defining usage of Content-ID >> URLs for referencing body parts, and implementations of = such specifications MUST NOT be modified in >> a backward incompatible way (even if the publication of = this specification would allow such change), >> unless there is a mechanism to ensure that the endpoints = support such modification. >> >>
>=20 > That looks good, with two minor adjustments. >=20 > 1. "Except as noted in section , this specification does not = update..." where "section " refers to the updates you propose below. >=20 > 2. In section 1.4.1, add a "Note that this example cannot be used with = the mechanism described in this document unless and until [RFC6442] is = updated; see section for details." >=20 >>>> The draft allows any new usages not having to use multipart (if=20 >>>> there is only one body part), and (as pointed out by Adam) makes=20 >>>> existing usages (RFC 5368 and 6080) of Content-ID as a SIP header = field standards compliant. >>> I'll note that these two documents didn't explicitly say that they=20= >>> could use Content-ID as a SIP header field; they only showed doing = so=20 >>> in examples. For the sake of normative tidiness, I would suggest = that=20 >>> sipcore-content-id specifically update these two RFCs, and have text = that explicitly and normatively allows the use of non-multipart = top-level content types for multiple-target REFER requests and for = device profile NOTIFY messages. >> We could update RFC 5368 by updating the second paragraph of section = 7: >>=20 >> OLD: >>=20 >> "The Refer-To header field of a REFER request with multiple REFER- >> Targets MUST contain a pointer (i.e., a Content-ID Uniform = Resource >> Locator (URL) as per RFC 2392 [RFC2392]) that points to the body = part >> that carries the URI list. The REFER-Issuer SHOULD NOT include = any >> particular URI more than once in the URI list." >>=20 >> NEW: >>=20 >> "The Refer-To header field of a REFER request with multiple REFER- >> Targets MUST contain a pointer (i.e., a Content-ID Uniform = Resource >> Locator (URL) as per RFC 2392 [RFC2392]) that points to the body = part >> that carries the URI list. The REFER-Issuer SHOULD NOT include = any >> particular URI more than once in the URI list. The REFER >> request can contain a SIP Content-ID header field referencing the >> message-body." >=20 > I'd make it a normative "...request MAY contain...", but aside from = that, it looks fine. >=20 >>=20 >> We could update RFC 6080 by adding the following new paragraph to = section 6.5: >>=20 >> NEW: >>=20 >> "The NOTIFY request can contain a SIP Content-ID header field = referencing the >> message-body." >=20 > Same comment regarding "MAY," but that looks fine. >=20 >>=20 >> In addition, I suggest adding the following paragraph to the 'Problem = statement' section: >>=20 >> >> and > pageno=3D"false" format=3D"default"/> contain examples that = show usage of a SIP Content-ID >> header field referencing a complete message-body, = eventhough such usage had not been >> specified when those RFCs were published. >> >>=20 >> ...and to add the following bullet to the 'Solution' section: >>=20 >> >> Updates and > pageno=3D"false" format=3D"default"/> by adding = explicit text saying that a SIP Content-ID header >> field can be used. >> >>=20 >=20 > That looks reasonable; but do note that RFC5368 and RFC6080 need to = appear in the document metadata (as "Updates"), and they need to be = mentioned in the Abstract ("This document updates RFC 5368 and RFC 6080 = to clarify their use of Content-ID.") >=20 > /a From nobody Mon Jul 10 03:59: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 F3B1C1286B2; Mon, 10 Jul 2017 03:59:25 -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 z-9ZRN4qPxHd; Mon, 10 Jul 2017 03:59:23 -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 C4550128AB0; Mon, 10 Jul 2017 03:59:22 -0700 (PDT) X-AuditID: c1b4fb3a-bea2a9c000001b2f-ec-59635e086571 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CE.70.06959.80E53695; Mon, 10 Jul 2017 12:59:20 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Mon, 10 Jul 2017 12:59:20 +0200 From: Christer Holmberg To: Ben Campbell CC: Adam Roach , Eric Rescorla , The IESG , "sipcore@ietf.org" , "draft-ietf-sipcore-content-id@ietf.org" , "A. Jean Mahoney" , "sipcore-chairs@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and COMMENT) Thread-Index: AQHS9YeSl7jlBr6gNkqjMJoiy+ImKKJFklVAgAE3rgCAAD3L8IAAJ+WAgAGSW8D///obAIAEQPGA Date: Mon, 10 Jul 2017 10:59:19 +0000 Message-ID: References: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CC50BB3@ESESSMB109.ericsson.se> <4c10a5e5-e2e0-a8bd-c038-2f2ef342daeb@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CC53AE4@ESESSMB109.ericsson.se> <4421323a-7bc8-d8af-7072-8ec3ca438f0b@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CC55723@ESESSMB109.ericsson.se> <8DE41F5F-73B0-4E88-8A1D-0CB7BEA5E9A7@nostrum.com> In-Reply-To: <8DE41F5F-73B0-4E88-8A1D-0CB7BEA5E9A7@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUyM2K7pS5HXHKkQeNqLYs9fxexW8zvPM1u cfrrDCaLFa/PsVvM+DOR2aKhcyWrRe/nhcwWX39sYnPg8Fiy5CeTx6ydT1g8Jj9uYw5gjuKy SUnNySxLLdK3S+DKaP2/nL3gpU3F8mtT2RsYlxp0MXJySAiYSHz+M5MNxBYSOMIosW9DeBcj F5C9mFHiza7T7F2MHBxsAhYS3f+0QWpEBJQknjdvZQGxmQV2Mkks75ADsYUF0iQe/N/LDlGT LnHz8DoWCDtK4svTG2DzWQRUJQ4u3w0W5xWwlpj0Yh4zxN4dzBJ7lrqB2JwC9hLfNr8Hq2EU EJP4fmoNE8QucYlbT+YzQdwsILFkz3lmCFtU4uXjf6wgZ4oK6Em82+8JYkoIKEos75eD6DSQ eH9uPjOEbS2x7E4vO4StLbFs4WtmiGsEJU7OfMIygVF8FpJls5C0z0LSPgtJ+ywk7QsYWVcx ihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBMbrwS2/rXYwHnzueIhRgINRiYf3oUVypBBrYllx Ze4hRgkOZiUR3t1hQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8DvsuRAgJpCeWpGanphakFsFk mTg4pRoYZ0gY5obrPdc9cd42YWNNwiLHifYVHJ9OiP6a7HiirlVcKtmL9Vip5M8rnEkRhaWb DfO0sr/Xclvt/CN3akbom3zN6IkvHKOWru9e3tm43F2mNpXlTva8T1Enjm2+9iZpzXnhDUsv z1DnDT6zUidOysPpyJ/LrT+0N0qz1c3Q+bhz8q6J/G3+SizFGYmGWsxFxYkA0OvqBNMCAAA= Archived-At: Subject: Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and 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, 10 Jul 2017 10:59:26 -0000 Hi, >>One thing that I forgot earlier: >>=20 >> Unlike the other RFCs defining Content-ID usages, RFC 6442 actually >>doesn't contain examples with a single body part - all examples contain >>multipart bodies with two body parts: SDP and location. >>=20 >> So, the question is what an implementation would do if it ONLY sends >>location? Would it use a SIP Content-ID header field, or will it use a >>multipart body with a single body part? >>=20 >> So, since we WILL allow SIP Content-ID header field (with a >>non-multipart body) for RFC 5638 and RFC 6080, shouldn't we do it also >>for RFC 6442? I personally think it would be safe to do so, because the >>only case where it could cause problem is if someone ONLY sends location >>(i.e., no SDP or any other body part), and does not use multipart. >> =20 > >In general, we should minimize material changes post last-call and IESG >evaluation. That doesn=B9t mean we can=B9t do it, just that we need good >reason.=20 Actually, I don=B9t think it would be a change to the current version, because it doesn=B9t say anything about backward compatibility: it simply says that one can now use Content-ID as a SIP header field :) >In this case, how likely are we to see location sent without sdp in real >life? > Do people expect situations where a sender sends the SIP header field >but the receiver only knows about the MIME header? (That is, does this >fall into the interop issue already discussed?) I would say that currently it is very unlikely - which is the reason I think we could allow a non-multipart message body without causing any backward compatibility issues. >Otherwise, this seems reasonable, perhaps with something to the effect of >=B3When sending location with no other body parts=8A=B2 added. Yes. Regards, Christer >>-----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: 06 July 2017 23:24 >> To: Christer Holmberg ; Eric Rescorla >>; The IESG >> Cc: sipcore@ietf.org; draft-ietf-sipcore-content-id@ietf.org; >>mahoney@nostrum.com; sipcore-chairs@ietf.org >> Subject: Re: Eric Rescorla's Discuss on >>draft-ietf-sipcore-content-id-07: (with DISCUSS and COMMENT) >>=20 >> On 7/6/17 12:45, Christer Holmberg wrote: >>> Hi, >>>=20 >>>>> Note that the draft does not update the existing multipart usages >>>>>(RFC 5368 and 6442). So, the draft does not cause any backward >>>>>compatibility issues. >>>>>=20 >>>>> (Now, IF people want to change existing multipart usages, I agree >>>>> there needs to be a mechanism to ensure that the endpoints >>>>> understand it. We can add some text about that. I think that is also >>>>> what Paul >>>>> indicated.) >>>> Right. I think this document really needs to contain text that >>>>normatively says that implementations can't use Content-ID as a SIP >>>>header field (and elide the multipart top->level type) except with >>>>those mechanisms that have explicitly "opted in" -- which is to say, >>>>the corresponding protocol document needs to contain text saying that >>>>this is an >okay thing to do. Example 1, in particular, needs a clear >>>>disclaimer that the described mechanism *cannot* be used with this >>>>example unless and until RFC6442 is updated. >>> What about the following new section: >>>=20 >>>
>>> >>> This specification does not update any of the current >>>specifications defining usage of Content-ID >>> URLs for referencing body parts, and implementations of such >>>specifications MUST NOT be modified in >>> a backward incompatible way (even if the publication of this >>>specification would allow such change), >>> unless there is a mechanism to ensure that the endpoints >>>support such modification. >>> >>>
>>=20 >> That looks good, with two minor adjustments. >>=20 >> 1. "Except as noted in section , this specification does not >>update..." where "section " refers to the updates you propose below. >>=20 >> 2. In section 1.4.1, add a "Note that this example cannot be used with >>the mechanism described in this document unless and until [RFC6442] is >>updated; see section for details." >>=20 >>>>> The draft allows any new usages not having to use multipart (if >>>>> there is only one body part), and (as pointed out by Adam) makes >>>>> existing usages (RFC 5368 and 6080) of Content-ID as a SIP header >>>>>field standards compliant. >>>> I'll note that these two documents didn't explicitly say that they >>>> could use Content-ID as a SIP header field; they only showed doing so >>>> in examples. For the sake of normative tidiness, I would suggest that >>>> sipcore-content-id specifically update these two RFCs, and have text >>>>that explicitly and normatively allows the use of non-multipart >>>>top-level content types for multiple-target REFER requests and for >>>>device profile NOTIFY messages. >>> We could update RFC 5368 by updating the second paragraph of section 7: >>>=20 >>> OLD: >>>=20 >>> "The Refer-To header field of a REFER request with multiple REFER- >>> Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource >>> Locator (URL) as per RFC 2392 [RFC2392]) that points to the body >>>part >>> that carries the URI list. The REFER-Issuer SHOULD NOT include any >>> particular URI more than once in the URI list." >>>=20 >>> NEW: >>>=20 >>> "The Refer-To header field of a REFER request with multiple REFER- >>> Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource >>> Locator (URL) as per RFC 2392 [RFC2392]) that points to the body >>>part >>> that carries the URI list. The REFER-Issuer SHOULD NOT include any >>> particular URI more than once in the URI list. The REFER >>> request can contain a SIP Content-ID header field referencing the >>> message-body." >>=20 >> I'd make it a normative "...request MAY contain...", but aside from >>that, it looks fine. >>=20 >>>=20 >>> We could update RFC 6080 by adding the following new paragraph to >>>section 6.5: >>>=20 >>> NEW: >>>=20 >>> "The NOTIFY request can contain a SIP Content-ID header field >>>referencing the >>> message-body." >>=20 >> Same comment regarding "MAY," but that looks fine. >>=20 >>>=20 >>> In addition, I suggest adding the following paragraph to the 'Problem >>>statement' section: >>>=20 >>> >>> and >>>>> pageno=3D"false" format=3D"default"/> contain examples that s= how >>>usage of a SIP Content-ID >>> header field referencing a complete message-body, eventhough >>>such usage had not been >>> specified when those RFCs were published. >>> >>>=20 >>> ...and to add the following bullet to the 'Solution' section: >>>=20 >>> >>> Updates >>format=3D"default"/> and >> pageno=3D"false" format=3D"default"/> by adding >>>explicit text saying that a SIP Content-ID header >>> field can be used. >>> >>>=20 >>=20 >> That looks reasonable; but do note that RFC5368 and RFC6080 need to >>appear in the document metadata (as "Updates"), and they need to be >>mentioned in the Abstract ("This document updates RFC 5368 and RFC 6080 >>to clarify their use of Content-ID.") >>=20 >> /a > From nobody Mon Jul 10 07:41: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 23FD2128B8F; Mon, 10 Jul 2017 07:41:38 -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 BsGwN1JqKvDJ; Mon, 10 Jul 2017 07:41:36 -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 7247A1317AE; Mon, 10 Jul 2017 07:41:34 -0700 (PDT) X-AuditID: c1b4fb3a-81bff70000001b2f-3c-5963921cfd48 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BD.82.06959.C1293695; Mon, 10 Jul 2017 16:41:32 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Mon, 10 Jul 2017 16:41:32 +0200 From: Christer Holmberg To: Ben Campbell CC: Adam Roach , Eric Rescorla , The IESG , "sipcore@ietf.org" , "draft-ietf-sipcore-content-id@ietf.org" , "A. Jean Mahoney" , "sipcore-chairs@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and COMMENT) Thread-Index: AQHS9YeSl7jlBr6gNkqjMJoiy+ImKKJFklVAgAE3rgCAAD3L8IAAKxmAgAYISQA= Date: Mon, 10 Jul 2017 14:41:31 +0000 Message-ID: References: <149925657551.15707.3307954601377299824.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CC50BB3@ESESSMB109.ericsson.se> <4c10a5e5-e2e0-a8bd-c038-2f2ef342daeb@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CC53AE4@ESESSMB109.ericsson.se> <46C1E67C-03F8-4A79-9597-E3996B531B95@nostrum.com> In-Reply-To: <46C1E67C-03F8-4A79-9597-E3996B531B95@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <381F7A160865544B919DC7909B60D802@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUyM2K7iq7MpORIg6Vz9Sz2/F3EbjG/8zS7 xemvM5gsVrw+x24x489EZouGzpWsFr2fFzJbfP2xic2Bw2PJkp9MHrN2PmHxmPy4jTmAOYrL JiU1J7MstUjfLoErY9LGKUwFv0wr3r88wdzA+E2zi5GTQ0LAROLF8XPsILaQwBFGicVTjLoY uYDsxYwSOy98Z+pi5OBgE7CQ6P6nDVIjIqAk8bx5KwuIzSywk0lieYcciC0skCbx4P9edoia dImbh9exQNh+EktaFzOB2CwCqhK9p5azgdi8AtYSd1vusEHs3c8k8et/BMgqTgF7idmf9UHC jAJiEt9PrWGCWCUucevJfCaIkwUkluw5zwxhi0q8fPyPFaRVVEBP4t1+TxBTAujKaVvTIDr1 JG5MncIGYVtLfP/+GmqitsSyha+ZIY4RlDg58wnLBEbxWUiWzULSPgtJ+ywk7bOQtC9gZF3F KFqcWlycm25kpJdalJlcXJyfp5eXWrKJERitB7f8ttrBePC54yFGAQ5GJR7ehxbJkUKsiWXF lbmHGCU4mJVEeN/3A4V4UxIrq1KL8uOLSnNSiw8xSnOwKInzOuy7ECEkkJ5YkpqdmlqQWgST ZeLglGpgrLlb+UpR02zj6XWsLedWu/z6dWBe+Nd5j5fMnmi2/Fj0jtUrUubVT3Xexe2wq7vg 466TB6doTGIWub1GrT3NdfXt6Hcmrffr1rc2ygbrz0n/ZzA1772jUm2G5PLavQtEWysybYwP pHX0bFmwzM3rbfZc9R1nFp70bP76T+JpgNZbx/fb54a36SmxFGckGmoxFxUnAgBuEQfk0gIA AA== Archived-At: Subject: Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and 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, 10 Jul 2017 14:41:38 -0000 Hi, ... >> On Jul 6, 2017, at 12:45 PM, Christer Holmberg >> wrote: >>=20 >> Hi, >>=20 >>>> Note that the draft does not update the existing multipart usages >>>>(RFC 5368 and 6442). So, the draft does not cause any backward >>>>compatibility issues. >>>>=20 >>>> (Now, IF people want to change existing multipart usages, I agree >>>> there needs to be a mechanism to ensure that the endpoints understand >>>> it. We can add some text about that. I think that is also what Paul >>>> indicated.) >>>=20 >>> Right. I think this document really needs to contain text that >>>normatively says that implementations can't use Content-ID as a SIP >>>header field (and elide the multipart top->level type) except with >>>those mechanisms that have explicitly "opted in" -- which is to say, >>>the corresponding protocol document needs to contain text saying that >>>this is an >okay thing to do. Example 1, in particular, needs a clear >>>disclaimer that the described mechanism *cannot* be used with this >>>example unless and until RFC6442 is updated. >>=20 >> What about the following new section: >>=20 >>
>> >> This specification does not update any of the current >>specifications defining usage of Content-ID >> URLs for referencing body parts, and implementations of such >>specifications MUST NOT be modified in >> a backward incompatible way (even if the publication of this >>specification would allow such change), >> unless there is a mechanism to ensure that the endpoints >>support such modification. >> >>
> >Won=B9t the =B3does not update=B2 bit become untrue if we add the proposed >updates (below)? You are correct. Perhaps we instead could say: =B3If an existing specification explicitly defines the usage of a multipart message body for carrying a single body part, that specification MUST be updated in order to allow usage of a non-multipart message body for carrying the body part, and for referencing the whole message body using a Content-ID URL." ------- >>=20 >>>> The draft allows any new usages not having to use multipart (if there >>>>is only one body part), >>>> and (as pointed out by Adam) makes existing usages (RFC 5368 and >>>>6080) of Content-ID as a >>>> SIP header field standards compliant. >>>=20 >>> I'll note that these two documents didn't explicitly say that they >>>could use Content-ID as a SIP header field; they only showed >>> doing so in examples. For the sake of normative tidiness, I would >>>suggest that sipcore-content-id specifically update these two >>> RFCs, and have text that explicitly and normatively allows the use of >>>non-multipart top-level content types for multiple-target >>> REFER requests and for device profile NOTIFY messages. >>=20 >> We could update RFC 5368 by updating the second paragraph of section 7: >>=20 >> OLD: >>=20 >> "The Refer-To header field of a REFER request with multiple REFER- >> Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource >> Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part >> that carries the URI list. The REFER-Issuer SHOULD NOT include any >> particular URI more than once in the URI list." >>=20 >> NEW: >>=20 >> "The Refer-To header field of a REFER request with multiple REFER- >> Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource >> Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part >> that carries the URI list. The REFER-Issuer SHOULD NOT include any >> particular URI more than once in the URI list. The REFER >> request can contain a SIP Content-ID header field referencing the >> message-body.=B2 >>=20 > >I=B9m not sure I agree there=B9s a need to update 5386, since as far as I = can >find, it doesn=B9t have text that says anything about how the content-ID i= s >labeled other than in the example. Based on the new suggested text above, I agree that there would be no need. But, I have no strong opinion. >But I don=B9t object if other=B9s feel strongly. If w do update it, I sugg= est >the following variation (or something to it=B9s effect): > >NEW: > "The Refer-To header field of a REFER request with multiple REFER- > Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource > Locator (URL) as per RFC 2392 [RFC2392]) that points to the message >body=20 > or body part that carries the URI list. The REFER-Issuer SHOULD NOT > include any particular URI more than once in the URI list. The REFER > request can use either a MIME Content-ID header field [RFC4483 ] or a > SIP Content-ID header field [RFCTHIS] to label the message-body.=B2 s/label the message-body/label the body-part --------- > >>=20 >> We could update RFC 6080 by adding the following new paragraph to >>section 6.5: >>=20 >> NEW: >>=20 >> "The NOTIFY request can contain a SIP Content-ID header field >>referencing the >> message-body.=B2 >>=20 > >I=B9m not sure that quite works, since there=B9s already text in 6.5 sayin= g >it MUST use the Content-ID MIME header field. > >How about this for the second sentence of the first paragraph: > >OLD: > For profile data delivered via content indirection, i.e., a pointer to >a PCC, then=20 > the Content-ID MIME header, as described in [RFC4483 ], MUST be used > for each profile document URI. >NEW > For profile data delivered via content indirection, i.e., a pointer to >a PCC, then=20 > either a Content-ID MIME header field [RFC4483 ] or the Content-ID SIP > header field [RFCTHIS] MUST be used for each profile document URI. Looks good. Regards, Christer > > > >>=20 >> In addition, I suggest adding the following paragraph to the 'Problem >>statement' section: >>=20 >> >> = and >>> pageno=3D"false" format=3D"default"/> contain examples that sho= w >>usage of a SIP Content-ID >> header field referencing a complete message-body, eventhough >>such usage had not been >> specified when those RFCs were published. >> >>=20 >> ...and to add the following bullet to the 'Solution' section: >>=20 >> >> Updates >format=3D"default"/> and > pageno=3D"false" format=3D"default"/> by adding expli= cit >>text saying that a SIP Content-ID header >> field can be used. >> >>=20 >>=20 >> Regards, >>=20 >> Christer > From nobody Thu Jul 13 17:28: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 9547F1317B6; Thu, 13 Jul 2017 17:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 X3z5VR9DIj7y; Thu, 13 Jul 2017 17:28:17 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08948126B72; Thu, 13 Jul 2017 17:28:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D4831B81081; Thu, 13 Jul 2017 17:28:07 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sipcore@ietf.org Message-Id: <20170714002807.D4831B81081@rfc-editor.org> Date: Thu, 13 Jul 2017 17:28:07 -0700 (PDT) Archived-At: Subject: [sipcore] RFC 8197 on A SIP Response Code for Unwanted Calls 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, 14 Jul 2017 00:28:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8197 Title: A SIP Response Code for Unwanted Calls Author: H. Schulzrinne Status: Standards Track Stream: IETF Date: March 2017 Mailbox: henning.schulzrinne@fcc.gov Pages: 8 Characters: 19114 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipcore-status-unwanted-06.txt URL: https://www.rfc-editor.org/info/rfc8197 DOI: 10.17487/RFC8197 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. This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Jul 18 12:47:39 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 8B3C31316E0; Tue, 18 Jul 2017 12:47:31 -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.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150040725154.11344.6357160284320942724@ietfa.amsl.com> Date: Tue, 18 Jul 2017 12:47:31 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-01.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, 18 Jul 2017 19:47:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core of the IETF. Title : SIP Call-Info Parameters for Labeling Calls Author : Henning Schulzrinne Filename : draft-ietf-sipcore-callinfo-spam-01.txt Pages : 9 Date : 2017-07-18 Abstract: Called parties often wish to decide whether to accept, reject or redirect calls based on the likely nature of the call. For example, they may want to reject unwanted telemarketing or fraudulent calls, but accept emergency alerts from numbers not in their address book. This document describes SIP Call-Info parameters and a feature tag that allow originating, intermediate and terminating SIP entities to label calls as to their type, spam probability and references to additional information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-callinfo-spam-01 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-callinfo-spam-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-callinfo-spam-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 18 12:50:42 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D287128961 for ; Tue, 18 Jul 2017 12:50:41 -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 HFCkIkCeT8Ox for ; Tue, 18 Jul 2017 12:50:38 -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 B856C124BE8 for ; Tue, 18 Jul 2017 12:50:38 -0700 (PDT) Received: from pps.filterd (m0102175.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6IJnOUI014138 for ; Tue, 18 Jul 2017 19:50:36 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 2bqavuj7e3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 18 Jul 2017 19:50:36 +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=r/s/2qyPTzx+MtXudRvd55c7qNz63Kv1uysgiZV45EA=; b=S9bP0PEHfD9qR4Kvf2sVfjc/i6l3DvNW5Flpr56TiMZPP0I1ZNsenjruf6rJ+Oe+OkcG0mY/ciQyqK1NRKlG5jsa98qVGLyvH74gdlQlPQxdgmgZ9YGj9KkIoehrRJAIeuIRN7c0NRHU9a2x2UqAG6ZpDuIM5ZzXOW20F8dAmeE= Received: from CY1PR09MB0760.namprd09.prod.outlook.com (10.161.173.151) by CY1PR09MB0760.namprd09.prod.outlook.com (10.161.173.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Tue, 18 Jul 2017 19:50:35 +0000 Received: from CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) by CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) with mapi id 15.01.1261.024; Tue, 18 Jul 2017 19:50:35 +0000 From: Henning Schulzrinne To: "sipcore@ietf.org" Thread-Topic: draft-ietf-sipcore-callinfo-spam-01 - SIP entities Thread-Index: AQHS//8f86lEHhh9VUKR5rSbwxo4zw== Date: Tue, 18 Jul 2017 19:50:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [128.59.13.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0760; 7:fZJhsikDr91WpeMq8TDBVemPcGhrTH6+6bwlFxasu3eqC5iKmyuDRdFkpYVjduxqIxMu7fp+70nwgNzhojulbZ7NrIhB44uWkrZD18qoqjvp8+A+EsCM4PfcuhZasSA7WR3Hc45oWnIrrX5vj9WgT5Wd4z9hFMwimWAdo5tLoRdng45Jx6DadfE+Qiq5OK+hWwWM7fgPrnte2x0U6plvVYDHtqU5D5jTKjC3BjySb8kveSx2YkIwQC6M/R/lbfyrTypx3sRUGhLjttjA2xCz8DRgMcnxsUJ4Pyd2+7dBQguFJLPPllSzpOkR5Qz6IcjRIVZ1DW3uf4xh6Mjj+Gyv5UlSgZCAi739jcFsyyAHkPQrSNKCGq9Rd7UX32Fm4CbIPVRlCVqc0bnH1OV8RjBDdgjogOuLwtn9vVjjyTRn0h/8yQid6bNMabks8Hiuu4Kpj5ntPDQ8dQKUsILcXeBAtmdJUGe0KecuOV1kj2Pd66yGpOKtYpxIGzQJVPhYpD+moXdJt3Yzur2b9mPf0UzsN2qmBfc5yLjirZaH01KpR1Vj6P2IgSmFVJUVs9405G0WqAmrmAExsVSOlURhp2/weg4ZO9FdmqBTUkVl238Ew/p9gSJODebgjtLm1Ucux/b3Bx6YEK9yXTEgDPPnqeLMb4ObXFRDaT6lrjDHlEsUv4KbuL9QY/FcC+GkeRrN0JqIIr0SkYG/C00WZwKbHRxRRuNWkiSsonkEpyjyYVRDsQhONpGNwyPtPZrirpphzgLgphTB3p2siFHY/GaN0y58dc0MpNS9I17WsAC6AKNBPjo= x-ms-office365-filtering-correlation-id: cbb09424-5af8-4f26-3271-08d4ce1641a8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR09MB0760; x-ms-traffictypediagnostic: CY1PR09MB0760: x-exchange-antispam-report-test: UriScan:(236129657087228)(131327999870524)(148574349560750); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR09MB0760; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR09MB0760; x-forefront-prvs: 037291602B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39450400003)(39850400002)(39410400002)(39840400002)(54356999)(606006)(230783001)(6506006)(50986999)(5640700003)(6116002)(53936002)(33656002)(189998001)(72206003)(77096006)(8936002)(102836003)(2906002)(7696004)(478600001)(19627405001)(3846002)(9686003)(3280700002)(81166006)(6916009)(8676002)(2900100001)(66066001)(6306002)(5660300001)(6436002)(14454004)(54896002)(2351001)(236005)(110136004)(86362001)(2501003)(25786009)(7736002)(74316002)(55016002)(1730700003)(38730400002)(6606003)(99286003)(3660700001)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0760; H:CY1PR09MB0760.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB07602078727954F586DCBDD3EAA10CY1PR09MB0760namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2017 19:50:35.1601 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0760 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 19:50:41 -0000 --_000_CY1PR09MB07602078727954F586DCBDD3EAA10CY1PR09MB0760namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm finally addressing Christer's helpful comments in https://www.ietf.org/mail-archive/web/sipcore/current/msg07851.html and have submitted a new draft. Christer noted that I used the term "SIP entities" several times. What I me= ant to say is "SIP proxies and B2BUAs that face the [end customer] user age= nt and are associated with a registrar" (as opposed to some random SBC in t= he core of the network). After all, only those elements should remove any u= ntrusted call-info information in this case. If there's a better way than t= he current short-hand "SIP proxy or B2BUA", I'll gladly take suggestions. I think I addressed all the comments pending, but if I missed anything, ple= ase remind me. Otherwise, this should be ready. Henning --_000_CY1PR09MB07602078727954F586DCBDD3EAA10CY1PR09MB0760namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I'm finally addressing Christer's helpful comments in


ht= tps://www.ietf.org/mail-archive/web/sipcore/current/msg07851.html


and have submitted a new draft.


Christer noted that I used the term "SIP entities" several tim= es. What I meant to say is "SIP proxies and B2BUAs that face the [end = customer] user agent and are associated with a registrar" (as opp= osed to some random SBC in the core of the network). After all, only those elements should remove any untrusted call-info information= in this case. If there's a better way than the current short-hand "SI= P proxy or B2BUA", I'll gladly take suggestions.


I think I addressed all the comments pending, but if I missed anything, = please remind me. Otherwise, this should be ready.


Henning


--_000_CY1PR09MB07602078727954F586DCBDD3EAA10CY1PR09MB0760namp_-- From nobody Wed Jul 19 01:34:48 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 EE0CA131C2C for ; Wed, 19 Jul 2017 01:34:46 -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 i33ZUQQBDORp for ; Wed, 19 Jul 2017 01:34:44 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791AC131C29 for ; Wed, 19 Jul 2017 01:34:44 -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=wUmZik0z2g5pRHIM7m2gvUHekvUOs4yINsM9Jjlfu38=; b=gWlbEDuXPOQhpqhkXbnfnI9fOifhyDvdP6z6hTTp5sK1TjsZxZPmnoBQmbhswGjk/HzLY+3342YtoTtzH+FrvuZ6V5nzTwRW9plqB6j+yhcAXEsByESOvuRt7fFz9e1fy9zkpSz+O2Brwr1epfaDx8VGIL5s9su//FQx8DzTvKA= Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0047.outbound.protection.outlook.com [207.46.163.47]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-107-WY-Rz4GGPb6MlbZHK-OReQ-1; Wed, 19 Jul 2017 04:34:40 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB046.namprd03.prod.outlook.com (10.255.175.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Wed, 19 Jul 2017 08:34:37 +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.1282.011; Wed, 19 Jul 2017 08:34:37 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , "sipcore@ietf.org" Thread-Topic: draft-ietf-sipcore-callinfo-spam-01 - SIP entities Thread-Index: AQHS//8f86lEHhh9VUKR5rSbwxo4z6Ja0ofA Date: Wed, 19 Jul 2017 08:34:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB046; 20:NQ7msmIX+mC7AZa5eRJpyQYD8Ux5VCWLkq3RoeQ15aF7QHN/kUOLYNNMviwEujkIhgckj/3wBQjAnxALIBWW/KPi73HRtpS4ECiBgQX3fScK+8qkpFomaJjWrsYz6LzHBD5BvSGxfMJ08qBJAv3StaLUF0vCcrXccJGKY1bS1GE= x-ms-office365-filtering-correlation-id: d5f91b23-31ea-4ef3-7596-08d4ce80fda6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR03MB046; x-ms-traffictypediagnostic: SN2PR03MB046: x-exchange-antispam-report-test: UriScan:(151999592597050)(133145235818549)(26388249023172)(236129657087228)(131327999870524)(148574349560750)(21748063052155)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB046; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB046; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39410400002)(39830400002)(39450400003)(377454003)(2501003)(3660700001)(230783001)(6506006)(77096006)(3280700002)(2950100002)(189998001)(33656002)(236005)(53936002)(6246003)(38730400002)(3846002)(6306002)(99286003)(54896002)(6116002)(55016002)(9686003)(790700001)(102836003)(81166006)(8936002)(8676002)(76176999)(50986999)(7696004)(5660300001)(25786009)(6436002)(66066001)(53546010)(54356999)(19609705001)(606006)(86362001)(478600001)(966005)(14454004)(229853002)(2906002)(7736002)(74316002)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB046; 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: 19 Jul 2017 08:34:37.0601 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB046 X-MC-Unique: WY-Rz4GGPb6MlbZHK-OReQ-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB235023C01D8658B9B25A3577B2A60SN2PR03MB2350namp_" Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 08:34:47 -0000 --_000_SN2PR03MB235023C01D8658B9B25A3577B2A60SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Henning, I had some high level queries/comments, which I sent back beginning of Apri= l. Here it is again for easier access: What are the main use cases? 1) Communicating spam related information between network elements for a pa= rticular call Various network elements may have a prediction whether a call is spam. It c= ould be useful to send all that info in a chain and then the ultimate decis= ion what needs to be sent to UE would be on the last-hop authorative entity= . A "0-100 spam score" indicator may be useful in this context, or at least= something more than just "likely to be spam" indicator. The identity of the entity providing spam score needs to be part of the pro= vided information. More than one spam score/identity pair needs to be supported. Support for signed identity should be there. I am not sure whether "type" would be useful here, I tend to think not. How= /Why would it be used? 2) Communicating spam related information between network and end-user I think here what is needed is just a "likely to be spam" indicator as far = as network prediction is concerned. End-user would see a visual indicator i= f the indicator is present. Anything more than that is just "information ov= erdose" IMHO and wouldn't have much practical value for an average user. An= other indicator stating "calling identity can't be verified" could be usefu= l but this IMHO is something different. An indicator for asking the end-user to provide information about whether h= e considers the call as spam would be useful and should be covered IMHO. Th= is would help Network Logic to learn/be more precise about heuristics appli= ed for spam detection. I can see a few different scenarios here: - Network decides to ask for feedback during initial INVITE, indicator can = a be a parameter in Call-Info - Network decides to ask for feedback after the call is setup, e.g. because= it detects that the call could be spam by speech analysis. Indicator can b= e sent in BYE, if the call is terminated by the calling party. Otherwise -i= f BYE is sent by called party-, network can still send BYE with the indicat= or toward calling party before 200 for the BYE received from it. I think th= is should work. In either case, end-user could see a visual indicator askin= g whether the call was spam. If he honors the request, 200(BYE) would have = the 666-unwanted. I am not sure what would be the best way to handle the si= tuation that the end-user hangs-up and then notices the indicator and decid= es to send feedback. UE can cache the Call-Id but conveying Call-Id/this wa= s(n't) a spam information to the network probably would require a new event= package. Alternatively, UE can buffer 200(BYE) for a while after user hang= s up -to give the user the opportunity to notice the indicator and act- but= that may have issues from billing perspective (maybe a "delayed =3D x sec"= parameter added to 200(BYE) could help). Thanks, Tolga From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Henning Schulz= rinne Sent: Tuesday, July 18, 2017 3:51 PM To: sipcore@ietf.org Subject: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities I'm finally addressing Christer's helpful comments in https://www.ietf.org/mail-archive/web/sipcore/current/msg07851.html and have submitted a new draft. Christer noted that I used the term "SIP entities" several times. What I me= ant to say is "SIP proxies and B2BUAs that face the [end customer] user age= nt and are associated with a registrar" (as opposed to some random SBC in t= he core of the network). After all, only those elements should remove any u= ntrusted call-info information in this case. If there's a better way than t= he current short-hand "SIP proxy or B2BUA", I'll gladly take suggestions. I think I addressed all the comments pending, but if I missed anything, ple= ase remind me. Otherwise, this should be ready. Henning --_000_SN2PR03MB235023C01D8658B9B25A3577B2A60SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Henning,

 

I had some high level queries/comments, which I sent= back beginning of April. Here it is again for easier access:

 

 

What are the main use cases?

1) Communicating spam related information between ne= twork elements for a particular call

Various network elements may have a prediction wheth= er a call is spam. It could be useful to send all that info in a chain and = then the ultimate decision what needs to be sent to UE would be on the last= -hop authorative entity. A "0-100 spam score" indicator may be useful in this context, or at least some= thing more than just "likely to be spam" indicator.

The identity of the entity providing spam score need= s to be part of the provided information.

More than one spam score/identity pair needs to be s= upported.

Support for signed identity should be there.

I am not sure whether "type" would be usef= ul here, I tend to think not. How/Why would it be used?

 

2) Communicating spam related information between ne= twork and end-user

I think here what is needed is just a "likely t= o be spam" indicator as far as network prediction is concerned. End-us= er would see a visual indicator if the indicator is present. Anything more = than that is just "information overdose" IMHO and wouldn't have much practical value for an average user. Another indica= tor stating "calling identity can't be verified" could be useful = but this IMHO is something different.

 

An indicator for asking the end-user to provide info= rmation about whether he considers the call as spam would be useful and sho= uld be covered IMHO. This would help Network Logic to learn/be more precise= about heuristics applied for spam detection. I can see a few different scenarios here:

- Network decides to ask for feedback during initial= INVITE, indicator can a be a parameter in Call-Info

- Network decides to ask for feedback after the call= is setup, e.g. because it detects that the call could be spam by speech an= alysis. Indicator can be sent in BYE, if the call is terminated by the call= ing party. Otherwise -if BYE is sent by called party-, network can still send BYE with the indicator toward cal= ling party before 200 for the BYE received from it. I think this should wor= k. In either case, end-user could see a visual indicator asking whether the= call was spam. If he honors the request, 200(BYE) would have the 666-unwanted. I am not sure what would be= the best way to handle the situation that the end-user hangs-up and then n= otices the indicator and decides to send feedback. UE can cache the Call-Id= but conveying Call-Id/this was(n't) a spam information to the network probably would require a new event packa= ge. Alternatively, UE can buffer 200(BYE) for a while after user hangs up -= to give the user the opportunity to notice the indicator and act- but that = may have issues from billing perspective (maybe a "delayed =3D x sec" parameter added to 200(BYE) could h= elp).

 

Thanks,

Tolga

 

From: sipcore [mailto:sipcore-bounces@ietf.or= g] On Behalf Of Henning Schulzrinne
Sent: Tuesday, July 18, 2017 3:51 PM
To: sipcore@ietf.org
Subject: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entitie= s

 

I'm finally addressing Chri= ster's helpful comments in

 

https://www.ietf.org/m= ail-archive/web/sipcore/current/msg07851.html

 

and have submitted a new dr= aft.

 

Christer noted that I used = the term "SIP entities" several times. What I meant to say is &qu= ot;SIP proxies and B2BUAs that face the [end customer] user agent and = are associated with a registrar" (as opposed to some random SBC in the core of the network). After all, only those elements should rem= ove any untrusted call-info information in this case. If there's a better w= ay than the current short-hand "SIP proxy or B2BUA", I'll gladly = take suggestions.

 

I think I addressed all the= comments pending, but if I missed anything, please remind me. Otherwise, t= his should be ready.

 

Henning

 

--_000_SN2PR03MB235023C01D8658B9B25A3577B2A60SN2PR03MB2350namp_-- From nobody Wed Jul 19 08:24:20 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 44CF7131C6C for ; Wed, 19 Jul 2017 08:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 WXh8zs9ird-5 for ; Wed, 19 Jul 2017 08:24:16 -0700 (PDT) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8256F1315FE for ; Wed, 19 Jul 2017 08:24:16 -0700 (PDT) X-AuditID: 12074412-22bff70000003b38-a1-596f799e6ee2 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id B5.7E.15160.E997F695; Wed, 19 Jul 2017 11:24:14 -0400 (EDT) Received: from [192.168.1.110] (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v6JFODis027087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 19 Jul 2017 11:24:14 -0400 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> Date: Wed, 19 Jul 2017 11:24:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixO6iqDu/Mj/SYP8fNouvPzaxOTB6LFny kymAMYrLJiU1J7MstUjfLoErY/rBHSwF99krrr/Pa2CcztbFyMEhIWAi8WdNQhcjF4eQwA4m iQs3prNDOG+YJDpeNLB2MXJyCAt4SnStfcoMYosIiEg8m/6PDaJoPaPE27+tYEVsAloScw79 ZwGxeQXsJa4tXAFmswioShx9/50dxBYVSJOY8f06M0SNoMTJmU/AajgFYiWOTL0DNodZwFbi ztzdzBC2uMStJ/OZIGx5ie1v5zBPYOSfhaR9FpKWWUhaZiFpWcDIsopRLjGnNFc3NzEzpzg1 Wbc4OTEvL7VI10wvN7NELzWldBMjJCiFdjCuPyl3iFGAg1GJh/dBan6kEGtiWXFl7iFGSQ4m JVHeObxAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8b8qAcrwpiZVVqUX5MClpDhYlcd6fi9X9 hATSE0tSs1NTC1KLYLIyHBxKErxmFUCNgkWp6akVaZk5JQhpJg5OkOE8QMPFQWp4iwsSc4sz 0yHypxiNOZo+bPnCxPFr5tYvTEIsefl5qVLivP3lQKUCIKUZpXlw02CJ5RWjONBzwrw7QAby AJMS3LxXQKuYgFYJ++aArCpJREhJNTAy9vGbfJzwyKx00p9I298zmTP130nWKzak5y3f3bWq +k7fhL/VCxZkfQqwmlFs9uM9+4kfHu4NZVILj88+8rFf/eID1wad4hclhzZVdX9kXOETcSd7 T9kj44OMkfHnKjpaDM2W/Z0snc78YOfWc39Or4pfcLbviZw/x90TCftDvs/d82mi8hVlJZbi jERDLeai4kQAPMZSswcDAAA= Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 15:24:19 -0000 On 7/19/17 4:34 AM, Asveren, Tolga wrote: > 2) Communicating spam related information between network and end-user > > I think here what is needed is just a "likely to be spam" indicator as > far as network prediction is concerned. End-user would see a visual > indicator if the indicator is present. Anything more than that is just > "information overdose" IMHO and wouldn't have much practical value for > an average user. Another indicator stating "calling identity can't be > verified" could be useful but this IMHO is something different. You seem to be making an assumption about where the intelligence is located and policy decisions are made. What you are saying may be appropriate for a dumb device and/or a dumb user. But most phones that will do anything with this information can be smart, and so be subject to configuration by the user for preferences. I'd rather maximize the amount of information available to the end device. Thanks, Paul From nobody Wed Jul 19 08:45: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 08085131C6C for ; Wed, 19 Jul 2017 08:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, 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 cl2ESKKnhysQ for ; Wed, 19 Jul 2017 08:45:31 -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 BFF2B131A50 for ; Wed, 19 Jul 2017 08:45:31 -0700 (PDT) Received: from pps.filterd (m0102175.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6JFiiVs001479; Wed, 19 Jul 2017 15:45:29 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 2bqavujsbm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 19 Jul 2017 15:45:29 +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=1l+eZ6ImOoIjaRdy0ZlhyPK2jeFMW1cIta4lj47JU8Q=; b=IjK6bOmwm7D9THJ4N2Y7cRaB6k3HGiev+NCmIBUqryn7K17ArjaijS68iou6qJLNgb4j4WU5k3IgLP0WMz++AkmruEc5lY8ReEnWTbpWIGythBFauKgtG7Dx8z53I5WmH1QrjJvITPQQsPPc7BRKShI2HnAwmwB2eZfr1cJmdiM= Received: from CY1PR09MB0760.namprd09.prod.outlook.com (10.161.173.151) by CY1PR09MB0759.namprd09.prod.outlook.com (10.161.173.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 15:45:27 +0000 Received: from CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) by CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) with mapi id 15.01.1261.024; Wed, 19 Jul 2017 15:45:27 +0000 From: Henning Schulzrinne To: "Asveren, Tolga" , "sipcore@ietf.org" Thread-Topic: draft-ietf-sipcore-callinfo-spam-01 - general Thread-Index: AdMAopBZ33P6AvZ9QAax/4dOZofeKQ== Date: Wed, 19 Jul 2017 15:45:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sonusnet.com; dkim=none (message not signed) header.d=none;sonusnet.com; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [192.104.54.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0759; 7:TiH4b6p/gSpHtNeWdFCn+rNNXJKNUjL7kpjLywNCdzNruQy8zvbftkZyVRT0wKB1GNTKh8HCS3IaekL8vyTppxFtmLKA+bJdVZZiwjLnKBir5QhcNmQpNGhcv5v+5YZfF/Tzcqznpa1I4exBCu+wWnkVsUutcjcxdTcw51CC5JKLCHsLwbPbgyvji+LGn6F8Rib7S0yppiPngPiYpTHElMikUHUpGBBm+4toLvEpZnjTqH72TEjj/4oSw8gRzaxE7MV5CtBugWa9DAdS7FMiORG6Ljv4tDgTKZ2kD5/eJJxlAXrM2yYuL2NfXrmE0QAEg9EwY3NHzphcPcPXpdW14rBXaFpR7Yp+S7Ls15mJWXRYmlxwvNj5G6NZiIGGEJT4o5dvZnAMvlijsea7cBBpxdtMB0pL4BN3M0XcIfpJeu3pZbzbZV1uJYYMpUEJqaLtRFhDpM6LQuAOqncvpvrDFUO5Zp1oGzrLG/pi8PAPjlBIhxeqdYFOMCJ/BzDrdfs/s0stH++lgZvMp4cWLiOZb3W3QZkHhNkXN47A3ELPCKWd0Gd0Ue9yUign57Czfk3QmULHGm+EFugNV9N/qe9Ufh4+fs0SmSyNb2at76EKV0iZ26C34zx+5Th9gowkXIc+thXDDGQm61r0f6xplIYy+TMTtFTlzpW9cE9xyU4KIHmESWKE2KLjXTpqcHNCkpw/X7KVcqfYEJDMY0amz4pUs7u6xMtSdrYtc9/KdCWjeOPTZVJ15Vy3Ojmy5uuHwcJZCf4Mw2I7rq179vjohPjHKLtCWr0xVt2JiioDf+zSDhY= x-ms-office365-filtering-correlation-id: adeaffa7-d2e8-43ff-b2b6-08d4cebd2da9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR09MB0759; x-ms-traffictypediagnostic: CY1PR09MB0759: x-exchange-antispam-report-test: UriScan:(151999592597050)(133145235818549)(26388249023172)(236129657087228)(131327999870524)(48057245064654)(21748063052155)(209349559609743)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR09MB0759; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR09MB0759; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39410400002)(39400400002)(377454003)(7696004)(2906002)(3660700001)(55016002)(229853002)(478600001)(72206003)(53936002)(14454004)(6306002)(54896002)(5660300001)(53546010)(3280700002)(54356999)(86362001)(19609705001)(25786009)(50986999)(74316002)(66066001)(2501003)(189998001)(7736002)(561944003)(6436002)(345774005)(3846002)(8676002)(77096006)(102836003)(6116002)(81166006)(8936002)(790700001)(2900100001)(230783001)(9686003)(6246003)(99286003)(38730400002)(33656002)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0759; H:CY1PR09MB0760.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0760C27004BA4E5B9910C19BEAA60CY1PR09MB0760namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 15:45:27.4444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0759 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - general 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 Jul 2017 15:45:43 -0000 --_000_CY1PR09MB0760C27004BA4E5B9910C19BEAA60CY1PR09MB0760namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tolga, Sorry for missing your comment and thank you for re-starting the conversati= on. Let me try to respond in general terms first, as I think your assumptions d= iffer a bit from mine. There are three general observations: 1. Call spam is somewhat subjective, partially reflected in the unwanted= vs. illegal distinction. There are clearly calls that are illegal (e.g., t= he tax authority scams) and presumably unwanted (if the called party knew t= hat it was a scam). But there are many calls that are somewhat less clear. = Calls by politicians or debt collectors are two classical examples - they m= ay be legal, but a significant fraction of people would rather not get thes= e calls or may not want to answer these calls at certain times. As another = example, a called party may decide that they'd rather not be bothered with = any non-personal calls ("robocalls") during their vacation or while traveli= ng in a different time zone, even if they'd otherwise be happy to get the c= all (e.g., calls about prescriptions being ready for pickup). They may also= decide to send these calls to voicemail. 2. As Paul points out in a follow-up message, only the end user is quali= fied to make these distinctions (or, somewhat equivalently, an algorithm co= nfigured by the end user that reflects her personal preferences). 3. Because of these subtleties, many carriers would rather not get into = the call dropping business and leave that to the end user, with exceptions.= (For example, they may want to drop denial-of-service or spoofed caller ID= calls.) The 'type' information helps the called party or the algorithm working on h= er behalf to make decisions. I don't quite understand the "identity of the entity providing spam score" = comment. The 'source' element is meant to provide this. Can you explain how= your identity differs from the one in the draft? Similarly, you write "A "0-100 spam score" indicator may be useful in this = context...". The 'spam' parameter in the draft contains this information. A= gain, can you explain how your proposal differs from the draft? [That said,= I'm tempted to rename the parameter to 'confidence', to be less prejudicia= l.] Henning From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Wednesday, July 19, 2017 4:35 AM To: Henning Schulzrinne ; sipcore@ietf.org Subject: RE: draft-ietf-sipcore-callinfo-spam-01 - SIP entities Henning, I had some high level queries/comments, which I sent back beginning of Apri= l. Here it is again for easier access: What are the main use cases? 1) Communicating spam related information between network elements for a pa= rticular call Various network elements may have a prediction whether a call is spam. It c= ould be useful to send all that info in a chain and then the ultimate decis= ion what needs to be sent to UE would be on the last-hop authorative entity= . A "0-100 spam score" indicator may be useful in this context, or at least= something more than just "likely to be spam" indicator. The identity of the entity providing spam score needs to be part of the pro= vided information. More than one spam score/identity pair needs to be supported. Support for signed identity should be there. I am not sure whether "type" would be useful here, I tend to think not. How= /Why would it be used? 2) Communicating spam related information between network and end-user I think here what is needed is just a "likely to be spam" indicator as far = as network prediction is concerned. End-user would see a visual indicator i= f the indicator is present. Anything more than that is just "information ov= erdose" IMHO and wouldn't have much practical value for an average user. An= other indicator stating "calling identity can't be verified" could be usefu= l but this IMHO is something different. [Trimming separate issue] --_000_CY1PR09MB0760C27004BA4E5B9910C19BEAA60CY1PR09MB0760namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tolga,

 

Sorry for missing your comment and thank you for re-= starting the conversation.

 

Let me try to respond in general terms first, as I t= hink your assumptions differ a bit from mine.

 

There are three general observations:

 

  1. C= all spam is somewhat subjective, partially reflected in the unwanted vs. il= legal distinction. There are clearly calls that are illegal (e.g., the tax = authority scams) and presumably unwanted (if the called party knew that it was a scam). But there are many calls th= at are somewhat less clear. Calls by politicians or debt collectors are two= classical examples – they may be legal, but a significant fraction o= f people would rather not get these calls or may not want to answer these calls at certain times. As another example= , a called party may decide that they’d rather not be bothered with a= ny non-personal calls (“robocalls”) during their vacation or wh= ile traveling in a different time zone, even if they’d otherwise be happy to get the call (e.g., calls about prescriptions being = ready for pickup). They may also decide to send these calls to voicemail.
  2. As Paul points out in a follow-up message, only the end user i= s qualified to make these distinctions (or, somewhat equivalently, an algor= ithm configured by the end user that reflects her personal preferences).
  3. Because of these subtleties, many ca= rriers would rather not get into the call dropping business and leave that = to the end user, with exceptions. (For example, they may want to drop denia= l-of-service or spoofed caller ID calls.)

 

The ‘type’ information helps the called = party or the algorithm working on her behalf to make decisions.<= /p>

 

I don’t quite understand the “identity o= f the entity providing spam score” comment. The ‘source’ = element is meant to provide this. Can you explain how your identity differs= from the one in the draft?

 

Similarly, you write “A "0-100 spam score= " indicator may be useful in this context…”. The ‘sp= am’ parameter in the draft contains this information. Again, can you = explain how your proposal differs from the draft? [That said, I’m tem= pted to rename the parameter to ‘confidence’, to be less prejudicia= l.]

 

Henning

 

From: Asveren, Tolga [mailto:tasveren@sonusne= t.com]
Sent: Wednesday, July 19, 2017 4:35 AM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; sipcore= @ietf.org
Subject: RE: draft-ietf-sipcore-callinfo-spam-01 - SIP entities=

 

Henning,

 

I had some high level queries/comments, which I sent= back beginning of April. Here it is again for easier access:

 

 

What are the main use cases?

1) Communicating spam related information between ne= twork elements for a particular call

Various network elements may have a prediction wheth= er a call is spam. It could be useful to send all that info in a chain and = then the ultimate decision what needs to be sent to UE would be on the last= -hop authorative entity. A "0-100 spam score" indicator may be useful in this context, or at least some= thing more than just "likely to be spam" indicator.

The identity of the entity providing spam score need= s to be part of the provided information.

More than one spam score/identity pair needs to be s= upported.

Support for signed identity should be there.

I am not sure whether "type" would be usef= ul here, I tend to think not. How/Why would it be used?

 

2) Communicating spam related information between ne= twork and end-user

I think here what is needed is just a "likely t= o be spam" indicator as far as network prediction is concerned. End-us= er would see a visual indicator if the indicator is present. Anything more = than that is just "information overdose" IMHO and wouldn't have much practical value for an average user. Another indica= tor stating "calling identity can't be verified" could be useful = but this IMHO is something different.

 

[Trimming separate issue]

 

--_000_CY1PR09MB0760C27004BA4E5B9910C19BEAA60CY1PR09MB0760namp_-- From nobody Wed Jul 19 08:49: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 B32D4131A93 for ; Wed, 19 Jul 2017 08:49:44 -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 iUwxE8ZHQcwY for ; Wed, 19 Jul 2017 08:49:42 -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 C875F131A50 for ; Wed, 19 Jul 2017 08:49:42 -0700 (PDT) Received: from pps.filterd (m0102176.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6JFnfon030588; Wed, 19 Jul 2017 15:49:41 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0053.outbound.protection.outlook.com [23.103.198.53]) by mx0a-0024ed01.pphosted.com with ESMTP id 2bqa3g3559-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 19 Jul 2017 15:49:41 +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=9fhR5pLpxuPp1ni6UicYu1KyXkgyBz2s/H2M2a71ay0=; b=BB5Ska9bKQVmrdqYXbchqjdriUoqSNJ9/4Yfe9CqGSYcnH67HjwouT+Me4jwhM+2F0a4M8Af7zO+Lgqo9ieL+Icm5yVCz7SOr9tiIDI/izm7Svm4C3wuKUDmErnZej3E5QUVcu8ww47n/PGgk5spPA/d5SOqI6vfaQWQYs9gZac= Received: from CY1PR09MB0760.namprd09.prod.outlook.com (10.161.173.151) by CY1PR09MB0757.namprd09.prod.outlook.com (10.161.173.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 15:49:40 +0000 Received: from CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) by CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) with mapi id 15.01.1261.024; Wed, 19 Jul 2017 15:49:39 +0000 From: Henning Schulzrinne To: "Asveren, Tolga" , "sipcore@ietf.org" Thread-Topic: draft-ietf-sipcore-callinfo-spam-01 - spam signaling Thread-Index: AdMApiFx95ijoSxGTASFGC2ZcUd6zQ== Date: Wed, 19 Jul 2017 15:49:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sonusnet.com; dkim=none (message not signed) header.d=none;sonusnet.com; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [192.104.54.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0757; 7:gS9DBWaOnMaopKQBlq8tIlqgIuIiyLvJQRjTa+FV9aFnyl5ljrGNO5wGTT5ZUdEDMYMOm35imjmrq533HzMuD4cLkPraiLHo8WVaOlc60P5uZsCycVftB7zwRXVgjmSoObKI3uHxJZOX9enYGCV1wvKFlIjBiewr8/7nuum0tIM2XuNxB4Gv+A5F7up/ETKo43aXPro8gwqa22FgMcuW08mKQescVK4QWVI58s6sZIMI8XHlEHd4fu97G/jjf6Rk3Vvo6av1IM7qrl12RycNibWzh1sf3HUeidpigg6JKjFwkA1rlqRd8Xhc7L7o9HEx84QfV82MEsyJzVdc5ip6bSbfuA4ucvZj8nrSGYeJuI0NlngNIslmLw7nLx915xT8qiKInoxlcYDuC5JAfwe+rFp++DNhIVZFDIRtuzjHL8Tnsr9s9Dw6bi90fgga+CHheydoE0hg6vxR6VYgdD7pOmgmKyCZOLEt+ZNHLtYD1dInrIWTmDiXE8qhqHmzVVzis8WThLNRTHjQQlOs4ZNQwPfIGdaQzhVLPtVUC9I5Fm/GBvdgkz3vm/ptbl26gJ5pxUQ7rTVn4tWwv/eDPrjmSlkcLnI1rllaUAyCMvFXUF6AI0Y8LkBDxNk2JTTDL7AQ0BqExLyQr6Q1YAeTj1uzMGXaVVonvF9Cq5IYqXCReK9tpnhXMtxylJgE/gS6vuZPUe42vtkgQCDpkgKEimThTTvIayoui2Xyz8nAkMOsk0dgRhpvNaY0PoO8uXSY0JOalLfAmwycy1cLIrMRtW7N/izqTkyTZg1ayb033qBz4kw= x-ms-office365-filtering-correlation-id: 823e9d02-c12f-46fb-218b-08d4cebdc40d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR09MB0757; x-ms-traffictypediagnostic: CY1PR09MB0757: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(48057245064654)(148574349560750)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR09MB0757; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR09MB0757; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39410400002)(39450400003)(39850400002)(39840400002)(377454003)(81166006)(66066001)(6506006)(3846002)(7736002)(8676002)(53546010)(478600001)(33656002)(72206003)(7696004)(54356999)(8936002)(86362001)(2501003)(14454004)(2900100001)(5660300001)(50986999)(3660700001)(2906002)(3280700002)(6436002)(6116002)(790700001)(38730400002)(19609705001)(229853002)(102836003)(230783001)(99286003)(77096006)(6246003)(9686003)(6306002)(25786009)(74316002)(189998001)(55016002)(54896002)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0757; H:CY1PR09MB0760.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB076029B7EA48F8F798602910EAA60CY1PR09MB0760namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 15:49:39.7855 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0757 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - spam signaling 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 Jul 2017 15:49:45 -0000 --_000_CY1PR09MB076029B7EA48F8F798602910EAA60CY1PR09MB0760namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tolga, To respond to your last paragraph, as that seems to raise issues unrelated = to the callinfo draft: I think RFC 8197 (SIP Response Code for Unwanted Calls) addresses most of y= our last comment, except the 'post call' case. My guess is that, in almost = all cases, the BYE-with-Reason described in RFC 8197 addresses the common c= ase of "hang up with prejudice". There may be a need for providing another = mechanism for post-hang-up spam indication, e.g., using SIP MESSAGE (to a d= esignated carrier address, similar to the SMS 7726 short code), possibly wi= th additional information. For example, this would be useful when listening= to voicemail. That mechanism could re-use the 'type' list here, but otherwise seems like = a different problem beyond the scope of the draft. My suggestion would be t= o separate the discussion. Henning From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Wednesday, July 19, 2017 4:35 AM To: Henning Schulzrinne ; sipcore@ietf.org Subject: RE: draft-ietf-sipcore-callinfo-spam-01 - SIP entities An indicator for asking the end-user to provide information about whether h= e considers the call as spam would be useful and should be covered IMHO. Th= is would help Network Logic to learn/be more precise about heuristics appli= ed for spam detection. I can see a few different scenarios here: - Network decides to ask for feedback during initial INVITE, indicator can = a be a parameter in Call-Info - Network decides to ask for feedback after the call is setup, e.g. because= it detects that the call could be spam by speech analysis. Indicator can b= e sent in BYE, if the call is terminated by the calling party. Otherwise -i= f BYE is sent by called party-, network can still send BYE with the indicat= or toward calling party before 200 for the BYE received from it. I think th= is should work. In either case, end-user could see a visual indicator askin= g whether the call was spam. If he honors the request, 200(BYE) would have = the 666-unwanted. I am not sure what would be the best way to handle the si= tuation that the end-user hangs-up and then notices the indicator and decid= es to send feedback. UE can cache the Call-Id but conveying Call-Id/this wa= s(n't) a spam information to the network probably would require a new event= package. Alternatively, UE can buffer 200(BYE) for a while after user hang= s up -to give the user the opportunity to notice the indicator and act- but= that may have issues from billing perspective (maybe a "delayed =3D x sec"= parameter added to 200(BYE) could help). Thanks, Tolga --_000_CY1PR09MB076029B7EA48F8F798602910EAA60CY1PR09MB0760namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tolga,

 

To respond to your last paragraph, as that seems to = raise issues unrelated to the callinfo draft:

 

I think RFC 8197 (SIP Response Code for Unwanted = Calls) addresses most of your last comment, except the ‘post call= ’ case. My guess is that, in almost all cases, the BYE-with-Reason de= scribed in RFC 8197 addresses the common case of “hang up with prejudice”. There may be a need for providing= another mechanism for post-hang-up spam indication, e.g., using SIP MESSAG= E (to a designated carrier address, similar to the SMS 7726 short code), po= ssibly with additional information. For example, this would be useful when listening to voicemail.

 

That mechanism could re-use the ‘type’ l= ist here, but otherwise seems like a different problem beyond the scope of = the draft. My suggestion would be to separate the discussion.

 

Henning

 

From: Asveren, Tol= ga [mailto:tasveren@sonusnet.com]
Sent: Wednesday, July 19, 2017 4:35 AM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; sipcore= @ietf.org
Subject: RE: draft-ietf-sipcore-callinfo-spam-01 - SIP entities=

 

An indicator for asking t= he end-user to provide information about whether he considers the call as s= pam would be useful and should be covered IMHO. This would help Network Log= ic to learn/be more precise about heuristics applied for spam detection. I can see a few different scenarios here:=

- Network decides to ask = for feedback during initial INVITE, indicator can a be a parameter in Call-= Info

- Network decides to ask = for feedback after the call is setup, e.g. because it detects that the call= could be spam by speech analysis. Indicator can be sent in BYE, if the cal= l is terminated by the calling party. Otherwise -if BYE is sent by called party-, network can still send BYE wit= h the indicator toward calling party before 200 for the BYE received from i= t. I think this should work. In either case, end-user could see a visual in= dicator asking whether the call was spam. If he honors the request, 200(BYE) would have the 666-unwanted. = I am not sure what would be the best way to handle the situation that the e= nd-user hangs-up and then notices the indicator and decides to send feedbac= k. UE can cache the Call-Id but conveying Call-Id/this was(n't) a spam information to the network probably= would require a new event package. Alternatively, UE can buffer 200(BYE) f= or a while after user hangs up -to give the user the opportunity to notice = the indicator and act- but that may have issues from billing perspective (maybe a "delayed =3D x sec&= quot; parameter added to 200(BYE) could help).

 

Thanks,

Tolga

 

--_000_CY1PR09MB076029B7EA48F8F798602910EAA60CY1PR09MB0760namp_-- From nobody Wed Jul 19 11:11: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 2D6CD131B9B for ; Wed, 19 Jul 2017 11:11:09 -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 6Rn3_kfDfbPE for ; Wed, 19 Jul 2017 11:11:07 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12FA9131B88 for ; Wed, 19 Jul 2017 11:11:06 -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=jIknou9q2+68/UmHRvddVEEgXIuGFx1Q/gGd9+5PoO0=; b=kdJkCdLRPRQIYl3/8e8NC8qsHmDOk8lmd+9XiDNtOzEZ1CtHh6TC1vKB1Ad84iaSqPK+ErrJ3Z8LLOVUeTaGCy7uX/gdob7bc1DQfEivk0OXNzfrA0bvurqI0LTjGfNTtnQAuC/sd0vGzMcgF/r+d3Oc9u1I9YRko6IwZXy8OLY= Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp0018.outbound.protection.outlook.com [216.32.181.18]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-41-gQ_OiZXrPimpLBNyOIbPkA-1; Wed, 19 Jul 2017 14:11:04 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2157.namprd03.prod.outlook.com (10.166.209.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 18:11:02 +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.1282.011; Wed, 19 Jul 2017 18:11:02 +0000 From: "Asveren, Tolga" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities Thread-Index: AQHS//8f86lEHhh9VUKR5rSbwxo4z6Ja0ofAgABzoYCAAC1loA== Date: Wed, 19 Jul 2017 18:11:02 +0000 Message-ID: References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> In-Reply-To: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> 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; SN2PR03MB2157; 20:CQUdz++jldr/8PjuATe97GZIAAX1dfRR9R1YhvpfUS2c1Uw3RbC/A4UeMQM6+9okwSoyaUHmAzLiCTLn+phNCDf8D9Ac8dNJHLgT1mHpU0d0dLzKWvSvBv2AtDCXy0Muez8oZZkWl/quP9BC7uL9KGtu3mAc97MrTZcMbvnqO/8= x-ms-office365-filtering-correlation-id: 6022b879-4344-4723-305e-08d4ced183e9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR03MB2157; x-ms-traffictypediagnostic: SN2PR03MB2157: x-exchange-antispam-report-test: UriScan:(236129657087228)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB2157; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB2157; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39410400002)(39400400002)(13464003)(377454003)(24454002)(81166006)(2171002)(8936002)(14454004)(7736002)(2900100001)(6436002)(77096006)(3280700002)(2950100002)(7696004)(38730400002)(53546010)(3660700001)(230783001)(5660300001)(55016002)(53936002)(9686003)(8676002)(6506006)(6246003)(6306002)(99286003)(66066001)(478600001)(86362001)(2906002)(3846002)(33656002)(25786009)(229853002)(966005)(189998001)(74316002)(50986999)(102836003)(54356999)(305945005)(76176999)(2501003)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2157; 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: 19 Jul 2017 18:11:02.1035 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2157 X-MC-Unique: gQ_OiZXrPimpLBNyOIbPkA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 18:11:09 -0000 Let me ask this question then: What would "spam with a likelihood of 47%" mean? Will the specification det= ail how this percentage need to be calculated? Otherwise how can the end-de= vice take some action based on this value? One could argue that all these a= re "implementation dependent" but honestly I think this would just create c= onfusion/chaos in practice and likely to be not useful. Thanks, Tolga -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, July 19, 2017 11:24 AM To: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities On 7/19/17 4:34 AM, Asveren, Tolga wrote: > 2) Communicating spam related information between network and end-user >=20 > I think here what is needed is just a "likely to be spam" indicator as=20 > far as network prediction is concerned. End-user would see a visual=20 > indicator if the indicator is present. Anything more than that is just=20 > "information overdose" IMHO and wouldn't have much practical value for=20 > an average user. Another indicator stating "calling identity can't be=20 > verified" could be useful but this IMHO is something different. You seem to be making an assumption about where the intelligence is located= and policy decisions are made. What you are saying may be appropriate for a dumb device and/or a dumb user= . But most phones that will do anything with this information can be smart,= and so be subject to configuration by the user for preferences.=20 I'd rather maximize the amount of information available to the end device. =09Thanks, =09Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Jul 19 11: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 96D7212EAB0 for ; Wed, 19 Jul 2017 11:33:25 -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 yF7-OMtW1zCw for ; Wed, 19 Jul 2017 11:33:23 -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 3862312711E for ; Wed, 19 Jul 2017 11:33:23 -0700 (PDT) Received: from pps.filterd (m0102172.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6JITpVZ015572; Wed, 19 Jul 2017 18:33:19 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0047.outbound.protection.outlook.com [23.103.198.47]) by mx0a-0024ed01.pphosted.com with ESMTP id 2bqc70k8v2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 19 Jul 2017 18:33:18 +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=dGUvS1l5tEX451Vwrs/FomrAwo3AhKrhoTE0eRgMbuM=; b=vfzZjR00YcvYLRE7BWVL8WtdMg4wFM61/tHYArfBdRDgUoeXREMrmE0KE+ZFvQP7oXai6VIaJgxvP+4BRJn2mVQDlW4PJOLvyOzCrsMTnEeS/O6xQTpFfDXJ7qdGysw3XVmCpNkTGJWdtHEiy6TGwo5oQH4uxILs2IqisZQskKQ= Received: from CY1PR09MB0760.namprd09.prod.outlook.com (10.161.173.151) by CY1PR09MB0757.namprd09.prod.outlook.com (10.161.173.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 18:33:17 +0000 Received: from CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) by CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) with mapi id 15.01.1261.024; Wed, 19 Jul 2017 18:33:17 +0000 From: Henning Schulzrinne To: "Asveren, Tolga" , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities Thread-Index: AQHS//8f86lEHhh9VUKR5rSbwxo4z6Ja0ofAgABzoYCAAC1loIAAAo2A Date: Wed, 19 Jul 2017 18:33:17 +0000 Message-ID: References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sonusnet.com; dkim=none (message not signed) header.d=none;sonusnet.com; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [192.104.54.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0757; 7:DWMp6jiwe6nnlAAnaTHtbNMZptP/XIQDaYCZ2qvbUuuSOba8iz7e2ejYKA2RBRb3p+jU1Of/V+7wjquQ1d9mVIAwGkP8IOuk05ZRYdIj8yku+dGb4Ei4yLHBYUzl16JF8p8FyKOQyL63HCA5jBvzqEd8Fb4N9IFJ2G7W2/YKXrjEVyZa8LUrjwAnMRBuheih/y+bMGEz9Uyxop23gSmEsyT4EeAHNH/KRVZOjF7FCBkEjjTB4vAt4B0y4aLn7wdFFHPRRTlsS2sTBQjiVWBnPXvGQjYk9MV07pjdzbNUrTUMLv0n00j8YJ+v77WuH/C16pIX6KWjNLVtQEp7igw9HPlQlKvd8Vrhs4AD86L6omO4FZ9gEamiHylkH10J7aKdvMULT6+/92CErK8B6Cyi8gYB14YeSpgOa+ZPFlLpOH9jGfgrDRH45vm8QdSjeIJukSOB1LaHAFv4AiPXy4NQG3vbtSDlyv7ES4FMJrXJfkHQTkwPQalMYzJMRy8MbQ37LQo4zJIKInU+GBQGGruJYq+3PG9wtuadr34uu32TzcR5kSv4ttqn1CNi8EFxPawmeHJFd9L21s7xAlFZ1ZzQD9wzr+9U5SameWqbhvlh7BsoMHTqQs3vHxaUqBO+KPGiWUgDQudk7319OCtohG1ZKVTnwzsb3WccoxDGC5mYbkHy2O/R5Hs9orfzlVwZ81ttlsbjgQ4Nb+CvpMdMsFR3NARm2uBQ3DQolveRXNlaw9cEhVqw0W5rgGEMQ/aiD+JcuqllfrGBY+/ij/uulJJ6UMxZfnzcGxPC+tit4SQEcXQ= x-ms-office365-filtering-correlation-id: 8346a832-8cd7-47c8-5f61-08d4ced49fb0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR09MB0757; x-ms-traffictypediagnostic: CY1PR09MB0757: x-exchange-antispam-report-test: UriScan:(236129657087228)(48057245064654)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR09MB0757; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR09MB0757; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39840400002)(39450400003)(39400400002)(39410400002)(13464003)(377454003)(229853002)(38730400002)(102836003)(6116002)(6436002)(93886004)(230783001)(3280700002)(2906002)(25786009)(74316002)(189998001)(2950100002)(9686003)(55016002)(53936002)(3660700001)(77096006)(2171002)(99286003)(305945005)(6246003)(33656002)(72206003)(14454004)(7696004)(8676002)(3846002)(7736002)(81166006)(66066001)(6506006)(478600001)(53546010)(2501003)(5660300001)(50986999)(2900100001)(76176999)(8936002)(54356999)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0757; H:CY1PR09MB0760.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 18:33:17.1419 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0757 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_12:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 18:33:26 -0000 This type of labeling is very common for email spam filters. It's essential= ly the same as "There's a 47% chance of rain today." Except that meteorolog= ists are smart enough not to say 47%, but rather 50%. It is better than the "According to the polls, candidate H has an 89% chanc= e of winning the election." (Any semblance of initials to real persons has = a 1-in-26 chance of being made up.) Theoretically, unlike for elections and somewhat similar to the weather cas= e, this is testable: You could take all the 50% spam or rain predictions, c= heck with some reliable metric (human or rain gauge) whether the spam or ra= in happened and compare your results, i.e., roughly one in two such predict= ions should indeed turn out to be spam or rain. (It's more complicated than= that, but we're getting pretty close to the philosophical debate of what p= robabilities mean when making predictions, which is apparently a rather uns= ettled scientific question.) To actually answer your question: I don't think this is useful except as a = rough way for users to trade false-positive/false-negative penalties. For e= xample, they may discard all 80%+ probability calls, route 30-80% calls to = voicemail and ring the below-30% calls. The thresholds are arbitrary, but u= sers may tune them based on experience ("all the calls in voicemail were sp= am, so I can go lower"). Some people pack an umbrella when there's a 20% chance of rain, others are = more willing to risk getting wet. By the way, it is well-known that meteoro= logists over-predict rain since nobody complains if they did not get soaked= . Henning -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, Tolga Sent: Wednesday, July 19, 2017 2:11 PM To: Paul Kyzivat ; sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities Let me ask this question then: What would "spam with a likelihood of 47%" mean? Will the specification det= ail how this percentage need to be calculated? Otherwise how can the end-de= vice take some action based on this value? One could argue that all these a= re "implementation dependent" but honestly I think this would just create c= onfusion/chaos in practice and likely to be not useful. Thanks, Tolga =20 From nobody Wed Jul 19 11:46:17 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE261267BB for ; Wed, 19 Jul 2017 11:46:12 -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 84aGe_1q5HVz for ; Wed, 19 Jul 2017 11:46:07 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BBF12711E for ; Wed, 19 Jul 2017 11:46:07 -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=cz2BFuh3IP/KTULufRwzwIquwndCBdmR2qX9MjhzEtU=; b=ZpjK9LJ0xJGuiKfqSvqyYLST3pUXTUypiuAHNWePhp6szB9KDiMLvnq3lWa6yY8S8JZzcdoH/Rr985KU3GEIQ88eCZoIVjvPZJQ7QM27+iF/l5V9q+sm9xPjQHp3xzwZ/HFKTzsjeqNJm8pM+9RJT5TwHLYIQsPw316haWZjOUo= Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0120.outbound.protection.outlook.com [207.46.163.120]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-147-ul2bWlDpOFCutQsz5FiNYQ-1; Wed, 19 Jul 2017 14:46:04 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2318.namprd03.prod.outlook.com (10.166.210.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Wed, 19 Jul 2017 18:46:02 +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.1282.011; Wed, 19 Jul 2017 18:46:02 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities Thread-Index: AQHS//8f86lEHhh9VUKR5rSbwxo4z6Ja0ofAgABzoYCAAC1loIAAAo2AgAAGWUA= Date: Wed, 19 Jul 2017 18:46:02 +0000 Message-ID: References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> 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; SN2PR03MB2318; 20:smJARjdyBWq9Gi4TXU4Ss96iZCBYAAmZCwOHGOaAAMwJ8kEPaA14ODXacClyIsmIss25TPta+V0ZF7kfOAVBY5M9XUs+bp7+QqORTxrEaiOjYWK5lRBxYc4I61xtcE60XiDa6p9LBAehouiAMb+7SVbbZAMut0Sa1wEtbIEUeWk= x-ms-office365-filtering-correlation-id: 00f367b4-87da-45a8-61c6-08d4ced667d0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR03MB2318; x-ms-traffictypediagnostic: SN2PR03MB2318: x-exchange-antispam-report-test: UriScan:(236129657087228)(48057245064654)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(2017060910075)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB2318; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB2318; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39400400002)(39410400002)(39450400003)(13464003)(377454003)(2501003)(3660700001)(230783001)(3280700002)(6506006)(77096006)(2950100002)(93886004)(33656002)(2171002)(53936002)(189998001)(6246003)(38730400002)(99286003)(3846002)(102836003)(55016002)(6116002)(9686003)(81166006)(8936002)(76176999)(50986999)(8676002)(7696004)(25786009)(5660300001)(6436002)(53546010)(86362001)(54356999)(2906002)(478600001)(229853002)(7736002)(305945005)(74316002)(14454004)(2900100001)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2318; 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: 19 Jul 2017 18:46:02.3493 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2318 X-MC-Unique: ul2bWlDpOFCutQsz5FiNYQ-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 18:46:12 -0000 Agreed that this is somewhat about "philosophical aspects of priority". Hav= ing said that, I really feel not content with a fine-granularity indicator = considering how in practice it would/could be generated especially consider= ing all the operator/equipment/call scenario/deployment model combinations.= It would be like, actually worse, than how sausages are prepared. I am not religiously advocating a change toward a binary indicator (i.e. I = wouldn't consider the current model as something "wrong") but IMHO that wou= ld be a more practical way of getting something useful at the end; just my = 2 cents. Thanks, Tolga -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Wednesday, July 19, 2017 2:33 PM To: Asveren, Tolga ; Paul Kyzivat ; sipcore@ietf.org Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities This type of labeling is very common for email spam filters. It's essential= ly the same as "There's a 47% chance of rain today." Except that meteorolog= ists are smart enough not to say 47%, but rather 50%. It is better than the "According to the polls, candidate H has an 89% chanc= e of winning the election." (Any semblance of initials to real persons has = a 1-in-26 chance of being made up.) Theoretically, unlike for elections and somewhat similar to the weather cas= e, this is testable: You could take all the 50% spam or rain predictions, c= heck with some reliable metric (human or rain gauge) whether the spam or ra= in happened and compare your results, i.e., roughly one in two such predict= ions should indeed turn out to be spam or rain. (It's more complicated than= that, but we're getting pretty close to the philosophical debate of what p= robabilities mean when making predictions, which is apparently a rather uns= ettled scientific question.) To actually answer your question: I don't think this is useful except as a = rough way for users to trade false-positive/false-negative penalties. For e= xample, they may discard all 80%+ probability calls, route 30-80% calls to = voicemail and ring the below-30% calls. The thresholds are arbitrary, but u= sers may tune them based on experience ("all the calls in voicemail were sp= am, so I can go lower"). Some people pack an umbrella when there's a 20% chance of rain, others are = more willing to risk getting wet. By the way, it is well-known that meteoro= logists over-predict rain since nobody complains if they did not get soaked= . Henning -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, Tolga Sent: Wednesday, July 19, 2017 2:11 PM To: Paul Kyzivat ; sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities Let me ask this question then: What would "spam with a likelihood of 47%" mean? Will the specification det= ail how this percentage need to be calculated? Otherwise how can the end-de= vice take some action based on this value? One could argue that all these a= re "implementation dependent" but honestly I think this would just create c= onfusion/chaos in practice and likely to be not useful. Thanks, Tolga =20 From nobody Wed Jul 19 13:40: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 77601131905 for ; Wed, 19 Jul 2017 13:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vVVZmiaf-Nca for ; Wed, 19 Jul 2017 13:40:49 -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 9AB051318F3 for ; Wed, 19 Jul 2017 13:40:49 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-07v.sys.comcast.net with ESMTP id XvlEdSm7lx5DGXvm4djs2N; Wed, 19 Jul 2017 20:40:48 +0000 Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-17v.sys.comcast.net with SMTP id Xvm4dRXox3sD5Xvm4dMYK9; Wed, 19 Jul 2017 20:40:48 +0000 To: Henning Schulzrinne , "Asveren, Tolga" , "sipcore@ietf.org" References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Wed, 19 Jul 2017 16:40:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfA0d4K9UoOhFaasM0PGj5P0NbjkQWwN0vcma88Gg0a5ztb83ar92gH3TZwO3QR3DbByuXBWbnxkESyoJNVtbYkkbN9mp2NuKc/wx9KeJUhJlcwP/ITol fMWUURQ78nnWwzDyQEzRp6ouW599WRYIZZpNCE3A9oVA528/SrfMKrMKpH8lAvVIz07ZkN0IBBCDj10JMSKY+WIBRHAEefER8ujy1nlNXQY70vyNB7MrSs0N 7ZMWu1r72iqeu7lC5ELcZw== Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 20:40:50 -0000 On 7/19/17 2:33 PM, Henning Schulzrinne wrote: > By the way, it is well-known that meteorologists over-predict rain since nobody complains if they did not get soaked. Farmers who are deciding whether to water their fields may feel differently. Perhaps meteorologists in farm country bias their predictions the other way. Thanks, Paul From nobody Wed Jul 19 13:45: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 1C79E1317A4 for ; Wed, 19 Jul 2017 13:45:27 -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, 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 m4xKowXv9c91 for ; Wed, 19 Jul 2017 13:45:25 -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 CC7AE131679 for ; Wed, 19 Jul 2017 13:45:25 -0700 (PDT) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id Xvq3dW0zY383gXvqXdNH4F; Wed, 19 Jul 2017 20:45:25 +0000 Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-03v.sys.comcast.net with SMTP id XvqWdpHtPTnV3XvqWdwwd4; Wed, 19 Jul 2017 20:45:25 +0000 To: "Asveren, Tolga" , Henning Schulzrinne , "sipcore@ietf.org" References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Wed, 19 Jul 2017 16:45:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNnTPHUjX5l0+UehymDF43phXM9f0iQ2gBP8RYJoAqXQ3L2pTqQeW8hJ757Xd4+GqS8fCRtVHdRPOaNOBEbL8ynhHUr7O+lmAkcByi+WBAp7HKYiVApN 3ynYOlyapKndcY6BqlSy+NQnvS8fxHmmECXPXB4R6FZJga8330KEVtaK6ik//+RucFvzM0vl5GhUvW0+iFpdMnITqE02OuisLr7MfU+kJpm6Jr/yN4x/ZXWm d5tzO1hxVYVxm7MH6AVE6Q== Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 20:45:27 -0000 On 7/19/17 2:46 PM, Asveren, Tolga wrote: > Agreed that this is somewhat about "philosophical aspects of priority". Having said that, I really feel not content with a fine-granularity indicator considering how in practice it would/could be generated especially considering all the operator/equipment/call scenario/deployment model combinations. It would be like, actually worse, than how sausages are prepared. > > I am not religiously advocating a change toward a binary indicator (i.e. I wouldn't consider the current model as something "wrong") but IMHO that would be a more practical way of getting something useful at the end; just my 2 cents. If those who are inserting the probabilities feel like you do then they can restrict themselves to inserting values 0, 50, 100, or whatever granularity they feel comfortable with. Thanks, Paul > Thanks, > Tolga > > -----Original Message----- > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > Sent: Wednesday, July 19, 2017 2:33 PM > To: Asveren, Tolga ; Paul Kyzivat ; sipcore@ietf.org > Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities > > This type of labeling is very common for email spam filters. It's essentially the same as "There's a 47% chance of rain today." Except that meteorologists are smart enough not to say 47%, but rather 50%. > > It is better than the "According to the polls, candidate H has an 89% chance of winning the election." (Any semblance of initials to real persons has a 1-in-26 chance of being made up.) > > Theoretically, unlike for elections and somewhat similar to the weather case, this is testable: You could take all the 50% spam or rain predictions, check with some reliable metric (human or rain gauge) whether the spam or rain happened and compare your results, i.e., roughly one in two such predictions should indeed turn out to be spam or rain. (It's more complicated than that, but we're getting pretty close to the philosophical debate of what probabilities mean when making predictions, which is apparently a rather unsettled scientific question.) > > To actually answer your question: I don't think this is useful except as a rough way for users to trade false-positive/false-negative penalties. For example, they may discard all 80%+ probability calls, route 30-80% calls to voicemail and ring the below-30% calls. The thresholds are arbitrary, but users may tune them based on experience ("all the calls in voicemail were spam, so I can go lower"). > > Some people pack an umbrella when there's a 20% chance of rain, others are more willing to risk getting wet. By the way, it is well-known that meteorologists over-predict rain since nobody complains if they did not get soaked. > > Henning > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, Tolga > Sent: Wednesday, July 19, 2017 2:11 PM > To: Paul Kyzivat ; sipcore@ietf.org > Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities > > Let me ask this question then: > What would "spam with a likelihood of 47%" mean? Will the specification detail how this percentage need to be calculated? Otherwise how can the end-device take some action based on this value? One could argue that all these are "implementation dependent" but honestly I think this would just create confusion/chaos in practice and likely to be not useful. > > Thanks, > Tolga > > > From nobody Wed Jul 19 13:46: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 5C95C131B16 for ; Wed, 19 Jul 2017 13:46:35 -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 de8ocRSc4OeC for ; Wed, 19 Jul 2017 13:46:33 -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 8F668131B0D for ; Wed, 19 Jul 2017 13:46:33 -0700 (PDT) Received: from pps.filterd (m0102172.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6JKifvZ028083; Wed, 19 Jul 2017 20:46:30 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 2bqc70kbfk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 19 Jul 2017 20:46: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=b9viLtsGsk7s/V5v+PV4KEAFwP1ft8pDuSMqQM9uaks=; b=oIlbeRFb8yhID2TJoLFEmvEo6sP/oplqj6ALy53YsFaqqmoXDvQ2Rf9DrZvyHKddYnA7nwt5dFr1oDb/UjasxW8EsWlS54lJt8egk0KT97T4hRkE+Xl/VXOnf5rNDYr3ypJNe0kokoC/8ZC2RHIMcNAjwAEHDD+TDe68wmy/6zA= Received: from CY1PR09MB0760.namprd09.prod.outlook.com (10.161.173.151) by CY1PR09MB0760.namprd09.prod.outlook.com (10.161.173.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 20:46:28 +0000 Received: from CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) by CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) with mapi id 15.01.1261.024; Wed, 19 Jul 2017 20:46:28 +0000 From: Henning Schulzrinne To: "Asveren, Tolga" , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities Thread-Index: AQHS//8f86lEHhh9VUKR5rSbwxo4z6Ja0ofAgABzoYCAAC1loIAAAo2AgAAGWUCAACJWAA== Date: Wed, 19 Jul 2017 20:46:28 +0000 Message-ID: References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sonusnet.com; dkim=none (message not signed) header.d=none;sonusnet.com; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [192.104.54.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0760; 7:1g5G3xPRh6KLylvI2XwxJyXTSdglO+AKXw3yS3lrZeDew42PemlqHqUyWuz35toVO6nIS/ZirBJzK1qVVfnepesvSaruO+AokZ+6H7qhkGwrlwuCHfVGuRkqxR7OWvmvreeYbXukcv1g918QkSTL49oeVrMrCnQYlenau+rh0jAL37aXVI59AtSd6bAbqrL0Rimmi0ngL0/42Hyq/yMiEDE6UOGrUvvd670i0Ij8jnbQILqMrL/oYgmz3Gn6pr2s7Y8ubw/KutTYPTqzEys0uiHjCX1SzXno8tWB9sY2BBYwVQ8QNJ/Pm12yUVFf3a4KWWrVWl/Qp51FDaLIKZsgmcOMzsDAFo9cCs1sfwF7DqTNJ44RnVM9cSVqQAjWsQDEA5Wn/HS/ZcCgfyn4jL1RymB5XviThto4yJaThiZcmW8NGHafQ+DIPymZoBOcfLB2ctXTgpEPlQtsRVmcFrcEjAzfl0N7fSlYxA1B/PKoPlxImhORuD6wdzuH5MJxwnM4VadRhgurQimKEtxCYDxO6+HGwTRYwC7F3azPBmZ2a+2NbkyNeKQIjvW3EtgvMOfapAZlTxPHBUk7SyEEcdWVKAD0gYTWEbsk6y+7OuXR0mAzlKyzxU6qmHiL2np8krNFJkEy9BRtAS6Z4ETm0JIWku+f7Jet+pxk8/X+TSLFhDJDfVsbUeBvlsmOyEmafcAGzDh9U4azC7zBP3OYN/y2bLP1mYQJ46CfaFX0w5WYCafC8C8t+cRgd7tZUbl4sovbYny6n9rTqmMgKd827m7OtD/IzRAmaei95bwy/FVF1Gc= x-ms-office365-filtering-correlation-id: 1acdef69-58f2-41b4-6f5a-08d4cee73ae2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR09MB0760; x-ms-traffictypediagnostic: CY1PR09MB0760: x-exchange-antispam-report-test: UriScan:(236129657087228); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR09MB0760; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR09MB0760; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39410400002)(39450400003)(39850400002)(39400400002)(13464003)(377454003)(2900100001)(66066001)(3280700002)(14454004)(5660300001)(6436002)(478600001)(9686003)(3846002)(38730400002)(55016002)(2950100002)(86362001)(99286003)(8936002)(3660700001)(81166006)(7736002)(305945005)(74316002)(2501003)(25786009)(53546010)(76176999)(6506006)(50986999)(230783001)(6246003)(2171002)(229853002)(54356999)(77096006)(189998001)(72206003)(33656002)(2906002)(7696004)(8676002)(102836003)(93886004)(53936002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0760; H:CY1PR09MB0760.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 20:46:28.6299 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0760 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_14:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 20:46:35 -0000 If a service provider wants to provide a binary indication using the draft,= they can, by omitting the 'spam' probability indicator: Call-Info: ... ;purpose=3Dinfo ;type=3Dspam Or Call-Info: ... ;purpose=3Dinfo ;type=3Dpersonal for non-spam. Henning -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com]=20 Sent: Wednesday, July 19, 2017 2:46 PM To: Henning Schulzrinne ; Paul Kyzivat ; sipcore@ietf.org Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities Agreed that this is somewhat about "philosophical aspects of priority". Hav= ing said that, I really feel not content with a fine-granularity indicator = considering how in practice it would/could be generated especially consider= ing all the operator/equipment/call scenario/deployment model combinations.= It would be like, actually worse, than how sausages are prepared. I am not religiously advocating a change toward a binary indicator (i.e. I = wouldn't consider the current model as something "wrong") but IMHO that wou= ld be a more practical way of getting something useful at the end; just my = 2 cents. Thanks, Tolga From nobody Thu Jul 20 09:27:30 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014D2131A67 for ; Thu, 20 Jul 2017 09:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=ham 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 18Vr2jCiO0Hn for ; Thu, 20 Jul 2017 09:27:26 -0700 (PDT) Received: from qproxy6.mail.unifiedlayer.com (unknown [69.89.23.12]) (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 905581315FE for ; Thu, 20 Jul 2017 09:27:26 -0700 (PDT) Received: from CMOut01 (unknown [10.0.90.82]) by qproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 01301140557 for ; Thu, 20 Jul 2017 10:27:21 -0600 (MDT) Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id n4NH1v00r1MNPNq014NLGV; Thu, 20 Jul 2017 10:22:21 -0600 X-Authority-Analysis: v=2.2 cv=DvwmwC3+ c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=G3gG6ho9WtcA:10 a=jqBRFv0mrdUA:10 a=ZZnuYtJkoWoA:10 a=48vgC7mUAAAA:8 a=kUVcWBOSAAAA:8 a=hQ2imU5F7Lge3hgSx4sA:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=KeNNF5xCQ8GJfYwZ:21 a=d8-ki9D_HOqJbLn1:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=2fN0Ut44FUSjvWHL4tab: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=LvwPGh5N3B03OC9R2xx7xCZAMxLqe6NeqkwejbhnbHY=; b=OSMOBGRentvwbSe/OvVh1MG3at VRFHZ5EsQgFuFd8p8oGih6WhEItcwOxn8eSKFioUE9hfcr7FMeQrGEMe043TVnGgkx9SdgOjDCOQU ustrPje/MpyhI8eq2+PTAnF60; Received: from pool-100-36-29-226.washdc.fios.verizon.net ([100.36.29.226]:54567 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.87) (envelope-from ) id 1dYEDR-003pSP-9L; Thu, 20 Jul 2017 10:22:17 -0600 User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Thu, 20 Jul 2017 12:22:15 -0400 From: Richard Shockey To: "Asveren, Tolga" , Henning Schulzrinne , Paul Kyzivat , "sipcore@ietf.org" Message-ID: Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit 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.29.226 X-Exim-ID: 1dYEDR-003pSP-9L X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-29-226.washdc.fios.verizon.net ([192.168.1.152]) [100.36.29.226]:54567 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 16:27:29 -0000 The other issue is who is the intended recipient of the data? Among those of us that are actively evaulating Call Validation Display options we see some differences. What a consumer may need to see is vastly different from what a inbound call center agent or enterprise user should see and should call validation data be combined with other forms of calling party identity in a expanded CNAM (calling party name) like service offering. In the EU for example they have no experience at all with CNAM. That has typically been a North Americian service. I understand the argument for a binary data display such as green check vs red octonganal stop like visual indicator and there are serious nuances in what type of text should be displayed. We are not there yet. We are delving into the black arts of UI design here and we are simply going to have to do some experimentation to come up with answers and even then its clear that one size may not fit all. In any event there is already a thoughtful discussion between the service provider community and some national regulators on what the options are. .. On 7/19/17, 2:46 PM, "sipcore on behalf of Asveren, Tolga" wrote: Agreed that this is somewhat about "philosophical aspects of priority". Having said that, I really feel not content with a fine-granularity indicator considering how in practice it would/could be generated especially considering all the operator/equipment/call scenario/deployment model combinations. It would be like, actually worse, than how sausages are prepared. I am not religiously advocating a change toward a binary indicator (i.e. I wouldn't consider the current model as something "wrong") but IMHO that would be a more practical way of getting something useful at the end; just my 2 cents. Thanks, Tolga -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 19, 2017 2:33 PM To: Asveren, Tolga ; Paul Kyzivat ; sipcore@ietf.org Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities This type of labeling is very common for email spam filters. It's essentially the same as "There's a 47% chance of rain today." Except that meteorologists are smart enough not to say 47%, but rather 50%. It is better than the "According to the polls, candidate H has an 89% chance of winning the election." (Any semblance of initials to real persons has a 1-in-26 chance of being made up.) Theoretically, unlike for elections and somewhat similar to the weather case, this is testable: You could take all the 50% spam or rain predictions, check with some reliable metric (human or rain gauge) whether the spam or rain happened and compare your results, i.e., roughly one in two such predictions should indeed turn out to be spam or rain. (It's more complicated than that, but we're getting pretty close to the philosophical debate of what probabilities mean when making predictions, which is apparently a rather unsettled scientific question.) To actually answer your question: I don't think this is useful except as a rough way for users to trade false-positive/false-negative penalties. For example, they may discard all 80%+ probability calls, route 30-80% calls to voicemail and ring the below-30% calls. The thresholds are arbitrary, but users may tune them based on experience ("all the calls in voicemail were spam, so I can go lower"). Some people pack an umbrella when there's a 20% chance of rain, others are more willing to risk getting wet. By the way, it is well-known that meteorologists over-predict rain since nobody complains if they did not get soaked. Henning -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, Tolga Sent: Wednesday, July 19, 2017 2:11 PM To: Paul Kyzivat ; sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities Let me ask this question then: What would "spam with a likelihood of 47%" mean? Will the specification detail how this percentage need to be calculated? Otherwise how can the end-device take some action based on this value? One could argue that all these are "implementation dependent" but honestly I think this would just create confusion/chaos in practice and likely to be not useful. Thanks, Tolga _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Jul 20 10:17: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 5DF56131C31 for ; Thu, 20 Jul 2017 10:17:22 -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=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 XV6IysvMyVUu for ; Thu, 20 Jul 2017 10:17:14 -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 BF4CA131B4B for ; Thu, 20 Jul 2017 10:17:14 -0700 (PDT) Received: from pps.filterd (m0102173.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6KHED7D004390; Thu, 20 Jul 2017 17:17:11 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0021.outbound.protection.outlook.com [23.103.198.21]) by mx0a-0024ed01.pphosted.com with ESMTP id 2bqbus43de-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 20 Jul 2017 17:17:11 +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=ZDLz+eA3HK5vUkvSfW90I3A7YZBdDg1RI1aWvlOXaLs=; b=iDue+UlZ26e5XSAFjrB44OSBXMvHqACZVbEgkH5yZH3ztRjkYYGE4aZ0TSfGlHHEZj1Kp2QszFOUAXP2KD1J0kqs0aL87RjghObbp6Ly9stg802ZeNfc49X1RqXMP69DJF8se1U2PZYvwYYddLNmCu5ILZUHX2v9g76KJnpjqrA= Received: from CY1PR09MB0760.namprd09.prod.outlook.com (10.161.173.151) by CY1PR09MB0757.namprd09.prod.outlook.com (10.161.173.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Thu, 20 Jul 2017 17:17:10 +0000 Received: from CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) by CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) with mapi id 15.01.1261.024; Thu, 20 Jul 2017 17:17:10 +0000 From: Henning Schulzrinne To: Richard Shockey , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities Thread-Index: AQHS//8f86lEHhh9VUKR5rSbwxo4z6Ja0ofAgABzoYCAAC1loIAAAo2AgAAGWUCAAWxBgIAADIFA Date: Thu, 20 Jul 2017 17:17:09 +0000 Message-ID: References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: shockey.us; dkim=none (message not signed) header.d=none;shockey.us; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [192.104.54.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0757; 7:5WlmKSLg8/c358tX/VY8d5v8s71Gn5Z3wHnSgBX2DpfdotwtD37S4w6W2cDl46zqZZ0q7qQKSddrpSOmVboz3r/mOGSx7z6+jlX9T1ZRvJUPQH4Xm4EO3lR3+UON9XwwVGQGB3ZN36Yw9VkRuPQ8zhe46ssowfKGEY3kcj7BGAZTlgDc3gX1tblIgBxYPtXr3GKsf5iPR6LSZY4OjxZJiWo1UyWCSgH33vEH9y/X9ZViIEffDMXGxBcuJsytdVO5iz1zIHAvMhSGF5JrRlgJ8/BIuoECuPzrkDG9ZmZ2Aw1ftYWm3mDaGPBDwR/OA7GKcCvis3nmkJy4A3riXf5l525a51ecVUegcvV4T7G9T92+sEdhcUChRRRzqgRL9C+QXoBnvXPap5JzCzqMB4FK/iyi0ti6PYH/sBs3zPvyTlGsx+HuIkKhe9EKW7P0/InxC+ncS31/+V5E/SZELAH8imZv07t1OKSYqZVJsCeRvkYlUJPtIgCTQmbJ3ZRfuFR7hUm4D2aIqKDAJk/n9uzderhvpVtpof0mAPc4S//Yxnf9QPnSvIZWnouRRtz6qwFQbI42YtasYQKBgHH5aUIfVEn7r+kY0ojnHxu5Pj1qUOV31OyXrxobdJQX7MG8nz8RrEMCqu7NiQJI1v+5bGVFgKo8qp+ntXNTc7PIaTIVzdKY3TIo+i/fzfysKlsiyS5bvRAHDmi/vmUbYiQBNQu2F+6LtBSsgMUw4/OI7+YY7Z+aQLRUJLO1osIQU53P1xqCwRNWaLpda1/lOhMtKU2El7opVpA5r8pEQfSNm0ZaWQw= x-ms-office365-filtering-correlation-id: ff1e93dc-2d1e-4a6a-8f0b-08d4cf9327ea x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR09MB0757; x-ms-traffictypediagnostic: CY1PR09MB0757: x-exchange-antispam-report-test: UriScan:(133145235818549)(10436049006162)(26388249023172)(236129657087228)(90097320859284)(48057245064654)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR09MB0757; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR09MB0757; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39400400002)(39410400002)(24454002)(13464003)(377454003)(102836003)(2900100001)(229853002)(38730400002)(6436002)(6116002)(3280700002)(230783001)(2906002)(93886004)(45080400002)(189998001)(2950100002)(55016002)(6306002)(74316002)(9686003)(25786009)(53936002)(3660700001)(77096006)(305945005)(6246003)(72206003)(14454004)(7696004)(3846002)(7736002)(99286003)(8676002)(478600001)(53546010)(81166006)(54356999)(5660300001)(2501003)(6506006)(66066001)(33656002)(76176999)(86362001)(8936002)(575784001)(50986999)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0757; H:CY1PR09MB0760.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: 20 Jul 2017 17:17:10.1501 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0757 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-20_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 17:17:22 -0000 VGhlcmUgYXJlIGZvdXIgbGlrZWx5IG1vZGVsczoNCg0KKiB0aGUgY2FsbCB0eXBlIChhbmQgc3Bh bS1xdW90aWVudCkgaW5mb3JtYXRpb24gbWF5IGJlIHNob3duIHRvIHVzZXJzLCBidXQgbW9zdCBs aWtlbHkgd2hlbiByZXZpZXdpbmcgdm9pY2UgbWFpbCwgbm90IGEgcmluZ2luZyBjYWxsICh3aGVy ZSBhIHNpbXBsZSBiaW5hcnkgaW5kaWNhdG9yIGlzIHByb2JhYmx5IG1vcmUgc3VpdGFibGUsIGRl cml2ZWQgZnJvbSBpbmZvcm1hdGlvbiBpbiB0aGUgZHJhZnQsIHBvc3NpYmx5KQ0KKiB2YXJpb3Vz IGVuZCBzeXN0ZW0gY2FsbCBoYW5kbGluZyBhbGdvcml0aG1zLCBlLmcuLCB0aGUgc2VtaS1hdXRv bWF0ZWQgJ2RvIG5vdCBkaXN0dXJiJyBmZWF0dXJlcyBpbiBBbmRyb2lkIGFuZCBpT1MsIHNvIHRo YXQsIGZvciBleGFtcGxlLCBub24tcGVyc29uYWwgY2FsbHMgd291bGQgYmUgZGlyZWN0ZWQgdG8g dm9pY2UgbWFpbCBhZnRlciAxMCBwbSBvciBkdXJpbmcgbWVldGluZ3MuDQoqIFBCWCBhbmQgc2lt aWxhciBjb3Jwb3JhdGUgc3lzdGVtcyB0aGF0IGZpbHRlciBhbmQgbWFuYWdlIGNhbGxzLCB3aGV0 aGVyIGJ5IGNvcnBvcmF0ZSBwb2xpY3kgKGUuZy4sIHRvIHByZXZlbnQgTWljcm9zb2Z0ICJzdXBw b3J0IiBjYWxscykgb3IgYnkgdXNlciBwcmVmZXJlbmNlDQoqIGFzIGEgY2FsbC1vdXQgdG8gYSB0 aGlyZC1wYXJ0eSBzeXN0ZW0gLSB0aGUgY2FsbCBpbmZvcm1hdGlvbiBpcyBwcm94aWVkIHRvIGEg dGhpcmQgcGFydHkgc3lzdGVtLCB3aGljaCB0aGVuIGFkZCB0aGUgY2FsbC1pbmZvIGxhYmVsaW5n IHRvIHRoZSBjYWxsDQoNCkluIGFsbCBjYXNlcywgdGhlIGluZm9ybWF0aW9uIGluIHRoZSBoZWFk ZXIgd291bGQgc2VlbSB0byBiZSwgYXQgbW9zdCwgYmUgaW5kaXJlY3RseSByZWZsZWN0ZWQgaW4g dGhlIGFwcHJvcHJpYXRlIHVzZXIgaW50ZXJmYWNlLiAgQnV0LCBpbiBteSB2aWV3LCB5b3UgbmVl ZCB0byBwcm92aWRlIHRoZSBlbmQgc3lzdGVtIGFuZCBVSSB3aXRoIGEgYml0IG1vcmUgZGF0YSBz byB0aGF0IHRoZXkgY2FuIGRvIHRoZSBmaWx0ZXJpbmcgYW5kIFVJIHRhaWxvcmluZy4gSXQncyBl YXN5IHRvIHR1cm4gYSBzcGFtIHNjb3JlIGludG8gcmVkIGFuZCBncmVlbiwgYnV0IHlvdSBjYW4n dCBzZXQgcmVkIGFuZCBncmVlbiB0aHJlc2hvbGRzIGFwcHJvcHJpYXRlIHRvIHRoZSBjaXJjdW1z dGFuY2VzIGlmIHRoZSBjYXJyaWVyIGhhcyBhbHJlYWR5IG1hZGUgdGhhdCBkZWNpc2lvbi4NCg0K VGhlIENOQU0gaW5mb3JtYXRpb24gc2VlbXMgY29tcGxlbWVudGFyeSB0byB0aGlzLCBhbHRob3Vn aCBpdCBtaWdodCB1c2Ugc29tZSBvZiB0aGUgc2FtZSB0eXBlIGxhYmVsaW5nLiBDTkFNIGFsc28g c2VlbXMgdG8gcmVxdWlyZSBmYXIgbW9yZSBvcmlnaW5hdG9yIGNvb3BlcmF0aW9uIChhbmQgYSBj YWxsZXIgaXMgdW5saWtlbHkgdG8gbGFiZWwgaXRzZWxmIGFzICJzcGFtIi4uLikuDQoNCkhlbm5p bmcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJpY2hhcmQgU2hvY2tleSBb bWFpbHRvOnJpY2hhcmRAc2hvY2tleS51c10gDQpTZW50OiBUaHVyc2RheSwgSnVseSAyMCwgMjAx NyAxMjoyMiBQTQ0KVG86IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb20+OyBI ZW5uaW5nIFNjaHVsenJpbm5lIDxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+OyBQYXVsIEt5 eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT47IHNpcGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbc2lwY29yZV0gZHJhZnQtaWV0Zi1zaXBjb3JlLWNhbGxpbmZvLXNwYW0tMDEgLSBTSVAg ZW50aXRpZXMNCg0KDQoNClRoZSBvdGhlciBpc3N1ZSBpcyB3aG8gaXMgdGhlIGludGVuZGVkIHJl Y2lwaWVudCBvZiB0aGUgZGF0YT8gIEFtb25nIHRob3NlIG9mIHVzIHRoYXQgYXJlIGFjdGl2ZWx5 IGV2YXVsYXRpbmcgQ2FsbCBWYWxpZGF0aW9uIERpc3BsYXkgb3B0aW9ucyB3ZSBzZWUgc29tZSBk aWZmZXJlbmNlcy4gIFdoYXQgYSBjb25zdW1lciBtYXkgbmVlZCB0byBzZWUgaXMgdmFzdGx5IGRp ZmZlcmVudCBmcm9tIHdoYXQgYSBpbmJvdW5kIGNhbGwgY2VudGVyIGFnZW50IG9yIGVudGVycHJp c2UgdXNlciBzaG91bGQgc2VlIGFuZCBzaG91bGQgY2FsbCB2YWxpZGF0aW9uIGRhdGEgYmUgY29t YmluZWQgd2l0aCBvdGhlciBmb3JtcyBvZiBjYWxsaW5nIHBhcnR5IGlkZW50aXR5IGluIGEgZXhw YW5kZWQgIENOQU0gKGNhbGxpbmcgcGFydHkgbmFtZSkgbGlrZSBzZXJ2aWNlIG9mZmVyaW5nLiAg SW4gdGhlIEVVIGZvciBleGFtcGxlIHRoZXkgaGF2ZSBubyBleHBlcmllbmNlIGF0IGFsbCB3aXRo IENOQU0uICBUaGF0IGhhcyB0eXBpY2FsbHkgYmVlbiBhIE5vcnRoIEFtZXJpY2lhbiBzZXJ2aWNl LiANCg0KSSB1bmRlcnN0YW5kIHRoZSBhcmd1bWVudCBmb3IgYSBiaW5hcnkgZGF0YSBkaXNwbGF5 IHN1Y2ggYXMgZ3JlZW4gY2hlY2sgdnMgcmVkIG9jdG9uZ2FuYWwgc3RvcCBsaWtlIHZpc3VhbCBp bmRpY2F0b3IgYW5kIHRoZXJlIGFyZSBzZXJpb3VzIG51YW5jZXMgaW4gd2hhdCB0eXBlIG9mIHRl eHQgc2hvdWxkIGJlIGRpc3BsYXllZC4gV2UgYXJlIG5vdCB0aGVyZSB5ZXQuICAgV2UgYXJlIGRl bHZpbmcgaW50byB0aGUgYmxhY2sgYXJ0cyBvZiBVSSBkZXNpZ24gaGVyZSBhbmQgd2UgYXJlIHNp bXBseSBnb2luZyB0byBoYXZlIHRvIGRvIHNvbWUgZXhwZXJpbWVudGF0aW9uIHRvIGNvbWUgdXAg d2l0aCBhbnN3ZXJzIGFuZCBldmVuIHRoZW4gaXRzIGNsZWFyIHRoYXQgb25lIHNpemUgbWF5IG5v dCBmaXQgYWxsLg0KDQpJbiBhbnkgZXZlbnQgdGhlcmUgaXMgYWxyZWFkeSBhIHRob3VnaHRmdWwg ZGlzY3Vzc2lvbiBiZXR3ZWVuIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIGNvbW11bml0eSBhbmQgc29t ZSBuYXRpb25hbCByZWd1bGF0b3JzIG9uIHdoYXQgdGhlIG9wdGlvbnMgYXJlLg0KDQouLg0KDQpP biA3LzE5LzE3LCAyOjQ2IFBNLCAic2lwY29yZSBvbiBiZWhhbGYgb2YgQXN2ZXJlbiwgVG9sZ2Ei IDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHRhc3ZlcmVuQHNvbnVzbmV0 LmNvbT4gd3JvdGU6DQoNCiAgICBBZ3JlZWQgdGhhdCB0aGlzIGlzIHNvbWV3aGF0IGFib3V0ICJw aGlsb3NvcGhpY2FsIGFzcGVjdHMgb2YgcHJpb3JpdHkiLiBIYXZpbmcgc2FpZCB0aGF0LCBJIHJl YWxseSBmZWVsIG5vdCBjb250ZW50IHdpdGggYSBmaW5lLWdyYW51bGFyaXR5IGluZGljYXRvciBj b25zaWRlcmluZyBob3cgaW4gcHJhY3RpY2UgaXQgd291bGQvY291bGQgYmUgZ2VuZXJhdGVkIGVz cGVjaWFsbHkgY29uc2lkZXJpbmcgYWxsIHRoZSBvcGVyYXRvci9lcXVpcG1lbnQvY2FsbCBzY2Vu YXJpby9kZXBsb3ltZW50IG1vZGVsIGNvbWJpbmF0aW9ucy4gSXQgd291bGQgYmUgbGlrZSwgYWN0 dWFsbHkgd29yc2UsIHRoYW4gaG93IHNhdXNhZ2VzIGFyZSBwcmVwYXJlZC4NCiAgICANCiAgICBJ IGFtIG5vdCByZWxpZ2lvdXNseSBhZHZvY2F0aW5nIGEgY2hhbmdlIHRvd2FyZCBhIGJpbmFyeSBp bmRpY2F0b3IgKGkuZS4gSSB3b3VsZG4ndCBjb25zaWRlciB0aGUgY3VycmVudCBtb2RlbCBhcyBz b21ldGhpbmcgIndyb25nIikgYnV0IElNSE8gdGhhdCB3b3VsZCBiZSBhIG1vcmUgcHJhY3RpY2Fs IHdheSBvZiBnZXR0aW5nIHNvbWV0aGluZyB1c2VmdWwgYXQgdGhlIGVuZDsganVzdCBteSAyIGNl bnRzLg0KICAgIA0KICAgIFRoYW5rcywNCiAgICBUb2xnYQ0KICAgIA0KICAgIC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTogSGVubmluZyBTY2h1bHpyaW5uZSBbbWFpbHRvOkhl bm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdl0gDQogICAgU2VudDogV2VkbmVzZGF5LCBKdWx5IDE5 LCAyMDE3IDI6MzMgUE0NCiAgICBUbzogQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0 LmNvbT47IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1Pjsgc2lwY29yZUBpZXRm Lm9yZw0KICAgIFN1YmplY3Q6IFJFOiBbc2lwY29yZV0gZHJhZnQtaWV0Zi1zaXBjb3JlLWNhbGxp bmZvLXNwYW0tMDEgLSBTSVAgZW50aXRpZXMNCiAgICANCiAgICBUaGlzIHR5cGUgb2YgbGFiZWxp bmcgaXMgdmVyeSBjb21tb24gZm9yIGVtYWlsIHNwYW0gZmlsdGVycy4gSXQncyBlc3NlbnRpYWxs eSB0aGUgc2FtZSBhcyAiVGhlcmUncyBhIDQ3JSBjaGFuY2Ugb2YgcmFpbiB0b2RheS4iIEV4Y2Vw dCB0aGF0IG1ldGVvcm9sb2dpc3RzIGFyZSBzbWFydCBlbm91Z2ggbm90IHRvIHNheSA0NyUsIGJ1 dCByYXRoZXIgNTAlLg0KICAgIA0KICAgIEl0IGlzIGJldHRlciB0aGFuIHRoZSAiQWNjb3JkaW5n IHRvIHRoZSBwb2xscywgY2FuZGlkYXRlIEggaGFzIGFuIDg5JSBjaGFuY2Ugb2Ygd2lubmluZyB0 aGUgZWxlY3Rpb24uIiAoQW55IHNlbWJsYW5jZSBvZiBpbml0aWFscyB0byByZWFsIHBlcnNvbnMg aGFzIGEgMS1pbi0yNiBjaGFuY2Ugb2YgYmVpbmcgbWFkZSB1cC4pDQogICAgDQogICAgVGhlb3Jl dGljYWxseSwgdW5saWtlIGZvciBlbGVjdGlvbnMgYW5kIHNvbWV3aGF0IHNpbWlsYXIgdG8gdGhl IHdlYXRoZXIgY2FzZSwgdGhpcyBpcyB0ZXN0YWJsZTogWW91IGNvdWxkIHRha2UgYWxsIHRoZSA1 MCUgc3BhbSBvciByYWluIHByZWRpY3Rpb25zLCBjaGVjayB3aXRoIHNvbWUgcmVsaWFibGUgbWV0 cmljIChodW1hbiBvciByYWluIGdhdWdlKSB3aGV0aGVyIHRoZSBzcGFtIG9yIHJhaW4gaGFwcGVu ZWQgYW5kIGNvbXBhcmUgeW91ciByZXN1bHRzLCBpLmUuLCByb3VnaGx5IG9uZSBpbiB0d28gc3Vj aCBwcmVkaWN0aW9ucyBzaG91bGQgaW5kZWVkIHR1cm4gb3V0IHRvIGJlIHNwYW0gb3IgcmFpbi4g KEl0J3MgbW9yZSBjb21wbGljYXRlZCB0aGFuIHRoYXQsIGJ1dCB3ZSdyZSBnZXR0aW5nIHByZXR0 eSBjbG9zZSB0byB0aGUgcGhpbG9zb3BoaWNhbCBkZWJhdGUgb2Ygd2hhdCBwcm9iYWJpbGl0aWVz IG1lYW4gd2hlbiBtYWtpbmcgcHJlZGljdGlvbnMsIHdoaWNoIGlzIGFwcGFyZW50bHkgYSByYXRo ZXIgdW5zZXR0bGVkIHNjaWVudGlmaWMgcXVlc3Rpb24uKQ0KICAgIA0KICAgIFRvIGFjdHVhbGx5 IGFuc3dlciB5b3VyIHF1ZXN0aW9uOiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgdXNlZnVsIGV4Y2Vw dCBhcyBhIHJvdWdoIHdheSBmb3IgdXNlcnMgdG8gdHJhZGUgZmFsc2UtcG9zaXRpdmUvZmFsc2Ut bmVnYXRpdmUgcGVuYWx0aWVzLiBGb3IgZXhhbXBsZSwgdGhleSBtYXkgZGlzY2FyZCBhbGwgODAl KyBwcm9iYWJpbGl0eSBjYWxscywgcm91dGUgMzAtODAlIGNhbGxzIHRvIHZvaWNlbWFpbCBhbmQg cmluZyB0aGUgYmVsb3ctMzAlIGNhbGxzLiBUaGUgdGhyZXNob2xkcyBhcmUgYXJiaXRyYXJ5LCBi dXQgdXNlcnMgbWF5IHR1bmUgdGhlbSBiYXNlZCBvbiBleHBlcmllbmNlICgiYWxsIHRoZSBjYWxs cyBpbiB2b2ljZW1haWwgd2VyZSBzcGFtLCBzbyBJIGNhbiBnbyBsb3dlciIpLg0KICAgIA0KICAg IFNvbWUgcGVvcGxlIHBhY2sgYW4gdW1icmVsbGEgd2hlbiB0aGVyZSdzIGEgMjAlIGNoYW5jZSBv ZiByYWluLCBvdGhlcnMgYXJlIG1vcmUgd2lsbGluZyB0byByaXNrIGdldHRpbmcgd2V0LiBCeSB0 aGUgd2F5LCBpdCBpcyB3ZWxsLWtub3duIHRoYXQgbWV0ZW9yb2xvZ2lzdHMgb3Zlci1wcmVkaWN0 IHJhaW4gc2luY2Ugbm9ib2R5IGNvbXBsYWlucyBpZiB0aGV5IGRpZCBub3QgZ2V0IHNvYWtlZC4N CiAgICANCiAgICBIZW5uaW5nDQogICAgDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CiAgICBGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQXN2ZXJlbiwgVG9sZ2ENCiAgICBTZW50OiBXZWRuZXNkYXksIEp1bHkgMTksIDIw MTcgMjoxMSBQTQ0KICAgIFRvOiBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT47 IHNpcGNvcmVAaWV0Zi5vcmcNCiAgICBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIGRyYWZ0LWlldGYt c2lwY29yZS1jYWxsaW5mby1zcGFtLTAxIC0gU0lQIGVudGl0aWVzDQogICAgDQogICAgTGV0IG1l IGFzayB0aGlzIHF1ZXN0aW9uIHRoZW46DQogICAgV2hhdCB3b3VsZCAic3BhbSB3aXRoIGEgbGlr ZWxpaG9vZCBvZiA0NyUiIG1lYW4/IFdpbGwgdGhlIHNwZWNpZmljYXRpb24gZGV0YWlsIGhvdyB0 aGlzIHBlcmNlbnRhZ2UgbmVlZCB0byBiZSBjYWxjdWxhdGVkPyBPdGhlcndpc2UgaG93IGNhbiB0 aGUgZW5kLWRldmljZSB0YWtlIHNvbWUgYWN0aW9uIGJhc2VkIG9uIHRoaXMgdmFsdWU/IE9uZSBj b3VsZCBhcmd1ZSB0aGF0IGFsbCB0aGVzZSBhcmUgImltcGxlbWVudGF0aW9uIGRlcGVuZGVudCIg YnV0IGhvbmVzdGx5IEkgdGhpbmsgdGhpcyB3b3VsZCBqdXN0IGNyZWF0ZSBjb25mdXNpb24vY2hh b3MgaW4gcHJhY3RpY2UgYW5kIGxpa2VseSB0byBiZSBub3QgdXNlZnVsLg0KICAgIA0KICAgIFRo YW5rcywNCiAgICBUb2xnYQ0KICAgICANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIHNpcGNvcmUgbWFpbGluZyBsaXN0DQogICAg c2lwY29yZUBpZXRmLm9yZw0KICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fc2lwY29yZSZk PUR3SUNhUSZjPXkwaDBvbUNlMGpBVUdyNGdBUTAyRncmcj1GSmNWb0RrV001RWlWY1YwUmVYOGxE VTFYZUhJWVJIZmFycGs0TUs1OVJFJm09QjRlSjFQS211ZU5oS0hlZTdVbnM4U3ZMNEV3UmdwLUE5 OHRRT0xXd0wyZyZzPTA2TFVXWWFJWXVxWUNsNU5TbzhPTlBCa1I3eVdGeWMtOGx4VWxWVE95V0km ZT0gDQogICAgDQoNCg0K From nobody Thu Jul 20 11:41:17 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C37131B7A for ; Thu, 20 Jul 2017 11:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lk6YV46YWoPE for ; Thu, 20 Jul 2017 11:41:14 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E84127342 for ; Thu, 20 Jul 2017 11:41:14 -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=TxsmaC0cQ+APkLthodel/ZZfNvoqbYREP//Hg2N7o9g=; b=KBzpvm0OsSzpk/kJyA9EsmK+rQ2iNFS2Uce/gR6kiMs3VKYSzrTAk9GrZWH2a3OPgSDNlV+0cjGcpFfZ1y0SJ8yfB9U949+4xd6v4bJW04Pshyo++lhroVPYL4jDSETJ+7xmmfDV0fciQEU1GmgHP/mc/YqlUFYcdfMv1XoyUF4= Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0047.outbound.protection.outlook.com [207.46.163.47]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-133-SiWgY-KhNVODmTLgAyxPTQ-1; Thu, 20 Jul 2017 14:41:11 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB015.namprd03.prod.outlook.com (10.255.175.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.15; Thu, 20 Jul 2017 18:41:07 +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.1282.011; Thu, 20 Jul 2017 18:41:07 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities Thread-Index: AQHS//8f86lEHhh9VUKR5rSbwxo4z6Ja0ofAgABzoYCAAC1loIAAAo2AgAAGWUCAACJWAIABaRBw Date: Thu, 20 Jul 2017 18:41:07 +0000 Message-ID: References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> 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; SN2PR03MB015; 20:U7xMGTV7V/cOwzSriC+JOCi3eLtHNBCYRMuzMpNDAsITG4TI5bmNPv3HhQE7GsbcIRVm9KrQLuil7Cis0qXi9ids6ytx9H5Q8pbDYYvlZid74swSGudNN8lnlCWZUaDixRcYpZZSEUbTVqBHD6/VUzQTNwrOSyiOlU2sLVA2s/w= x-ms-office365-filtering-correlation-id: 1c4e7579-53af-43cc-9e64-08d4cf9ee25a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR03MB015; x-ms-traffictypediagnostic: SN2PR03MB015: x-exchange-antispam-report-test: UriScan:(236129657087228); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB015; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB015; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39410400002)(39830400002)(39450400003)(13464003)(377454003)(478600001)(25786009)(7696004)(54356999)(55016002)(93886004)(6506006)(33656002)(76176999)(77096006)(50986999)(229853002)(6436002)(305945005)(8676002)(74316002)(230783001)(189998001)(9686003)(5660300001)(38730400002)(53936002)(6246003)(3846002)(86362001)(81166006)(2171002)(8936002)(102836003)(66066001)(6116002)(2900100001)(2950100002)(3660700001)(7736002)(53546010)(2906002)(3280700002)(99286003)(2501003)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB015; 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: 20 Jul 2017 18:41:07.4517 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB015 X-MC-Unique: SiWgY-KhNVODmTLgAyxPTQ-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 18:41:16 -0000 O.K., this sounds good. It really could be good to add a sentence or two ab= out this issue -even if the syntax already defines "spam" as optional"- tho= ugh. "Use of spam parameter requires a fine granularity decision about the natur= e of the call. It may not be possible to easily predict or use in an effici= ent way for certain networks, call flows, end-points." Thanks, Tolga -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Wednesday, July 19, 2017 4:46 PM To: Asveren, Tolga ; Paul Kyzivat ; sipcore@ietf.org Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities If a service provider wants to provide a binary indication using the draft,= they can, by omitting the 'spam' probability indicator: Call-Info: ... ;purpose=3Dinfo ;type=3Dspam Or Call-Info: ... ;purpose=3Dinfo ;type=3Dpersonal for non-spam. Henning -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com]=20 Sent: Wednesday, July 19, 2017 2:46 PM To: Henning Schulzrinne ; Paul Kyzivat ; sipcore@ietf.org Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities Agreed that this is somewhat about "philosophical aspects of priority". Hav= ing said that, I really feel not content with a fine-granularity indicator = considering how in practice it would/could be generated especially consider= ing all the operator/equipment/call scenario/deployment model combinations.= It would be like, actually worse, than how sausages are prepared. I am not religiously advocating a change toward a binary indicator (i.e. I = wouldn't consider the current model as something "wrong") but IMHO that wou= ld be a more practical way of getting something useful at the end; just my = 2 cents. Thanks, Tolga From nobody Thu Jul 20 12:21:42 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8FE131BA1 for ; Thu, 20 Jul 2017 12:21:40 -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=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 O-p89VqxEuOz for ; Thu, 20 Jul 2017 12:21:38 -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 71346131B9D for ; Thu, 20 Jul 2017 12:21:38 -0700 (PDT) Received: from pps.filterd (m0102173.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6KJJi3N012357; Thu, 20 Jul 2017 19:21:34 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0019.outbound.protection.outlook.com [23.103.198.19]) by mx0a-0024ed01.pphosted.com with ESMTP id 2bqbus46d2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 20 Jul 2017 19:21:34 +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=4gLI7oaaPqNm6MI4q4Bx4boZgc+DycEmDNaA0GLck/4=; b=WxbZLSifhG95jTNGTfiXyw7wyLqRyzrOuy4UVuMvUzi35EpVHhcsvdU9IvOg0y43kiLZwnFAtCu6Jt941k6ffCUSqEIEKrllkJRKn7MJkloYyOo7DRZg2gDAP5qhhLzGf6/ONFxcl7O4QHoyafcc+LWvUmX5FrfnZ8yNfpxqagM= Received: from CY1PR09MB0760.namprd09.prod.outlook.com (10.161.173.151) by CY1PR09MB0758.namprd09.prod.outlook.com (10.161.173.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Thu, 20 Jul 2017 19:21:33 +0000 Received: from CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) by CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) with mapi id 15.01.1261.024; Thu, 20 Jul 2017 19:21:32 +0000 From: Henning Schulzrinne To: "Asveren, Tolga" , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities Thread-Index: AQHS//8f86lEHhh9VUKR5rSbwxo4z6Ja0ofAgABzoYCAAC1loIAAAo2AgAAGWUCAACJWAIABaRBwgAASotA= Date: Thu, 20 Jul 2017 19:21:32 +0000 Message-ID: References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sonusnet.com; dkim=none (message not signed) header.d=none;sonusnet.com; dmarc=none action=none header.from=fcc.gov; x-originating-ip: [192.104.54.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0758; 7:KvVIvA5wASiPvwYk816h30paKgngCTNWUlIdC0PwR7jo//1ilcQJ04T4L2GEeDJ4VhZLH2g5ebBzwxtPgQjW8jyUvX27laKC2dwkCn08L49LETfwOGJxUrxQ+MhGv3ELB03U76EnvSUxTqBoBSg/ovzGOnBjE+FM9CcojaSX4CSQBmixHH06UVKquEIs4C36WrQ0EiglSkjXBoU1Io+nddZYfEbalqpkALzdpd4pg0SRKLCbXvm939K6JnB1Dd9UaN0Za7+kiB2iI48f8dGL8LntC7yTRvlIEX/b+KRMaF5o7rymHr4OoCX9Nmm0nTx16MwUCEnCDS8HVMycLVDgu4zm++2miXgBRVtLywMmY2ytsWJFCZXVbBEh2VFm7sjVh3oP1dEawIHht0Q32QhK07XZJH32BrFfKjLyPqzUkWF69IW4UV5aaY46FaO6w1IQk3cLJZnKpjDqqvcFRIqUtS6RnH1kD2wALMmW+Df6kjHERu6IsA8xY9DzO1ODMct8sv3BOcFM14BLMbVKCI7kHO0tjMHkbBExJdV89PTk4Mi8hG8CKXlAE9O9EFCxn4vXMBIQPMPCixSL4BEr5vKLR0MwQRlIpm00+EucfYhGRdbLChx4DQAwHVcfizWpmiYAsoaEAfL+iOnrU6IDJp5KWNT56M1uHVWlbCtOgQ6arUZAxP09yKWljflRrKfWEW0sQX+s9Ri22+KfmImfeE8IN8WvHb+IWAaU2Spk2FkOn3pV249NArmyqsewYpFdm0dhexanLvO1jdC9maUb6pTE7c1vUSbXpZfLRKIA1OJ9tXE= x-ms-office365-filtering-correlation-id: f12aa2fc-cad6-4358-d642-08d4cfa487db x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR09MB0758; x-ms-traffictypediagnostic: CY1PR09MB0758: x-exchange-antispam-report-test: UriScan:(236129657087228); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR09MB0758; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR09MB0758; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39400400002)(39410400002)(39840400002)(39450400003)(377454003)(13464003)(55016002)(93886004)(76176999)(6116002)(3846002)(25786009)(54356999)(66066001)(102836003)(3660700001)(3280700002)(2906002)(6246003)(53936002)(9686003)(6436002)(7696004)(53546010)(72206003)(230783001)(38730400002)(2171002)(74316002)(8936002)(33656002)(81166006)(2501003)(8676002)(14454004)(5660300001)(99286003)(77096006)(229853002)(50986999)(189998001)(7736002)(86362001)(6506006)(478600001)(2950100002)(2900100001)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0758; H:CY1PR09MB0760.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 19:21:32.5437 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0758 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-20_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 19:21:41 -0000 It does say explicitly that all parameters are optional, but I will add tex= t about what the absence means ("good enough", basically, since no indicato= r is 100% correct). -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com]=20 Sent: Thursday, July 20, 2017 2:41 PM To: Henning Schulzrinne ; Paul Kyzivat ; sipcore@ietf.org Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities O.K., this sounds good. It really could be good to add a sentence or two ab= out this issue -even if the syntax already defines "spam" as optional"- tho= ugh. "Use of spam parameter requires a fine granularity decision about the natur= e of the call. It may not be possible to easily predict or use in an effici= ent way for certain networks, call flows, end-points." Thanks, Tolga From nobody Thu Jul 20 12:38:30 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D0112F299 for ; Thu, 20 Jul 2017 12:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham 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 jMRnZIJoWWXZ for ; Thu, 20 Jul 2017 12:38:26 -0700 (PDT) Received: from qproxy1.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) (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 D19B31293E1 for ; Thu, 20 Jul 2017 12:38:25 -0700 (PDT) Received: from cmgw2 (unknown [10.0.90.83]) by qproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 015CE120B45 for ; Thu, 20 Jul 2017 13:38:21 -0600 (MDT) Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id n7ZH1v00t1MNPNq017ZL4F; Thu, 20 Jul 2017 13:33:21 -0600 X-Authority-Analysis: v=2.2 cv=UvYTD64B c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=G3gG6ho9WtcA:10 a=jqBRFv0mrdUA:10 a=ZZnuYtJkoWoA:10 a=kUVcWBOSAAAA:8 a=48vgC7mUAAAA:8 a=RpNjiQI2AAAA:8 a=kNH0ug7cwpVFfZga6P0A:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=jpIH26JlB8aEU1M81S3jpgcb7nU=:19 a=hpEB6L2-uw6rD9M2:21 a=YaV9uFvTcuK7wi6V:21 a=QEXdDO2ut3YA:10 a=2fN0Ut44FUSjvWHL4tab:22 a=w1C3t2QeGrPiZgrLijVG:22 a=vJuR_VyAocOa-HWBgGQO: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=CpFVKoJzldF1UEtbH8xgL6woM3dBGbElzVb7jfpJJaY=; b=j0abCmcPxFyYBMqGLNrYU/Elml U+p5ewUOaxKDIdciL4Gu/2b9notIgG/w5wTrVfvZoDyjn0NiWJlY9lQv9bxqz3e7R1AAGVAz4RswH OqlECu4gpvUv2htT2vlquDaC6; Received: from pool-100-36-29-226.washdc.fios.verizon.net ([100.36.29.226]:51383 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.87) (envelope-from ) id 1dYHCH-000mZQ-J9; Thu, 20 Jul 2017 13:33:17 -0600 User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Thu, 20 Jul 2017 15:33:15 -0400 From: Richard Shockey To: Henning Schulzrinne , "sipcore@ietf.org" Message-ID: <8542D641-AE8F-4134-B357-017DC6F73E5F@shockey.us> Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> In-Reply-To: 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.29.226 X-Exim-ID: 1dYHCH-000mZQ-J9 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-29-226.washdc.fios.verizon.net ([192.168.1.152]) [100.36.29.226]:51383 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 19:38:29 -0000 In line.. On 7/20/17, 1:17 PM, "Henning Schulzrinne" wr= ote: There are four likely models: =20 * the call type (and spam-quotient) information may be shown to users, = but most likely when reviewing voice mail, not a ringing call (where a simpl= e binary indicator is probably more suitable, derived from information in th= e draft, possibly) RS> That=E2=80=99s what I=E2=80=99ve been thinking. The binary indicator is most usef= ul during ringing and that is the 2-3 seconds you have when you look at the = UA. Some Data Analytics vendors have indicated there is zero difference in = consumer behavior on binary display (good vs bad red vs green) vs granular s= coring (0-100) display for instance. This is really the VERISAT 3GPP parame= ter for inband SIP usage vs some other out of band transmittal (HTTP) to the= UA.=20 * various end system call handling algorithms, e.g., the semi-automated= 'do not disturb' features in Android and iOS, so that, for example, non-per= sonal calls would be directed to voice mail after 10 pm or during meetings. RS> Agreed but I=E2=80=99m not sure how much UA programming people can actually h= andle. Of course, we can program pretty much anything we want into the UA at= this point. But some of this may be network or proxy (PBX) based as well.=20 * PBX and similar corporate systems that filter and manage calls, wheth= er by corporate policy (e.g., to prevent Microsoft "support" calls) or by us= er preference. * as a call-out to a third-party system - the call information is proxi= ed to a third party system, which then add the call-info labeling to the cal= l RS> These may be closely bound. Its clear at least from some discussions I= =E2=80=99ve had with enterprises that they may want to manage this process themsel= ves for various legal and regulatory concerns. There are clearly early adop= ter industries. Financial Services, Health Care and Utilities where these te= chniques come under the general heading of =E2=80=9Creputation management=E2=80=9D and f= raud protection. There is another use case involving public safety that has= been barely touched.=20 =20 In all cases, the information in the header would seem to be, at most, = be indirectly reflected in the appropriate user interface. But, in my view,= you need to provide the end system and UI with a bit more data so that they= can do the filtering and UI tailoring. It's easy to turn a spam score into = red and green, but you can't set red and green thresholds appropriate to the= circumstances if the carrier has already made that decision. RS> Sure but this is ultimately a consumer / enterprise decision on who doe= s what to analyze the call. My guess is most consumers (98%) would want the= carrier to deal with it. That=E2=80=99s what we pay them for and life is too com= plicated as it is. Enterprises, especially those that rely on various forms= of voice communications for mission critical applications may take a differ= ent view. I suspect many of them do not want to rely on carrier data analyt= ics if they are to be held liable for the consequences. If we can properly = define a limited set of tools then the market will sort out the gory details= . The good news here is that there is a ready market for these solutions if= we can define to tool kit correctly. =20 =20 The CNAM information seems complementary to this, although it might use= some of the same type labeling. CNAM also seems to require far more origina= tor cooperation (and a caller is unlikely to label itself as "spam"...). RS> Agreed. =E2=80=9CEmpower Consumers=E2=80=9D as you colleague=E2=80=99s on 12th street wo= uld call it. (=20 =20 Henning =20 -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: Thursday, July 20, 2017 12:22 PM To: Asveren, Tolga ; Henning Schulzrinne ; Paul Kyzivat ; sipcore@ietf.o= rg Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entiti= es =20 =20 =20 The other issue is who is the intended recipient of the data? Among th= ose of us that are actively evaulating Call Validation Display options we se= e some differences. What a consumer may need to see is vastly different fro= m what a inbound call center agent or enterprise user should see and should = call validation data be combined with other forms of calling party identity = in a expanded CNAM (calling party name) like service offering. In the EU f= or example they have no experience at all with CNAM. That has typically bee= n a North Americian service.=20 =20 I understand the argument for a binary data display such as green check= vs red octonganal stop like visual indicator and there are serious nuances = in what type of text should be displayed. We are not there yet. We are del= ving into the black arts of UI design here and we are simply going to have t= o do some experimentation to come up with answers and even then its clear th= at one size may not fit all. =20 In any event there is already a thoughtful discussion between the servi= ce provider community and some national regulators on what the options are. =20 .. =20 On 7/19/17, 2:46 PM, "sipcore on behalf of Asveren, Tolga" wrote: =20 Agreed that this is somewhat about "philosophical aspects of priori= ty". Having said that, I really feel not content with a fine-granularity ind= icator considering how in practice it would/could be generated especially co= nsidering all the operator/equipment/call scenario/deployment model combinat= ions. It would be like, actually worse, than how sausages are prepared. =20 I am not religiously advocating a change toward a binary indicator = (i.e. I wouldn't consider the current model as something "wrong") but IMHO t= hat would be a more practical way of getting something useful at the end; ju= st my 2 cents. =20 Thanks, Tolga =20 -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Wednesday, July 19, 2017 2:33 PM To: Asveren, Tolga ; Paul Kyzivat ; sipcore@ietf.org Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP en= tities =20 This type of labeling is very common for email spam filters. It's e= ssentially the same as "There's a 47% chance of rain today." Except that met= eorologists are smart enough not to say 47%, but rather 50%. =20 It is better than the "According to the polls, candidate H has an 8= 9% chance of winning the election." (Any semblance of initials to real perso= ns has a 1-in-26 chance of being made up.) =20 Theoretically, unlike for elections and somewhat similar to the wea= ther case, this is testable: You could take all the 50% spam or rain predict= ions, check with some reliable metric (human or rain gauge) whether the spam= or rain happened and compare your results, i.e., roughly one in two such pr= edictions should indeed turn out to be spam or rain. (It's more complicated = than that, but we're getting pretty close to the philosophical debate of wha= t probabilities mean when making predictions, which is apparently a rather u= nsettled scientific question.) =20 To actually answer your question: I don't think this is useful exce= pt as a rough way for users to trade false-positive/false-negative penalties= . For example, they may discard all 80%+ probability calls, route 30-80% cal= ls to voicemail and ring the below-30% calls. The thresholds are arbitrary, = but users may tune them based on experience ("all the calls in voicemail wer= e spam, so I can go lower"). =20 Some people pack an umbrella when there's a 20% chance of rain, oth= ers are more willing to risk getting wet. By the way, it is well-known that = meteorologists over-predict rain since nobody complains if they did not get = soaked. =20 Henning =20 -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asvere= n, Tolga Sent: Wednesday, July 19, 2017 2:11 PM To: Paul Kyzivat ; sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP en= tities =20 Let me ask this question then: What would "spam with a likelihood of 47%" mean? Will the specifica= tion detail how this percentage need to be calculated? Otherwise how can the= end-device take some action based on this value? One could argue that all t= hese are "implementation dependent" but honestly I think this would just cre= ate confusion/chaos in practice and likely to be not useful. =20 Thanks, Tolga =20 =20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ailman_listinfo_sipcore&d=3DDwICaQ&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0= ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DB4eJ1PKmueNhKHee7Uns8SvL4EwRgp-A98tQOLWwL2g&s=3D= 06LUWYaIYuqYCl5NSo8ONPBkR7yWFyc-8lxUlVTOyWI&e=3D=20 =20 =20 =20 =20 From nobody Thu Jul 20 13:12: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 C8776131B90 for ; Thu, 20 Jul 2017 13:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 FJeBl0vQSDZz for ; Thu, 20 Jul 2017 13:12:43 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id C2565131B78 for ; Thu, 20 Jul 2017 13:12:43 -0700 (PDT) X-AuditID: 12074413-281ff70000001b03-c5-59710ebacdbd Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id D7.9C.06915.ABE01795; Thu, 20 Jul 2017 16:12:42 -0400 (EDT) Received: from [192.168.1.110] (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v6KKCgq0017268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 20 Jul 2017 16:12:42 -0400 To: sipcore@ietf.org References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> <8542D641-AE8F-4134-B357-017DC6F73E5F@shockey.us> From: Paul Kyzivat Message-ID: <15895f11-85c0-70ab-9cc1-e7b5943e2549@alum.mit.edu> Date: Thu, 20 Jul 2017 16:12:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8542D641-AE8F-4134-B357-017DC6F73E5F@shockey.us> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixO6iqLubrzDSYNMTZouvPzaxOTB6LFny kymAMYrLJiU1J7MstUjfLoEr41j3d6aCq9wVT/9cYWxgnMvZxcjJISFgInHnxn/mLkYuDiGB HUwSR6fdZwdJCAm8YZJom8EKYgsLeEp0rX3KDGKLCIhIPJv+jw2iYSarxOIn3YwgCTYBLYk5 h/6zgNi8AvYSfxecB2tgEVCVmHXwFthQUYE0iRnfrzND1AhKnJz5BKyeU8BO4tPRV2wgNrOA mcS8zQ+ZIWxxiVtP5jNB2PISzVtnM09g5J+FpH0WkpZZSFpmIWlZwMiyilEuMac0Vzc3MTOn ODVZtzg5MS8vtUjXXC83s0QvNaV0EyMkLIV3MO46KXeIUYCDUYmHl2FdQaQQa2JZcWXuIUZJ DiYlUV6WQKAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd7TX4FyvCmJlVWpRfkwKWkOFiVxXrUl 6n5CAumJJanZqakFqUUwWRkODiUJ3v28hZFCgkWp6akVaZk5JQhpJg5OkOE8QMP/gtTwFhck 5hZnpkPkTzHqcvyaufULkxBLXn5eqpQ4734eoCIBkKKM0jy4ObB08opRHOgtYV4JYHIR4gGm IrhJr4CWMAEteeQG8kFxSSJCSqqBUYPn9OPT1psW7Po7W2v35Lknn7w8f/D7nrCjf4WX3xQ1 PrSuVtGxOUPvwifPf9YKG1Vk81LX1bcu/Zdn4/2CdenqnG0T2qIuntuT5r52iZJjyA8hM/cZ ZQzN1w6fqlr/Mbq8W/5izYSSY41yx8M2RS6vMxNSE3NqfnSAZRZXa1VgdNaDvbMNFymxFGck GmoxFxUnAgBh4STmAgMAAA== Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 20:12:45 -0000 On 7/20/17 3:33 PM, Richard Shockey wrote: > There are four likely models: > > * the call type (and spam-quotient) information may be shown to users, but most likely when reviewing voice mail, not a ringing call (where a simple binary indicator is probably more suitable, derived from information in the draft, possibly) > > RS> That’s what I’ve been thinking. The binary indicator is most useful during ringing and that is the 2-3 seconds you have when you look at the UA. Some Data Analytics vendors have indicated there is zero difference in consumer behavior on binary display (good vs bad red vs green) vs granular scoring (0-100) display for instance. This is really the VERISAT 3GPP parameter for inband SIP usage vs some other out of band transmittal (HTTP) to the UA. Ring tones could be used to indicate more than a binary choice while remaining easy and quick to understand. > RS> Sure but this is ultimately a consumer / enterprise decision on who does what to analyze the call. My guess is most consumers (98%) would want the carrier to deal with it. That’s what we pay them for and life is too complicated as it is. Speak for yourself. Admittedly perhaps everyone reading this will fall within the 2%. But lots of people are already familiar with configuring their ring tones and dialer. It is not at all hard to imagine quite a lot of people (at least those < 30 years old) wanting to tweak this stuff. Thanks, Paul From nobody Thu Jul 20 14:09: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 4C75B12714F for ; Thu, 20 Jul 2017 14:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham 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 mLz53NZ8BxVc for ; Thu, 20 Jul 2017 14:08:59 -0700 (PDT) Received: from qproxy3.mail.unifiedlayer.com (qproxy3-pub.mail.unifiedlayer.com [67.222.38.20]) (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 87E2E1201F2 for ; Thu, 20 Jul 2017 14:08:59 -0700 (PDT) Received: from cmgw2 (unknown [10.0.90.83]) by qproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 0207AD60CD for ; Thu, 20 Jul 2017 15:08:59 -0600 (MDT) Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id n93v1v01X1MNPNq0193yBc; Thu, 20 Jul 2017 15:03:59 -0600 X-Authority-Analysis: v=2.2 cv=IqBuSP3g c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=G3gG6ho9WtcA:10 a=jqBRFv0mrdUA:10 a=ZZnuYtJkoWoA:10 a=48vgC7mUAAAA:8 a=HXqRbPrG5ElX3qFbnnMA:9 a=u2gVz7fNhMuur0Mb:21 a=_42CMPBoz19_EvoC:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG: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=B+Mm3WWpDD5UJHEBdynuosJK/3hFY7tER6vrS1kHy5k=; b=kbr5B1KCG+1iSTBAUKgNbi+US/ Z3JIo9JfryHH9WcQGtquN8FngIwD0nIq8AQfTSCfJMX5FS7YXMZNj4Df7Q3zcMAxkL24U+LUROgUH 6w2X5vi9Es+ehnpL/vBkfLRVj; Received: from pool-100-36-29-226.washdc.fios.verizon.net ([100.36.29.226]:53739 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.87) (envelope-from ) id 1dYIbz-001SVQ-NV; Thu, 20 Jul 2017 15:03:55 -0600 User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Thu, 20 Jul 2017 17:03:54 -0400 From: Richard Shockey To: Paul Kyzivat , Message-ID: <5D4E83A0-7B5E-4DC9-B8CD-A89B0C7F22B0@shockey.us> Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> <8542D641-AE8F-4134-B357-017DC6F73E5F@shockey.us> <15895f11-85c0-70ab-9cc1-e7b5943e2549@alum.mit.edu> In-Reply-To: <15895f11-85c0-70ab-9cc1-e7b5943e2549@alum.mit.edu> 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.29.226 X-Exim-ID: 1dYIbz-001SVQ-NV X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-29-226.washdc.fios.verizon.net ([192.168.1.152]) [100.36.29.226]:53739 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 21:09:01 -0000 On 7/20/17, 4:12 PM, "sipcore on behalf of Paul Kyzivat" wrote: On 7/20/17 3:33 PM, Richard Shockey wrote: =20 > There are four likely models: > =20 > * the call type (and spam-quotient) information may be shown to = users, but most likely when reviewing voice mail, not a ringing call (where = a simple binary indicator is probably more suitable, derived from informatio= n in the draft, possibly) >=20 > RS> That=E2=80=99s what I=E2=80=99ve been thinking. The binary indicator is mos= t useful during ringing and that is the 2-3 seconds you have when you look a= t the UA. Some Data Analytics vendors have indicated there is zero differen= ce in consumer behavior on binary display (good vs bad red vs green) vs gran= ular scoring (0-100) display for instance. This is really the VERISAT 3GPP = parameter for inband SIP usage vs some other out of band transmittal (HTTP) = to the UA. =20 Ring tones could be used to indicate more than a binary choice while=20 remaining easy and quick to understand. RS> Humm that=E2=80=99s a good point. It is something to consider especially fo= r those with visual impairments. =E2=80=9CWarning Will Robinson=E2=80=9D Seriously its = an important consideration. =20 =20 > RS> Sure but this is ultimately a consumer / enterprise decision on w= ho does what to analyze the call. My guess is most consumers (98%) would wa= nt the carrier to deal with it. That=E2=80=99s what we pay them for and life is t= oo complicated as it is. =20 =20 Speak for yourself. Admittedly perhaps everyone reading this will fall=20 within the 2%. But lots of people are already familiar with configuring= =20 their ring tones and dialer. It is not at all hard to imagine quite a=20 lot of people (at least those < 30 years old) wanting to tweak this stu= ff. RS> Fair enough. Choice is fine until someone screws up and you cant find = the =E2=80=9Creset to default=E2=80=9D button. =20 =20 Thanks, Paul =20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =20 From nobody Thu Jul 20 15:18: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 8A1FE129AFF for ; Thu, 20 Jul 2017 15:18:36 -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 YaTMWY2wqz9O for ; Thu, 20 Jul 2017 15:18:34 -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 A2BE51250B8 for ; Thu, 20 Jul 2017 15:18:34 -0700 (PDT) Received: from pps.filterd (m0102176.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6KMEE6T012924; Thu, 20 Jul 2017 22:18:30 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0047.outbound.protection.outlook.com [23.103.198.47]) by mx0a-0024ed01.pphosted.com with ESMTP id 2bqa3g4b1c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 20 Jul 2017 22:18: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=RGhcuB8y4Eklj1upOk/S/7LznB6sIBuL2iT7VTAO6IY=; b=Uc3Z6lRf4aSttDsTmS2K3otj8Wh4tdu34ulnMGTAk/iWh55xUGmXuAU1VfAWGAaY9gvCOmvYYles0M0WETHy7KmNH/eqdY4KiFbfBiLaBFBhE+jiItmOq/789jLJ1Qm6GlUNjPQ+CEPgWQ+EpQT2WVE2I+FbD/9l/VIWUYP5F8U= Received: from CY1PR09MB0760.namprd09.prod.outlook.com (10.161.173.151) by CY1PR09MB0757.namprd09.prod.outlook.com (10.161.173.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Thu, 20 Jul 2017 22:18:28 +0000 Received: from CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) by CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) with mapi id 15.01.1261.024; Thu, 20 Jul 2017 22:18:28 +0000 From: Henning Schulzrinne To: Richard Shockey , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities Thread-Index: AQHS//8f86lEHhh9VUKR5rSbwxo4z6Ja0ofAgABzoYCAAC1loIAAAo2AgAAGWUCAAWxBgIAADIFAgAAo3ICAAAsFgIAADk8AgAAS8rM= Date: Thu, 20 Jul 2017 22:18:28 +0000 Message-ID: References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> <8542D641-AE8F-4134-B357-017DC6F73E5F@shockey.us> <15895f11-85c0-70ab-9cc1-e7b5943e2549@alum.mit.edu>, <5D4E83A0-7B5E-4DC9-B8CD-A89B0C7F22B0@shockey.us> In-Reply-To: <5D4E83A0-7B5E-4DC9-B8CD-A89B0C7F22B0@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.56.2.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0757; 7:LEdy/4Q+Oxiq5B5ZAP29wwutuEtWcHqbXuuMi9ibdcy9jkLV4c4g8NAWlqFlDTdUMQyrxl6vXMXe8g8uIhDVDrj3na60E/f5a8pPg8urw5n2aaQ1+fQaCVH3dCD013wVsjQKYtM1K82k8wDQ433rmKASfooTfW/aeNnAhYXYHsLZNFTfbX3XWZCjQiVOZhfD/nkJ+1+5rFJTWUOrMW7Byq7Pds8nZ2XNsy5Gy7JmKL09Bc+EJ2L/zhwuAZfaiXGcuq4eSC3vcf70IoSBfgZpjND6LothMzxHsDZcUjFvTEGf2fHuYJpx8xLWHg/MqUWJUbMtIsrr/lGjtoT48GYQ8GXTRLYK7v8SKttLEPtcFBvZjdesburi61FlElbtvtQ20c/OS5VJSlQhIoWSHKpxO8MRWwTxu3XH/9PnA2GM/iuoAWzEDXa050+cqg0a0N3Q5VKDnpfuUow7ArsPVM9S1QSYCUh0n2Zs7/0kZIjyii9bjT4kal1FUZD2o6es1wUjRDutaPIVpSnNoDZzJaODCLfj9Tpg6Y2ofQjGpgb4z4IgMzVoeHKLAPLP3Esnr79mUHWl9UZQzwIAOAbS/mT2rcF8kXT8qpWkuyMcuQEUbMrIWIsOa8RU3u+Ot4t2O9GuJ7N286w42Ccln8TRvtjRpCUsOwj86q83+X30gH/ctaNLzEDtD5zgqSlmnALB1RwN17YG6JJMs+0pRV7NhCb5xJcGBIhzUBiTD1nagzKPdhTgbL0ovy0w8LKwZfRvePkszeVK6KnAiy8H6TDrdm6pBADz0+QLXpLOHQYhDDfBmNA= x-ms-office365-filtering-correlation-id: 69b61230-830c-429f-e5e8-08d4cfbd3f5b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR09MB0757; x-ms-traffictypediagnostic: CY1PR09MB0757: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR09MB0757; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR09MB0757; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39850400002)(39450400003)(39410400002)(39400400002)(189002)(199003)(38730400002)(229853002)(102836003)(6436002)(2900100001)(3280700002)(6606003)(6116002)(230783001)(81156014)(105586002)(93886004)(68736007)(97736004)(2906002)(106356001)(25786009)(189998001)(74316002)(55016002)(53936002)(54896002)(9686003)(3660700001)(2171002)(77096006)(6246003)(2950100002)(14454004)(7736002)(7696004)(3846002)(99286003)(8676002)(478600001)(81166006)(54356999)(6506006)(5660300001)(19627405001)(33656002)(76176999)(66066001)(2501003)(8936002)(86362001)(50986999)(72206003)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0757; H:CY1PR09MB0760.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB076009948A7DC1775E106DEDEAA70CY1PR09MB0760namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 22:18:28.3275 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0757 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-20_12:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 22:18:36 -0000 --_000_CY1PR09MB076009948A7DC1775E106DEDEAA70CY1PR09MB0760namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: sipcore on behalf of Richard Shockey RS> Fair enough. Choice is fine until someone screws up and you cant find = the =93reset to default=94 button. Consider the Android "Do not disturb" model. It's fairly programmable and y= ou can define time-of-day and event rules and then what are "priority" inte= rrupts that are allowed. Currently, there's "calls from..." starred contact= s, from anyone, from contacts, none. You could imagine adding "from non-spa= m callers" or "personal calls", say, based on the Call-Info header informat= ion. This does not require that users write Javascript code and most users will = probably just leave the default behavior, but this offers flexibility to th= e mobile OS vendors to implement interesting behavior. Henning --_000_CY1PR09MB076009948A7DC1775E106DEDEAA70CY1PR09MB0760namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

From: sipcor= e <sipcore-bounces@ietf.org> on behalf of Richard Shockey <richard= @shockey.us>

 
RS> Fair enough.  Choice is fine until som= eone screws up and you cant find the =93reset to default=94 button. 

Consider the Android "Do not disturb" mo= del. It's fairly programmable and you can define time-of-day and event rule= s and then what are "priority" interrupts that are allowed. Curre= ntly, there's "calls from..." starred contacts, from anyone, from contacts, none. You could imagine adding "from non-spam callers&= quot; or "personal calls", say, based on the Call-Info header inf= ormation.

This does not require that users write Javascript = code and most users will probably just leave the default behavior, but this= offers flexibility to the mobile OS vendors to implement interesting behav= ior.

Henning
   

--_000_CY1PR09MB076009948A7DC1775E106DEDEAA70CY1PR09MB0760namp_-- From nobody Fri Jul 21 03:50:01 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 13560129B3A for ; Fri, 21 Jul 2017 03:49:59 -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 XpUcfO0pgfVx for ; Fri, 21 Jul 2017 03:49:57 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF3D6127337 for ; Fri, 21 Jul 2017 03:49:56 -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=2JCZ2vw+vXjjV4RDWikBL48ephcwCLdCcj5n57NTxWk=; b=h89viYdgCpSoRKUV3+RpX979kkUlgSuV72SM3Jdj7dyZcXcsqfi1ddLAvrYzn0ZxH1Xs4OjLXS9PwIX7BLtxN1CZyiEL2RopnYwD0B857fmHUb9EKVn5vFVtPcJK8pP1RRs946JnSoJlJR/3zg9itCn13JvdMrYyLXQZZASMJ+0= Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0087.outbound.protection.outlook.com [207.46.163.87]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-71-PTu1lIvyM6ajrol47BbdOA-1; Fri, 21 Jul 2017 06:49:53 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2160.namprd03.prod.outlook.com (10.166.209.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Fri, 21 Jul 2017 10:49:52 +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.1282.016; Fri, 21 Jul 2017 10:49:51 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , Richard Shockey , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities Thread-Index: AQHS//8f86lEHhh9VUKR5rSbwxo4z6Ja0ofAgABzoYCAAC1loIAAAo2AgAAGWUCAAWxBgIAADIFAgAAo3ICAAAsFgIAADk8AgAAS8rOAANKUgA== Date: Fri, 21 Jul 2017 10:49:51 +0000 Message-ID: References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> <8542D641-AE8F-4134-B357-017DC6F73E5F@shockey.us> <15895f11-85c0-70ab-9cc1-e7b5943e2549@alum.mit.edu>, <5D4E83A0-7B5E-4DC9-B8CD-A89B0C7F22B0@shockey.us> 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; SN2PR03MB2160; 20:iT3QL/y5zq7R81LccL9CDcdZybAG6sxgYNHFIDULxHbtUfEPUEeH6n5UYnDtsaE0sWH1yq5zack1R3np2CCKOQtaCr5LKyj5u+gnG6yxWNKRN+dbOUos/JMO3Cq461+bnm+HPoBLUC0gj40UpXaxoVHn4VebI2ZMLgGN/FuQMR0= x-ms-office365-filtering-correlation-id: 5896a972-ea79-4a9d-d4a6-08d4d02636f8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR03MB2160; x-ms-traffictypediagnostic: SN2PR03MB2160: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB2160; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB2160; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39830400002)(39410400002)(39400400002)(189002)(199003)(377454003)(53936002)(55016002)(99286003)(54896002)(6306002)(9686003)(790700001)(6116002)(102836003)(3846002)(38730400002)(6246003)(2171002)(236005)(8936002)(81166006)(8676002)(81156014)(2501003)(74316002)(2906002)(478600001)(2900100001)(86362001)(3280700002)(68736007)(3660700001)(7696004)(5660300001)(50986999)(189998001)(93886004)(6436002)(54356999)(76176999)(25786009)(101416001)(53546010)(97736004)(229853002)(106356001)(7736002)(33656002)(2950100002)(6506006)(105586002)(77096006)(14454004)(230783001)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2160; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 10:49:51.4131 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2160 X-MC-Unique: PTu1lIvyM6ajrol47BbdOA-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB23509BF513D1D716AFF56D23B2A40SN2PR03MB2350namp_" Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 10:49:59 -0000 --_000_SN2PR03MB23509BF513D1D716AFF56D23B2A40SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Would this spam indicator really be useful for anything else during ringing= ? For post-ringing, the "ultimate decision maker" is already in the loop, t= he enduser himself. He doesn't need the network to tell him whether the cal= l was spam or not (or a survey or etc...), he can decide himself. And regarding granularity during ringing, would the UI really display somet= hing like "There is a 87% chance that this is a robocall" or "There is a 61= % chance that this is a survey". IMHO, we really are already in the "inform= ation overdose" area. Thanks, Tolga From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Henning Schulz= rinne Sent: Thursday, July 20, 2017 6:18 PM To: Richard Shockey ; Paul Kyzivat ; sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities From: sipcore > o= n behalf of Richard Shockey > RS> Fair enough. Choice is fine until someone screws up and you cant find = the "reset to default" button. Consider the Android "Do not disturb" model. It's fairly programmable and y= ou can define time-of-day and event rules and then what are "priority" inte= rrupts that are allowed. Currently, there's "calls from..." starred contact= s, from anyone, from contacts, none. You could imagine adding "from non-spa= m callers" or "personal calls", say, based on the Call-Info header informat= ion. This does not require that users write Javascript code and most users will = probably just leave the default behavior, but this offers flexibility to th= e mobile OS vendors to implement interesting behavior. Henning --_000_SN2PR03MB23509BF513D1D716AFF56D23B2A40SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Would this spam indicator really be useful for anyth= ing else during ringing? For post-ringing, the “ultimate decision mak= er” is already in the loop, the enduser himself. He doesn’t nee= d the network to tell him whether the call was spam or not (or a survey or etc…), he can decide himself.

 

And regarding granularity during ringing, would the = UI really display something like “There is a 87% chance that this is = a robocall” or “There is a 61% chance that this is a surveyR= 21;. IMHO, we really are already in the “information overdose” area.

 

Thanks,

Tolga

 

From: sipcore [mailto:sipcore-bounces@ietf.or= g] On Behalf Of Henning Schulzrinne
Sent: Thursday, July 20, 2017 6:18 PM
To: Richard Shockey <richard@shockey.us>; Paul Kyzivat <pky= zivat@alum.mit.edu>; sipcore@ietf.org
Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP ent= ities

 

From: sipcore <sipcore-bounces= @ietf.org> on behalf of Richard Shockey <richard@shockey.us>

 <= o:p>

RS> = Fair enough.  Choice is fine until someone screws up and you cant find= the “reset to default” button. 

&n= bsp;

Conside= r the Android "Do not disturb" model. It's fairly programmable an= d you can define time-of-day and event rules and then what are "priori= ty" interrupts that are allowed. Currently, there's "calls from..." starred contacts, from anyone, from contacts, no= ne. You could imagine adding "from non-spam callers" or "per= sonal calls", say, based on the Call-Info header information.

&n= bsp;

This do= es not require that users write Javascript code and most users will probabl= y just leave the default behavior, but this offers flexibility to the mobil= e OS vendors to implement interesting behavior.

&n= bsp;

Henning
   

--_000_SN2PR03MB23509BF513D1D716AFF56D23B2A40SN2PR03MB2350namp_-- From nobody Fri Jul 21 04:19:57 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31E1131467 for ; Fri, 21 Jul 2017 04:19:55 -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 aQ4PwYQ6TN11 for ; Fri, 21 Jul 2017 04:19:54 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A7B129B7F for ; Fri, 21 Jul 2017 04:19:53 -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=T7BISDU4BaG9USfmFBDkUGzCzGFQs5UZF5j8Yl5wSro=; b=iHRNEMr/npJ9gu9nrHWX8UrdsUWwq/aWWtr1Tg7xI2BCD564iXEFkj1szIB7O9UhmWqHV/BUe/e6hUsw8EdFkQxNlxn8bZuYtspweAzrtevf2DZgG157fh1S0FIAL0rPZF15zVka7LDIOC6mBFcw+ruOgo+9lCDk2SExJwC+P98= Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0047.outbound.protection.outlook.com [207.46.163.47]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-17-snfNUqKoOHaF5TfF3peX4A-1; Fri, 21 Jul 2017 07:19:49 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Fri, 21 Jul 2017 11:19:46 +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.1282.016; Fri, 21 Jul 2017 11:19:46 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities Thread-Index: AQHS//8f86lEHhh9VUKR5rSbwxo4z6Ja0ofAgABzoYCAAC1loIAAAo2AgAAGWUCAACJWAIABaRBwgAASotCAAM0KkA== Date: Fri, 21 Jul 2017 11:19:46 +0000 Message-ID: References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> 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; SN2PR03MB077; 20:0/jcTttD5D8zTTvNtG52591WIG6UjHhxWNfybitA5pAmesqxPw5HHsYOiLWdUeVhFiYWvRUtTEZVKsnbMoPdyuQHt4PSOjNaloEt9dr4t9HLVUny4bs5Sop15kEQwBh81NtA9yvMeigZfS4GJW/bvVjB8fcip8EuYma8nzTVGvA= x-ms-office365-filtering-correlation-id: dcc0c930-4570-4269-6ca5-08d4d02a64ad x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR03MB077; x-ms-traffictypediagnostic: SN2PR03MB077: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB077; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB077; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39400400002)(39830400002)(13464003)(199003)(377454003)(189002)(3660700001)(2950100002)(101416001)(68736007)(2171002)(93886004)(54356999)(8936002)(105586002)(74316002)(102836003)(3846002)(2906002)(6246003)(6116002)(229853002)(50986999)(38730400002)(14454004)(2501003)(7696004)(6506006)(99286003)(106356001)(86362001)(230783001)(97736004)(5660300001)(2900100001)(66066001)(3280700002)(305945005)(33656002)(25786009)(81156014)(81166006)(6436002)(76176999)(9686003)(8676002)(478600001)(53936002)(55016002)(189998001)(53546010)(77096006)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB077; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 11:19:46.1123 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB077 X-MC-Unique: snfNUqKoOHaF5TfF3peX4A-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 11:19:56 -0000 Initially I liked the idea of using "type" as a binary indicator but after = thinking a bit more about it: i- I don't think that would be proper use of "type". It is not meant to ind= icate probability but, as the name indicates, the type of the call. Overloa= ding its semantics is not a good idea IMHO. So, still using "spam" is the r= ight thing to do if one want to go "binary" AFAICT. ii- On another node on "type": I really am not sure what use this field wou= ld have as far as enduser is concerned. As I indicated in an earlier messag= e, any indication has practical value only during ringing IMHO. Do we reall= y foresee the UI display something related with the "type" -unless it is fo= r a type-value, for which network can assert 100% that is correct, e.g. "go= vernment", "emergency-alert"? I would keep type-values restricted to such v= alues. Thanks, Tolga -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Thursday, July 20, 2017 3:22 PM To: Asveren, Tolga ; Paul Kyzivat ; sipcore@ietf.org Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities It does say explicitly that all parameters are optional, but I will add tex= t about what the absence means ("good enough", basically, since no indicato= r is 100% correct). -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com]=20 Sent: Thursday, July 20, 2017 2:41 PM To: Henning Schulzrinne ; Paul Kyzivat ; sipcore@ietf.org Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities O.K., this sounds good. It really could be good to add a sentence or two ab= out this issue -even if the syntax already defines "spam" as optional"- tho= ugh. "Use of spam parameter requires a fine granularity decision about the natur= e of the call. It may not be possible to easily predict or use in an effici= ent way for certain networks, call flows, end-points." Thanks, Tolga From nobody Fri Jul 21 06:57: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 4D681131DFF for ; Fri, 21 Jul 2017 06:57:22 -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 5j3Bjw8lOIO9 for ; Fri, 21 Jul 2017 06:57:19 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B181131A5F for ; Fri, 21 Jul 2017 06:57:19 -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=gofbRKz0hNvBWOKxEqkAQlNoo+12VEdU0ekwxaJg11s=; b=qJQ43atxNvX50NS4OmBnI+nxqVlwd/a1K96Ykz0UtUYDAeBzg4qAHaXAcuS/R8b+F1WVt32d7HI++eIz4vnLXm+zVvdj6vLzA8YbAWHQanP++tu1QRO5FJHVmmM4PXJyjKttsYV2K1f0aev+NCtiW6o32EhuhpWb2lJCPawBfxk= Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0175.outbound.protection.outlook.com [216.32.180.175]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-15-DERRfmLrNJq4eyKkqALHIg-1; Fri, 21 Jul 2017 09:57:13 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB080.namprd03.prod.outlook.com (10.255.175.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Fri, 21 Jul 2017 13:57:11 +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.1282.016; Fri, 21 Jul 2017 13:57:11 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , "sipcore@ietf.org" Thread-Topic: draft-ietf-sipcore-callinfo-spam-01 - general Thread-Index: AdMAopBZ33P6AvZ9QAax/4dOZofeKQA5VdvA Date: Fri, 21 Jul 2017 13:57:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB080; 20:0GmHO4tsyYLXtE3KJG8QZYWQrzm833LTNZe3FcBNjCytIl69a7szv2fHQ/GdRcgAbqNcOOmQqo1zReVy/PZRWk/2cY/gGCfCcXTSJAsIMvVbax1i3Hyhy6F0uw0v5OoaXQExN2DR4gpUpDIl+P8OPuiO5Y3jwG9yxMUZzXOeego= x-ms-office365-filtering-correlation-id: b043921c-a9de-4d12-5fb5-08d4d0406241 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR03MB080; x-ms-traffictypediagnostic: SN2PR03MB080: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(131327999870524)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB080; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB080; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39830400002)(39450400003)(39410400002)(377454003)(51694002)(189002)(199003)(101416001)(33656002)(229853002)(8676002)(478600001)(53936002)(236005)(2501003)(189998001)(81166006)(86362001)(68736007)(66066001)(54356999)(6306002)(14454004)(3280700002)(561944003)(3846002)(99286003)(55016002)(6246003)(38730400002)(2906002)(50986999)(76176999)(54896002)(81156014)(53546010)(9686003)(2950100002)(8936002)(6436002)(77096006)(345774005)(230783001)(105586002)(6116002)(7736002)(106356001)(3660700001)(19609705001)(6506006)(7696004)(5660300001)(790700001)(74316002)(97736004)(102836003)(2900100001)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB080; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 13:57:11.0080 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB080 X-MC-Unique: DERRfmLrNJq4eyKkqALHIg-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB23501372748A11A4880D98A4B2A40SN2PR03MB2350namp_" Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - general 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 Jul 2017 13:57:22 -0000 --_000_SN2PR03MB23501372748A11A4880D98A4B2A40SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Henning, Inline... Thanks, Tolga From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, July 19, 2017 11:45 AM To: Asveren, Tolga ; sipcore@ietf.org Subject: RE: draft-ietf-sipcore-callinfo-spam-01 - general Tolga, Sorry for missing your comment and thank you for re-starting the conversati= on. Let me try to respond in general terms first, as I think your assumptions d= iffer a bit from mine. There are three general observations: 1. Call spam is somewhat subjective, partially reflected in the unwanted= vs. illegal distinction. There are clearly calls that are illegal (e.g., t= he tax authority scams) and presumably unwanted (if the called party knew t= hat it was a scam). But there are many calls that are somewhat less clear. = Calls by politicians or debt collectors are two classical examples - they m= ay be legal, but a significant fraction of people would rather not get thes= e calls or may not want to answer these calls at certain times. As another = example, a called party may decide that they'd rather not be bothered with = any non-personal calls ("robocalls") during their vacation or while traveli= ng in a different time zone, even if they'd otherwise be happy to get the c= all (e.g., calls about prescriptions being ready for pickup). They may also= decide to send these calls to voicemail. 2. As Paul points out in a follow-up message, only the end user is quali= fied to make these distinctions (or, somewhat equivalently, an algorithm co= nfigured by the end user that reflects her personal preferences). [TOLGA] I think what you are describing here gets a bit out of the "annoyin= g calls" category. It is more related with "call categorization in general"= . Do we really want to tackle such a broad topic in this draft? I thought t= he raison d'etre is dealing with robocalls, spam. I personally would prefer= to keep focus on these aspects. 1. Because of these subtleties, many carriers would rather not get into = the call dropping business and leave that to the end user, with exceptions.= (For example, they may want to drop denial-of-service or spoofed caller ID= calls.) The 'type' information helps the called party or the algorithm working on h= er behalf to make decisions. I don't quite understand the "identity of the entity providing spam score" = comment. The 'source' element is meant to provide this. Can you explain how= your identity differs from the one in the draft? [TOLGA] Yes, what I described is covered by "source", I just wanted to expr= ess my opinion for which scenarios/use case it would be useful, i.e. betwee= n network elements and not much toward the end-device. Similarly, you write "A "0-100 spam score" indicator may be useful in this = context...". The 'spam' parameter in the draft contains this information. A= gain, can you explain how your proposal differs from the draft? [That said,= I'm tempted to rename the parameter to 'confidence', to be less prejudicia= l.] [TOLGA] Again, I was just trying to point out that a fine granularity spam = indicator could be useful among network entities but not so much toward the= end-device. Henning From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Wednesday, July 19, 2017 4:35 AM To: Henning Schulzrinne >; sipcore@ietf.org Subject: RE: draft-ietf-sipcore-callinfo-spam-01 - SIP entities Henning, I had some high level queries/comments, which I sent back beginning of Apri= l. Here it is again for easier access: What are the main use cases? 1) Communicating spam related information between network elements for a pa= rticular call Various network elements may have a prediction whether a call is spam. It c= ould be useful to send all that info in a chain and then the ultimate decis= ion what needs to be sent to UE would be on the last-hop authorative entity= . A "0-100 spam score" indicator may be useful in this context, or at least= something more than just "likely to be spam" indicator. The identity of the entity providing spam score needs to be part of the pro= vided information. More than one spam score/identity pair needs to be supported. Support for signed identity should be there. I am not sure whether "type" would be useful here, I tend to think not. How= /Why would it be used? 2) Communicating spam related information between network and end-user I think here what is needed is just a "likely to be spam" indicator as far = as network prediction is concerned. End-user would see a visual indicator i= f the indicator is present. Anything more than that is just "information ov= erdose" IMHO and wouldn't have much practical value for an average user. An= other indicator stating "calling identity can't be verified" could be usefu= l but this IMHO is something different. [Trimming separate issue] --_000_SN2PR03MB23501372748A11A4880D98A4B2A40SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Henning,

 

Inline…

 

Thanks,

Tolga

 

From: Henning Schulzrinne [mailto:Henning.Sch= ulzrinne@fcc.gov]
Sent: Wednesday, July 19, 2017 11:45 AM
To: Asveren, Tolga <tasveren@sonusnet.com>; sipcore@ietf.org Subject: RE: draft-ietf-sipcore-callinfo-spam-01 - general

 

Tolga,

 

Sorry for missing your comment and thank you for re-= starting the conversation.

 

Let me try to respond in general terms first, as I t= hink your assumptions differ a bit from mine.

 

There are three general observations:

 

  1. C= all spam is somewhat subjective, partially reflected in the unwanted vs. il= legal distinction. There are clearly calls that are illegal (e.g., the tax = authority scams) and presumably unwanted (if the called party knew that it was a scam). But there are many calls th= at are somewhat less clear. Calls by politicians or debt collectors are two= classical examples – they may be legal, but a significant fraction o= f people would rather not get these calls or may not want to answer these calls at certain times. As another example= , a called party may decide that they’d rather not be bothered with a= ny non-personal calls (“robocalls”) during their vacation or wh= ile traveling in a different time zone, even if they’d otherwise be happy to get the call (e.g., calls about prescriptions being = ready for pickup). They may also decide to send these calls to voicemail.
  2. As Paul points out in a follow-up message, only the end user i= s qualified to make these distinctions (or, somewhat equivalently, an algor= ithm configured by the end user that reflects her personal preferences).

[TOLGA] I think what you are describing here gets a = bit out of the “annoying calls” category. It is more related wi= th “call categorization in general”. Do we really want to tackl= e such a broad topic in this draft? I thought the raison d’etre is dealing with robocalls, spam. I personally would prefer to keep focus o= n these aspects.

 

  1. B= ecause of these subtleties, many carriers would rather not get into the cal= l dropping business and leave that to the end user, with exceptions. (For e= xample, they may want to drop denial-of-service or spoofed caller ID calls.)

 

The ‘type’ information helps the called = party or the algorithm working on her behalf to make decisions.<= /p>

 

I don’t quite understand the “identity o= f the entity providing spam score” comment. The ‘source’ = element is meant to provide this. Can you explain how your identity differs= from the one in the draft?

[TOLGA] Yes, what I described is covered by “s= ource”, I just wanted to express my opinion for which scenarios/use c= ase it would be useful, i.e. between network elements and not much toward t= he end-device.

 

Similarly, you write “A "0-100 spam score= " indicator may be useful in this context…”. The ‘sp= am’ parameter in the draft contains this information. Again, can you = explain how your proposal differs from the draft? [That said, I’m tem= pted to rename the parameter to ‘confidence’, to be less prejudicia= l.]

[TOLGA] Again, I was just trying to point out that a= fine granularity spam indicator could be useful among network entities but= not so much toward the end-device.

 

Henning

 

From: Asveren, Tolga [mailto:tasveren@sonusnet.com]
Sent: Wednesday, July 19, 2017 4:35 AM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; sipcore@ietf.org
Subject: RE: draft-ietf-sipcore-callinfo-spam-01 - SIP entities=

 

Henning,

 

I had some high level queries/comments, which I sent= back beginning of April. Here it is again for easier access:

 

 

What are the main use cases?

1) Communicating spam related information between ne= twork elements for a particular call

Various network elements may have a prediction wheth= er a call is spam. It could be useful to send all that info in a chain and = then the ultimate decision what needs to be sent to UE would be on the last= -hop authorative entity. A "0-100 spam score" indicator may be useful in this context, or at least some= thing more than just "likely to be spam" indicator.

The identity of the entity providing spam score need= s to be part of the provided information.

More than one spam score/identity pair needs to be s= upported.

Support for signed identity should be there.

I am not sure whether "type" would be usef= ul here, I tend to think not. How/Why would it be used?

 

2) Communicating spam related information between ne= twork and end-user

I think here what is needed is just a "likely t= o be spam" indicator as far as network prediction is concerned. End-us= er would see a visual indicator if the indicator is present. Anything more = than that is just "information overdose" IMHO and wouldn't have much practical value for an average user. Another indica= tor stating "calling identity can't be verified" could be useful = but this IMHO is something different.

 

[Trimming separate issue]

 

--_000_SN2PR03MB23501372748A11A4880D98A4B2A40SN2PR03MB2350namp_-- From nobody Fri Jul 21 08:55: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 0307A13189C for ; Fri, 21 Jul 2017 08:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mKeRpm0vO8Sa for ; Fri, 21 Jul 2017 08:55:17 -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 2E782131B5B for ; Fri, 21 Jul 2017 08:55:16 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-10v.sys.comcast.net with ESMTP id YaEodzla8pjExYaGpdr7i7; Fri, 21 Jul 2017 15:55:15 +0000 Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-14v.sys.comcast.net with SMTP id YaGodRAeVyqbQYaGodGRQc; Fri, 21 Jul 2017 15:55:15 +0000 To: "Asveren, Tolga" , Henning Schulzrinne , Richard Shockey , "sipcore@ietf.org" References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> <8542D641-AE8F-4134-B357-017DC6F73E5F@shockey.us> <15895f11-85c0-70ab-9cc1-e7b5943e2549@alum.mit.edu> <5D4E83A0-7B5E-4DC9-B8CD-A89B0C7F22B0@shockey.us> From: Paul Kyzivat Message-ID: <4c1d999e-d240-04f9-8a51-6bba87f471fa@alum.mit.edu> Date: Fri, 21 Jul 2017 11:55:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfOKlDFflQNRDn/YNAbbQLjtcnxhFlNoAVsL6xrf/K/vc42i/0JzPGnaahdnUNTvLSD6hg8K9xF4qQSh5tcbA5d+JTF2UR5V1BP7mCwB//poVd3WASvNk CMq2I99XMtM7OlaRK9lwA6HUmILIhDUFiogE64FkUjGmgmjxIkEGusEpjdpKN4bAXhvQ6KqdwRNNhXDKq6LB6jd0KetPGxD40RoN2VIgE03uwkAYh9eBBbaO 6ljeXaG4ljRpUjRc9qmsk8TeR1rL3aqMQ/ZzwYiOTlA= Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 15:55:18 -0000 On 7/21/17 6:49 AM, Asveren, Tolga wrote: > And regarding granularity during ringing, would the UI really display > something like “There is a 87% chance that this is a robocall” or “There > is a 61% chance that this is a survey”. IMHO, we really are already in > the “information overdose” area. That sounds like a really bad UI - I think I would choose a different app. But my UI might show a green/yellow/red indicator. Or maybe a larger spectrum of colors. Or, as I already mentioned, there might be different ring tones for various ranges of probability. The trick is, if the range is from 0-100 then you can carve it up into two categories, Henning can carve it up into three, and I can have five distinct ranges if I want. If the SP makes a binary choice then we don't have those options. Thanks, Paul From nobody Fri Jul 21 08:59: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 03BE512EAF7 for ; Fri, 21 Jul 2017 08:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zclA7-4ESilf for ; Fri, 21 Jul 2017 08:59:00 -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 32D6F128BC8 for ; Fri, 21 Jul 2017 08:59:00 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id YaK8d2PwTGWg6YaKRd4KSu; Fri, 21 Jul 2017 15:58:59 +0000 Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-01v.sys.comcast.net with SMTP id YaKQdnqXe3hkzYaKQd73Rc; Fri, 21 Jul 2017 15:58:59 +0000 To: "Asveren, Tolga" , Henning Schulzrinne , "sipcore@ietf.org" References: <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> From: Paul Kyzivat Message-ID: <0f5871f5-1559-496d-6832-f7c87a99aa1a@alum.mit.edu> Date: Fri, 21 Jul 2017 11:58:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfD0TOOVxBa4h2tiYu5P8WSFXs9FXBOFMX1lO9MwBzLtFly2n+EUBjgFSQM0lj5XuT64lrchDlWnk+3ndJwXDJpO3CPKcE9mXbmMM2fm3uYG79wJhHX5Q l63/+yvBGHfDJ9QnCVXSR4SfzpIuC+3LwKH3q/YXybmDejTuW5A60i08oihNUhyVg2k+KLcyXY+rOwQiLgpmTRAf8B448bSLBbAulJWfPW9VmZRJi9B0wNJK NgerHU19ng9OtwONpWZKKQ== Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities 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 Jul 2017 15:59:01 -0000 On 7/21/17 7:19 AM, Asveren, Tolga wrote: > As I indicated in an earlier message, any indication has practical value only during ringing IMHO. Henning already mentioned the idea of displaying it along with voicemails. Certainly at that point you can listen to the voicemail and decide for yourself. But when your mailbox is full up with junk you are likely to want to use this info to help decide which ones to listen to and which ones to defer or delete without listening. Thanks, Paul From nobody Fri Jul 21 11:27: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 AC86E131C55 for ; Fri, 21 Jul 2017 11:27:17 -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 ZiwEVNei-bEl for ; Fri, 21 Jul 2017 11:27:15 -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 E9425131C36 for ; Fri, 21 Jul 2017 11:27:15 -0700 (PDT) Received: from pps.filterd (m0102176.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6LIObEj019759; Fri, 21 Jul 2017 18:27:14 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0021.outbound.protection.outlook.com [23.103.198.21]) by mx0a-0024ed01.pphosted.com with ESMTP id 2bqa3g5122-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 21 Jul 2017 18:27:14 +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=NoPBSTW8jZsbxJPmt+eRZ+bGCcLM1BHTAR9bEfHuGa4=; b=EQIjA2T1A3dCFu0oG++FH6my7WXsaNYyKxcUgn3qzlKR9+SHFYyg2L02kroUaIm5fntMnkS4eIvcmLtFChF/aJhrtog9RlCGE/6VUlIOn476tWYr9ov+OkiOcYYFtCiKH5TKsxyx1/WBfdaITLckM+L2P8nWPYNhJr+4fy29724= Received: from CY1PR09MB0760.namprd09.prod.outlook.com (10.161.173.151) by CY1PR09MB0757.namprd09.prod.outlook.com (10.161.173.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Fri, 21 Jul 2017 18:27:12 +0000 Received: from CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) by CY1PR09MB0760.namprd09.prod.outlook.com ([10.161.173.151]) with mapi id 15.01.1261.024; Fri, 21 Jul 2017 18:27:12 +0000 From: Henning Schulzrinne To: "Asveren, Tolga" , "sipcore@ietf.org" Thread-Topic: draft-ietf-sipcore-callinfo-spam-01 - general Thread-Index: AdMAopBZ33P6AvZ9QAax/4dOZofeKQA5VdvAADFiENI= Date: Fri, 21 Jul 2017 18:27:12 +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: [2001:18d8:ffff:16:5dd2:eed3:70c4:9a81] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0757; 7:oEP/Sv+7tLXjIbRlbntP+fTMT+8lTjpn+8F0JLYA2kJcDpsN4dj/CcOXG+poGysJaJ9uGTVaSV7nbvtpb2ItUvgi0cu7FB0Q9ySF4DSzguHNL14Pan0pk6iCE3uqoKRdOp7J0fE2psYOY+m1NFrJF8M8cAzYOSFAdHB2/6QBbMT65lx3h5DMvMl1disIwynMaWpGEqEub0byUl45QkHwisdOLy41uRN00o0D5ixwTJulW5nwsM8/QvFkpwd6FJ+0By27b0I07ak073NXg5xiS/cnNb/wtxtkzejrWz3trK/iQc+lge228M04eXAhFfmwrqd6m6iFoik5I80MMnJIdz+INmuT0jqCUrOHRyIkzCuEXEax8HUC5xWgjv9MNUyRGOA8gtZdG0Azse6OFAp5wG7kQCP9P3lpWs/XSPlLPMDntNqT+sJafPITd+FQJSjpf+8n8san3vZ7kv6buzrP0u8grREg6xGZ8S1R++SI+RaTPXUQLl8cq7whofVQ0i2NR+A3v3cnpaNkl8KKtkYPlC83u6lTY0LRkxGVvwhxNgBSBUeN1opYwC+gfdDbVmnIypuBJm7omjSfFH121Sx6/8gIF5hhqOmklzM7lswgebca8JEbnAc3gBO08u3zd05jtCSfsfY2kE8NlEWXTxAzUf5I0XwO+uLHWfI0xtMSvX8kZZXvNHN/l2nUVieDqasYBsGTrRDq6IY8/uETQ9oGq688Zc5+hn5fDhstDzX5GP5cQ7V9DADRXuz4uG/g/MmM/31XAtK3PhmZ8uR6qBIshtqdSb4cSUgiwETdC8vEOkg= x-ms-office365-filtering-correlation-id: 63125ab6-1a55-4d89-e7f1-08d4d0661b53 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR09MB0757; x-ms-traffictypediagnostic: CY1PR09MB0757: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR09MB0757; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR09MB0757; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(39850400002)(199003)(189002)(8676002)(99286003)(6506006)(478600001)(8936002)(81166006)(7736002)(7696004)(14454004)(72206003)(86362001)(101416001)(54356999)(50986999)(5660300001)(19627405001)(2501003)(33656002)(76176999)(6116002)(6436002)(97736004)(2906002)(68736007)(106356001)(105586002)(3280700002)(102836003)(229853002)(38730400002)(6606003)(230783001)(81156014)(55016002)(6246003)(25786009)(2900100001)(74316002)(2950100002)(77096006)(189998001)(3660700001)(9686003)(54896002)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0757; H:CY1PR09MB0760.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0760D957D428D1BBCC2DD6FCEAA40CY1PR09MB0760namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 18:27:12.7464 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0757 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - general 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 Jul 2017 18:27:17 -0000 --_000_CY1PR09MB0760D957D428D1BBCC2DD6FCEAA40CY1PR09MB0760namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think we beat the other issues to death, where, if I may say so, your opi= nion seems to be on the rough side of the consensus. For the 'type' designation, the list is motivated by the real-life observat= ion that robocalls come in, to use your term, shades of annoying. The curre= nt strategy in many households is not to answer any calls where the caller = name isn't a family member, which is not ideal. (For example, your bank rob= ot may be calling you to alert you to a suspicious charge on your debit car= d.) Thus arose the notion of labeling calls that are robocalls (or, more ge= nerally, non-personal calls) with more granularity. Otherwise, you end up e= ither rejecting or labeling all non-personal calls or only fraudulent "IRS = scam" calls. The list of labels, as noted in the acknowledgments section of the draft, w= as compiled by members of the Robocall Strike Force that met last year, so = this is not my personal invention. Task force members were struggling with = the issue I mentioned above, where a simple binary good/bad indicator is li= kely to be either over-inclusive or under-inclusive for many called parties= . As noted, you can implement a simple "spam-or-not" mechanism using only the= type=3D'spam' catch-all, if that's your implementation preference. [TOLGA] I think what you are describing here gets a bit out of the =93annoy= ing calls=94 category. It is more related with =93call categorization in ge= neral=94. Do we really want to tackle such a broad topic in this draft? I t= hought the raison d=92etre is dealing with robocalls, spam. I personally wo= uld prefer to keep focus on these aspects. Henning --_000_CY1PR09MB0760D957D428D1BBCC2DD6FCEAA40CY1PR09MB0760namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I thi= nk we beat the other issues to death, where, if I may say so, your opinion = seems to be on the rough side of the consensus.


For t= he 'type' designation, the list is motivated by the real-life observation t= hat robocalls come in, to use your term, shades of annoying. The current st= rategy in many households is not to answer any calls where the caller name isn't a family member, which is not= ideal. (For example, your bank robot may be calling you to alert you to a = suspicious charge on your debit card.) Thus arose the notion of labeli= ng calls that are robocalls (or, more generally, non-personal calls) with more granularity. Otherwise, you end u= p either rejecting or labeling all non-personal calls or only fraudulent &q= uot;IRS scam" calls.


The l= ist of labels, as noted in the acknowledgments section of the draft, w= as compiled by members of the Robocall Strike Force that met last year, so = this is not my personal invention. Task force members were struggling with the issue I mentioned above, where a si= mple binary good/bad indicator is likely to be either over-inclusive or und= er-inclusive for many called parties.


As no= ted, you can implement a simple "spam-or-not" mechanism using onl= y the type=3D'spam' catch-all, if that's your implementation preference.


[TOLG= A] I think what you are describing here gets a bit out of the =93annoying c= alls=94 category. It is more related with =93call categorization in general= =94. Do we really want to tackle such a broad topic in this draft? I thought the raison d=92etre is dealing with robocal= ls, spam. I personally would prefer to keep focus on these aspects.<= br>


 

Henning


--_000_CY1PR09MB0760D957D428D1BBCC2DD6FCEAA40CY1PR09MB0760namp_-- From nobody Fri Jul 21 11:36: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 6CCC0131C6B for ; Fri, 21 Jul 2017 11:36: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 FiTzrk08k6vQ for ; Fri, 21 Jul 2017 11:36: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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA6C131C6A for ; Fri, 21 Jul 2017 11:36: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=RJsGgj8IJtO1c8aHXNsamrwGbSxJKwb1C3j1IM2H2rQ=; b=rZ5P15FKN8fi5RW1nTMHSZ1XOx8NCTB/ytyjB+JYSnPFtOw4RdRCcOam0MzRQ2hpPWNR+rmEnN4lpq+qd5JLCpLDTeHj6hC1FJySboIo6ULwniv6DBPkcelYnFqFDKcQpVHqJzO3PhFlsi4vbW9PvZrfr1BQrSeYphceVQ8nHlo= Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0082.outbound.protection.outlook.com [207.46.163.82]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-63-RfY3iQPFPQ2u5eoUBbJVwg-1; Fri, 21 Jul 2017 14:36:13 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB014.namprd03.prod.outlook.com (10.255.175.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.15; Fri, 21 Jul 2017 18:36: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.1282.016; Fri, 21 Jul 2017 18:36:09 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , "sipcore@ietf.org" Thread-Topic: draft-ietf-sipcore-callinfo-spam-01 - general Thread-Index: AdMAopBZ33P6AvZ9QAax/4dOZofeKQA5VdvAADFiENIAAJUSMA== Date: Fri, 21 Jul 2017 18:36:09 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB014; 20:rLJKSG6TLTBXyCIs7ZvQk4zz01A+f/acbpiWx0hLgtuBb3iu3ArniVJJIcuTwCXGNztSI9oOFsA1c0d0u06x7RnRvNf3vY8XO95RblaOTuCyQwg/2oW2UYvqudioDofAVAFOFfUDy/9eqJ/DSRWv3LPCPGw3YldgiyvFPyFSz9I= x-ms-office365-filtering-correlation-id: e5e9ff3a-5fa5-41c6-2cf3-08d4d0675b4e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR03MB014; x-ms-traffictypediagnostic: SN2PR03MB014: x-exchange-antispam-report-test: UriScan:(26388249023172)(21748063052155)(151999592597050); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB014; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB014; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39830400002)(39450400003)(377454003)(199003)(189002)(7736002)(50986999)(3660700001)(54356999)(76176999)(6306002)(9686003)(2906002)(97736004)(81166006)(81156014)(101416001)(6436002)(8676002)(74316002)(38730400002)(478600001)(6246003)(790700001)(14454004)(8936002)(105586002)(66066001)(106356001)(55016002)(99286003)(3846002)(102836003)(6116002)(189998001)(53936002)(3280700002)(6506006)(54896002)(230783001)(2900100001)(2501003)(33656002)(68736007)(229853002)(25786009)(77096006)(53546010)(2950100002)(5660300001)(7696004)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB014; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 18:36:09.6970 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB014 X-MC-Unique: RfY3iQPFPQ2u5eoUBbJVwg-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB23502D22A2B114D7A59F8431B2A40SN2PR03MB2350namp_" Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - general 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 Jul 2017 18:36:20 -0000 --_000_SN2PR03MB23502D22A2B114D7A59F8431B2A40SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Understood that the list is not coming out of thin air; I just thought that= it refers to a broader range of issues outside of the scope of the draft. = But then it seems I am on the minority as far as that view is concerned. Th= at parameters are optional is comforting though. So, overall, I am resting my case. Thanks, Tolga From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Henning Schulz= rinne Sent: Friday, July 21, 2017 2:27 PM To: Asveren, Tolga ; sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - general I think we beat the other issues to death, where, if I may say so, your opi= nion seems to be on the rough side of the consensus. For the 'type' designation, the list is motivated by the real-life observat= ion that robocalls come in, to use your term, shades of annoying. The curre= nt strategy in many households is not to answer any calls where the caller = name isn't a family member, which is not ideal. (For example, your bank rob= ot may be calling you to alert you to a suspicious charge on your debit car= d.) Thus arose the notion of labeling calls that are robocalls (or, more ge= nerally, non-personal calls) with more granularity. Otherwise, you end up e= ither rejecting or labeling all non-personal calls or only fraudulent "IRS = scam" calls. The list of labels, as noted in the acknowledgments section of the draft, w= as compiled by members of the Robocall Strike Force that met last year, so = this is not my personal invention. Task force members were struggling with = the issue I mentioned above, where a simple binary good/bad indicator is li= kely to be either over-inclusive or under-inclusive for many called parties= . As noted, you can implement a simple "spam-or-not" mechanism using only the= type=3D'spam' catch-all, if that's your implementation preference. [TOLGA] I think what you are describing here gets a bit out of the "annoyin= g calls" category. It is more related with "call categorization in general"= . Do we really want to tackle such a broad topic in this draft? I thought t= he raison d'etre is dealing with robocalls, spam. I personally would prefer= to keep focus on these aspects. Henning --_000_SN2PR03MB23502D22A2B114D7A59F8431B2A40SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Understood that the list is not coming out of thin a= ir; I just thought that it refers to a broader range of issues outside of t= he scope of the draft. But then it seems I am on the minority as far as tha= t view is concerned. That parameters are optional is comforting though.

 

So, overall, I am resting my case.

 

Thanks,

Tolga

 

From: sipcore [mailto:sipcore-bounces@ietf.or= g] On Behalf Of Henning Schulzrinne
Sent: Friday, July 21, 2017 2:27 PM
To: Asveren, Tolga <tasveren@sonusnet.com>; sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - general=

 

I think we beat the other issues to death, w= here, if I may say so, your opinion seems to be on the rough side of the co= nsensus.

 

For the 'type' designation, the list is moti= vated by the real-life observation that robocalls come in, to use your term= , shades of annoying. The current strategy in many households is not to ans= wer any calls where the caller name isn't a family member, which is not ideal. (For example, your bank robot m= ay be calling you to alert you to a suspicious charge on your debit card.) = Thus arose the notion of labeling calls that are robocalls (or, more g= enerally, non-personal calls) with more granularity. Otherwise, you end up either rejecting or labeling all non-pe= rsonal calls or only fraudulent "IRS scam" calls.

 

The list of labels, as noted in the acknowle= dgments section of the draft, was compiled by members of the Robocall = Strike Force that met last year, so this is not my personal invention. Task= force members were struggling with the issue I mentioned above, where a simple binary good/bad indicator is likel= y to be either over-inclusive or under-inclusive for many called parties.

 

As noted, you can implement a simple "s= pam-or-not" mechanism using only the type=3D'spam' catch-all, if that'= s your implementation preference.

 

[TOLGA] I think what you are describing here= gets a bit out of the “annoying calls” category. It is more re= lated with “call categorization in general”. Do we really want = to tackle such a broad topic in this draft? I thought the raison d’etre is dealing with robocalls, spam. I personally would pr= efer to keep focus on these aspects.

 

 

Henning

 

--_000_SN2PR03MB23502D22A2B114D7A59F8431B2A40SN2PR03MB2350namp_--