From nobody Fri Mar 1 02:36:46 2019 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 5C5AA130DE4 for ; Fri, 1 Mar 2019 02:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Mpcu0jwu; dkim=pass (1024-bit key) header.d=ericsson.com header.b=jR5lox+P 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 hD-CVVOrfQQC for ; Fri, 1 Mar 2019 02:36:43 -0800 (PST) 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 CA469130E2F for ; Fri, 1 Mar 2019 02:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551436600; x=1554028600; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dnOsjjOcipInOH7w6AuW4OULwwwaN6ryeGbdR9wgwAg=; b=Mpcu0jwue0mcGiJVRQrFYrqff/oLUJKcOkHZcBrjS1kh4fgwC7hVn1dimqgdDVnO s/kyQsybtCi0WPcDp554XaPDmCG/t8cWFicLqDOkmNHiTCXGeGJEz59i6VagfKsH ueWNP9w1MheRUG/hzPPI1cninMSj4VDzzPFYzAOWiAY=; X-AuditID: c1b4fb3a-5c9c29e00000672c-7e-5c790b380dc4 Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 10.4D.26412.83B097C5; Fri, 1 Mar 2019 11:36:40 +0100 (CET) Received: from ESESBMR504.ericsson.se (153.88.183.139) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Mar 2019 11:36:34 +0100 Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESBMR504.ericsson.se (153.88.183.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Mar 2019 11:36:35 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 1 Mar 2019 11:36:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dnOsjjOcipInOH7w6AuW4OULwwwaN6ryeGbdR9wgwAg=; b=jR5lox+PjjXYqpMqQR/2uoYIMZLB0gejWZmDR1AXqSKqexwesexgVenAP2qhMDachtWXgrbMdDcEHFlD46f8OcaxFQl5N5vonUMTDMEXGUbZq8C4h2qvfGtfUOJ7B/EixDgklqX3AhDXxhk2CMUDCrEyJ3ntcgJq9EMS8qA2gOc= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB1036.eurprd07.prod.outlook.com (10.162.27.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.9; Fri, 1 Mar 2019 10:36:33 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae%3]) with mapi id 15.20.1686.011; Fri, 1 Mar 2019 10:36:33 +0000 From: Christer Holmberg To: Ben Campbell CC: "sipcore@ietf.org" , "sipcore-chairs@ietf.org" Thread-Topic: [sipcore] Draft new version: SIP Push -26 Thread-Index: AQHUzG2/fAsUUrRbaUabkXaZNj2C3KX0V90AgAFsEYD//+T/AIABFQQA Date: Fri, 1 Mar 2019 10:36:32 +0000 Message-ID: <010FF140-EFC4-4833-A526-826D69A49DB5@ericsson.com> References: <8F397308-9ED7-4CB7-B1F6-DC1A78018672@nostrum.com> <9673FB23-BB4C-4C6F-8E48-90650A5D0409@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 x-originating-ip: [2001:14b8:1829:11:9032:6c5a:3308:5eb7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d589d906-47e0-4ec8-f54c-08d69e31c5f7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB1036; x-ms-traffictypediagnostic: HE1PR07MB1036: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIxMDM2OzIzOjMwUTNMbWZpeWFZaFlQMjMxUEFLYkZyK0E1?= =?utf-8?B?SndXVmxvK1pDdGlWVVpTUGdyVUhZYS9rN3N2Z1dOVW05Q3MvM0RJSXJFeG5m?= =?utf-8?B?TDdSV1lFUm1yeTdlY1VqTmJxY1hBSG4zWUJFd2sxOXJpYUJOcVdQNG9xZXpR?= =?utf-8?B?U3dWRFdscENUZEdibGQyYjVsVEQ4ajNGT2h0UUtBRGNsQzZFakZsb1lNK3Q4?= =?utf-8?B?WUhPNVNUWSs2S3k4bFZwVlREdmF6emlOK29SeEpGWU5xMXBLaERnZG1jMGdF?= =?utf-8?B?ZHkrWVptRElMSjJNandsZ2phdHJuOU1peHpCWE9WUmNrZ3V4dDhPTUxKMVBn?= =?utf-8?B?Q2htSHBreDJpQmU2L1NMOW56Nm91MmFaWHV2K1pHdlo4K1hNSDVxbUI4WXNK?= =?utf-8?B?Nkxac3FtS01oUHVWWGJIWkoxb0hUdmJsQTZyR2ZnUytFMEFDRkx4TTVDbVZo?= =?utf-8?B?MVNhVjhVUkNkdzBNSE5XNEpISCtJSEhjeDcxU2dwOEhRUEhwb0pHSGp4SjZm?= =?utf-8?B?TkFRS0ZYQXF4TzYzN1pGVkJxSHU4R2pWQ2owWkkrU2p0VjVVVlNQaTk4S21E?= =?utf-8?B?ejlWcEpoVXJuZWJnWVAySUxBOTE4YWlNTGRWZnZ0TmRtWUtEVENTZ2ZML1ha?= =?utf-8?B?aFdZSzFRYUdTOXdDb3lpWk9Yazd0TWZhcjI3djMrSkx2VVE3aGJuVXpmNThB?= =?utf-8?B?QVNOZHFsRlZweWF4OTBjalZ5czgxcFVGN1hOZ2F1VjY5SVg2ZVBmNXEzQkNt?= =?utf-8?B?SlJqVjJMb3YrWXRIcXFDdkN3dHVxaGx0WU9hZHEwRURzSG9qZTJEaGhyTlBk?= =?utf-8?B?a0JQNVJyMTZJRlUydG1EMHJEU2Nxc2pyaFJyWUViWEtnVktjQ3dsUjVxenkx?= =?utf-8?B?RThDeFlYZkFtaTAxclJBeUNWYmpEMG1HY2hCaUVyd1V4ODUxSWZmQjhVdStD?= =?utf-8?B?TGFyUlpDSTJTWUpGWFZpVURmWXNCMWcxRlhUUGxhNkl0YWQ2cGtEZDVBS0hm?= =?utf-8?B?TXk4UktvdWgvWVFQc2pwcGo0akRHNzJaUnVxdW5pZTVUSnVPTzYrSkFQQW5m?= =?utf-8?B?YWtlczFReUVoMDlZSVhuU3A1U2sxd0d5SXFoUThzc0FPNml1cUN1V0JGeXIz?= =?utf-8?B?UHZhQ2orUVUwZktSTU1OT00vMFFIV3Rrd1ovK0J5cDQ0TzN6RlZSRGZlN2JI?= =?utf-8?B?Z1pFRGxiekVOdGl4bFRsS3FqQ1hZRE85UTlSQUFSekxQcTczN3NMNlQ5TFNE?= =?utf-8?B?aWx6aTd6UnE4aXR5SjdmZ1ZEdGI4eEluMmJtZ09qTTdLOFhNMFdKK3QyN1Bp?= =?utf-8?B?SEpPN2t0bG9UK3JkaWRoelJIRnNjUngyN2xUSVNwT3lrN1hlb0VnVE9lZ0Iz?= =?utf-8?B?ZW11NWp2SW5aZ2VOZWFPR25ZWnpZNFd6UVlIeHBLeVFNTmJvazBHbWVMOWcy?= =?utf-8?B?Y0dLbVpSR1kzMkxnWFV4M2YvelB1ZFFhTlluT0taMTNUU3F3cStzMklVUERu?= =?utf-8?B?cHliNE04MkhhU0g5L093cXY0QmFOZ2VUSWwvVXhwSHVtTVBVbVpmYmpaMnZa?= =?utf-8?B?U0tFTmFBclJOVXVXMEhIbVR0aFFkTTROWTJKcThoaGJVcUhTYVpzdHB3akFC?= =?utf-8?B?dFdValhUeHh6TCs2VVM1WXBZdFNQL3dKNitPelZkK1pkYTlkV0FmLzc1ZjFT?= =?utf-8?B?cFpXOCsyam5Ea0ZqejNUMWtjU1BicUw0aERkdjZVMGRiU09tWnp5YjZ6TnRW?= =?utf-8?B?eTFmcmQ3emQrQkNHODVwQT09?= x-microsoft-antispam-prvs: x-forefront-prvs: 09634B1196 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(346002)(376002)(396003)(366004)(199004)(189003)(71200400001)(71190400001)(33656002)(82746002)(58126008)(93886005)(97736004)(478600001)(8936002)(102836004)(54906003)(6512007)(2906002)(99286004)(6506007)(6346003)(53936002)(83716004)(316002)(76176011)(5660300002)(68736007)(6436002)(86362001)(2616005)(6116002)(486006)(6486002)(44832011)(186003)(36756003)(229853002)(25786009)(8676002)(46003)(81156014)(446003)(81166006)(4326008)(11346002)(105586002)(14454004)(256004)(14444005)(6246003)(106356001)(6916009)(476003)(305945005)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1036; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 9C4gdyB5SzicWHcRcCN430Zn/7UwkYPa/4FU4iHhV4U0misolxuAEOpAdI5fCsvAhnJ3zUbXJy6Ki3fqx/20Acw4yUQpOTGLAuoitX1WMrOGZe0hvrrb76T6hvANqRFrrIoZy7c64XHv0YBuJvWSoHi6GOdsnYSb1/4WHsud7Zt10bd2WE18JBLcJFfa2xPD62kR98VTxtrgwgiR6jLZybcy3oRqv8c0uMfV7EHZx8n/+j2HwdS4pWqlV4H/EgvT92y7bllTlZ7a7ftPbsUhXVAzWDCPtGFg2tQ7UM2l58RwRP0ICLiVyTfA717TqaxWOuNR1CRcXll1dbfBtaS178y5nJ/NZK3glWROxoKEQX7x1ay4zqHFEccanoSmjWmAOefphGN7EyUYEDEVu6XFIQozac7CbQJ6CWGARoArBWM= Content-Type: text/plain; charset="utf-8" Content-ID: <12BEE6D65280B54CA089DDA2745B82C9@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d589d906-47e0-4ec8-f54c-08d69e31c5f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2019 10:36:32.9660 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1036 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGfXfv3HW1el0uj1ZgKyENP5LQmZImJIMwDJLKJjnyoqJO2VVx RWUafbgpMwxyf6TlzE9cmmGpWJozaqRkRegqk4bOUpRsmR9I3l2L/vud5zw853nhpQhxBd+b Slfl0mqVMlPqKiQrT3bkBcg2aBTB90Y3y6puWASy0vm7hMzxu801mpAbjYs8ueGJjYznJQoj U+jM9HxaHXQwWZhWO7DMz1nyKTA7llAh0vmUIDcK8H4w2a+jEiSkxLgfwa+RfpIbHAimOsz8 f0P5xAdXbqjhQZG+wWkjsZ6A5S67gA0TYz0PZrp5HI8juPrsRAmiKFcsA+3qXlb2wFKYLH5E skzgZHh7+7vTvgWHwkJXKcl5wqDL2irgOBZ6KnUEyyTeDUOfSgRspAhHwUB9AtdnDEFTWY8z x21N11nnEMsIb4WFV8087pYnjNqqeNybMRi7hwiOJTD1dZXPsgQHQXvZF5LTw8FuaVz37IDh Ki3iOA5aFl4I2MOARxD0Lnaum/yhbvgn4hZmd5gfLF5PyoBrzRaSbQ14O9S3XOBkGx+mJr30 KNjwXz/DmovAfmDqDOJkOTzsfyPgeCdUaMedLMLu8LLSRlYjfiOSMDTDZKWGhATS6vSzDJOt ClTRuW1o7a/0ti8feIx6Jw/1IUwh6UZRgkCjEPOV+Ywmqw8BRUg9RJtc1iRRilJzjlZnn1Hn ZdJMH9pGkVJP0YrYXSHGqcpcOoOmc2j13y2PcvMuRP6KmemLcXbdRESk8Nvgqsbr6Y9piLMe SYnOW5GJva/4EhFhc3c+Wxz3A8PPz1oCPp6qmjD7vt/lebPg2OnyPT5jzQ3pS5d8615LjNqj s1SMtc4wU1cYVRQqDkosR7XHKy4HP0gy6WP8DkdWa+JdapLki7FqU/bSreejTe/I/FYpyaQp 9/kTakb5B6I2h5cnAwAA Archived-At: Subject: Re: [sipcore] Draft new version: SIP Push -26 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 10:36:45 -0000 SGksDQoNCiAgICA+Pj4gICDCpzQuMToNCiAgICA+Pj4gDQogICAgPj4+ICAgLSAiRm9yIHByaXZh Y3kgYW5kIHNlY3VyaXR5IHJlYXNvbnMsIGEgVUEgTVVTVCBOT1QgaW5zZXJ0IHRoZSBTSVAgVVJJ DQogICAgPj4+ICAgcGFyYW1ldGVycyAoZXhjZXB0IGZvciB0aGUgcG4tcHVyciBwYXJhbWV0ZXIp 4oCdDQogICAgPj4+IA0KICAgID4+PiAgIFRoZSDigJxleGNlcHQgZm9yIHRoZSBwbi1wdXJyIHBh cmFtZXRlcuKAnXBhcnQgaXMgcGFydCBvZiB0aGUgbm9ybWF0aXZlIHJlcXVpcmVtZW50LiBQbGVh c2UgZG9u4oCZdCBidXJ5IGl0IGluIGEgcGFyZW50aGV0aWNhbCBwaHJhc2UuDQogICAgPj4+IA0K ICAgID4+PiAgIC0gImluIG5vbi1SRUdJU1RFUiByZXF1ZXN0Ig0KICAgID4+PiANCiAgICA+Pj4g ICBQbHVyYWwgRGlzYWdyZWVtZW50DQogICAgPj4gDQogICAgPj4gQ2FuIHlvdSBzdWdnZXN0IGJl dHRlciB3b3JkaW5nPw0KICAgID4NCiAgICA+IGVpdGhlciDigJxpbiBub24tUkVHSVNURVIgcmVx dWVzdHPigJ0gb3Ig4oCcaW4gYSBub24tUkVHSVNURVIgcmVxdWVzdOKAnS4NCiAgICANCiAgICBB YWFoLCBub3cgSSBnZXQgaXQuIFRoZSBpbnRlbnRpb24gd2FzIHNvIHNheSAiaW4gbm9uLVJFR0lT VEVSIHJlcXVlc3RzIi4gSSB3aWxsIGZpeCBpdC4NCg0KICAgIC0tLQ0KICAgICANCiAgICA+Pj4g ICAtICJyZXF1ZXN0IHRoYXQNCiAgICA+Pj4gICBhIHB1c2ggbm90aWZpY2F0aW9uIGlzIHNlbnTi gJ0NCiAgICA+Pj4gDQogICAgPj4+ICAgcy9pcy9iZSAgKG5vdGUgdGhhdCB0aGlzIHBhdHRlcm4g b2NjdXJzIG1hbnkgdGltZXMgaW4gdGhlIGRyYWZ0LikNCiAgICA+PiANCiAgICA+PiBBcyBJIGlu ZGljYXRlZCB0byBKZWFuLCB0aGUgd29yZGluZyBpcyB0aGUgb3V0Y29tZSBvZiB0aGUgcHJldmlv dXMgZGlzY3Vzc2lvbnMgYXNzb2NpYXRlZCB3aXRoIEVrcidzIElFU0cgcmV2aWV3Lg0KICAgID4N CiAgICA+IEnigJlkIGJlIGhpZ2hseSBzdXJwcmlzZWQgaWYgZWtyIG9iamVjdGVkIHRvIOKAnGJl 4oCdLiAgaXQgaXMgbW9yZSBncmFtbWF0aWNhbGx5IGNvcnJlY3QgdGhhbiDigJxpc+KAnS4gVGhl IHN1Ymp1bmN0aXZlIOKAnGJlIiBmb3JtIGlzIGluZGljYXRlZCBieSB0aGUgZmFjdCB0aGF0IHdl IHRhbGsgYWJvdXQgYSByZXF1ZXN0IGZvciBzb21ldGhpbmcgdG8gaGFwcGVuLCBub3QgYSBzdGF0 ZW1lbnQgdGhhdCBzb21ldGhpbmcgaXMgdHJ1ZS4NCiAgICA+DQogICAgPiBJ4oCZbSBub3QgZ29p bmcgdG8gYmxvY2sgdGhpbmdzIG92ZXIgaXQsIGJ1dCBJIHdvdWxkIGJldCBhIGJlZXIgdGhhdCB0 aGUgUkZDIGVkaXRvciBjaGFuZ2VzIGl0LiA6LSkNCiAgICANCiAgICBTbywgeW91IHdhbnQgdG8g c2F5ICJyZXF1ZXN0IHRoYXQgYSBwdXNoIG5vdGlmaWNhdGlvbiBiZSBzZW50Ij8NCg0KICAgIElm IHRoYXQncyBtb3JlIGdyYW1tYXRpY2FsbHkgY29ycmVjdCBJIHdpbGwgZml4IGFzIHN1Z2dlc3Rl ZC4NCg0KICAgIC0tLQ0KICAgICAgICANCiAgICA+Pj4gICAtICJBIGJpbmRpbmcgZXhwaXJhdGlv biBpbnRlcnZhbCBNVVNUIGJlIGNvbnNpZGVyZWQgdG9vIHNob3J0IGlmIHRoZQ0KICAgID4+PiAg IGJpbmRpbmcgd291bGQgZXhwaXJlIGJlZm9yZSB0aGUgcHJveHkgd291bGQgcmVxdWVzdCB0aGF0 IGEgcHVzaA0KICAgID4+PiAgIG5vdGlmaWNhdGlvbiBpcyBzZW50IHRvIHRoZSBVQeKAnQ0KICAg ID4+PiANCiAgICA+Pj4gICBJ4oCZbSBub3Qgc3VyZSB3aGF0IHRvIG1ha2Ugb2YgdGhhdCBzZW50 ZW5jZS4gUHJlc3VtYWJseSB0aGUgcHJveHkgd2lsbCByZXF1ZXN0IHRoZSBQTiB3aGVuIGl0IG5l ZWRzIHRvDQogICAgPj4+ICBkbyBzby4gUGVyaGFwcyB0aGUg4oCcd291bGTigJ0gaW4g4oCccHJv eHkgd291bGQgcmVxdWVzdOKAnSBzaG91bGQgYmUg4oCcY2Fu4oCdPyAoVGhhdCBpcywgdGhlIGlu dGVydmFsIGlzIHNvIHNob3J0IHRoZQ0KICAgID4+PiAgcHJveHkgaXMgdW5hYmxlIHRvIHJlcXVl c3QgYSBQTiBpbiB0aW1lPykNCg0KICAgIFNlZW1zIGxpa2UgSSBza2lwcGVkIHRoaXMgaW4gbXkg ZWFybGllciByZXBseS4gSSBhZ3JlZSB0aGF0ICJjYW4iIGlzIGJldHRlciwgc28gSSB3aWxsIGZp eCBhcyBzdWdnZXN0ZWQuDQoNCiAgICAtLS0NCiAgICANCiAgICANCiAgICA+Pj4gICDCpzUuNi4x LjIgYW5kIMKnNS42LjI6IEFyZSB0aGUgbGlzdHMgb2YgcHJvY2VkdXJlIHN0ZXBzIHN1cHBvc2Vk IHRvIGhhdmUgYnVsbGV0cyBvciBudW1iZXJzPw0KICAgID4+IA0KICAgID4+IE5vDQogICAgPj4g DQogICAgPj4gSSB0aGluayB0aGUgcHJvY2VkdXJlcyBhcmUgdmVyeSBjbGVhciB0aGFua3MgdG8g dGhlIHBhcmFncmFwaCBzZXBhcmF0aW9uLg0KICAgID4NCiAgICA+IERvIHlvdSBtZWFuIHRoZSBp bmRlbnRhdGlvbj8gVHJhZGl0aW9uYWxseSBpbmRlbnRhdGlvbiBoYXMgYmVlbiB1c2VkIGluIFJG Q3MgdG8gc2hvdyBwYXJlbnRoZXRpY2FsIGV4cGxhbmF0aW9ucyBvciBzaWRlYmFycy4gDQogICAg PiBBbHNvLCB0aGUgdXNlIG9mIHRoZSBpbmRlbnRlZCBsaXN0IHJlbW92ZXMgdGhlIHdoaXRlIHNw YWNlIGJldHdlZW4gdGhlIHBhcmFncmFwaHMsIHdoaWNoIG1ha2VzIHRoZW0gaGFyZGVyIHRvIHJl YWQuDQogICAgPg0KICAgID4gQnVsbGV0cyB3b3VsZCBtYWtlIHRoZW0gZWFzaWVyIHRvIHJlYWQs IGFuZCB3b3VsZCBiZSBtb3JlIGNvbnNpc3RlbnQgd2l0aCBzaW1pbGFyIHByb2NlZHVyZSBsaXN0 cyBlYXJsaWVyIGluIHRoZSBkcmFmdC4NCiAgICANCiAgICBBYWFhaC4uLi4gSSBzZWUgd2hhdCB5 b3UgbWVhbiAoc2VlbXMgbGlrZSBJIHdhcyB0b28gdGlyZWQgd2hlbiBJIHJlcGxpZWQgeWVzdGVy ZGF5KS4NCg0KICAgIFllcywgdGhlIGluZGVudGVkIHByb2NlZHVyZXMgc2hhbGwgaGF2ZSBidWxs ZXRzLiBUaGF0IHdhcyB0aGUgaW50ZW50aW9uLiBJIGNoZWNrZWQgdGhlIFhNTCwgYW5kIHRoZSB0 ZXN0IGlzIGEgPGxpc3Q+LCBidXQgSSBoYXZlIGZvcmdvdHRlbiANCiAgICB0byBhZGQgdGhlIGJ1 bGxldHMuIEkgd2lsbCBkbyB0aGF0Lg0KDQogICAgUmVnYXJkcywNCg0KICAgIENocmlzdGVyIA0K DQo= From nobody Fri Mar 1 03:21:07 2019 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 877F5130E2F for ; Fri, 1 Mar 2019 03:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=XhSkoYPf; dkim=pass (1024-bit key) header.d=ericsson.com header.b=XD7qzBt7 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 2Tl6wpKJ-6QK for ; Fri, 1 Mar 2019 03:21:02 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49EBB12D4F0 for ; Fri, 1 Mar 2019 03:21:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551439259; x=1554031259; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3v7MXXKve6ZkPMQUwV0+yVNdmEl29QvvcCBbZuP1+0k=; b=XhSkoYPf1oPemipt3WewbaWKRI7D9G3icNl2of1m3eeizqZnjzEH/UN7LTg+LROE Smz+XzuNzC/Ec/1rhSxEnKj3STtRt/fb4ZlNOJrh5loZ6oersBWgN6q9CY3haUuy p158ekPNmKwjRvV3LAWBIgwEW/uzXyL7jYnSnDevv3A=; X-AuditID: c1b4fb25-209009e000005ff7-e3-5c79159b5ea5 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CA.43.24567.B95197C5; Fri, 1 Mar 2019 12:20:59 +0100 (CET) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Mar 2019 12:20:56 +0100 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 1 Mar 2019 12:20:56 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3v7MXXKve6ZkPMQUwV0+yVNdmEl29QvvcCBbZuP1+0k=; b=XD7qzBt7JPofLfU+XgSwAUr1X+wW+H7NAuxbXAl2iuzitcCVWK71BLQMpv1oioEAi/49i0wpdGY2iVkxDUSlcCco56dz0/Dppl047NM/UXXXjUl60THnVwR/Lo7PC6ICTO1vz9Dg87FeOM5a6OKtWbiZAYsyizjAttod39VIpyk= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.10; Fri, 1 Mar 2019 11:20:55 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae%3]) with mapi id 15.20.1686.011; Fri, 1 Mar 2019 11:20:55 +0000 From: Christer Holmberg To: Ben Campbell , Yehoshua Gev CC: "sipcore@ietf.org" , "sipcore-chairs@ietf.org" Thread-Topic: [sipcore] Draft new version: SIP Push -26 - the pull request Thread-Index: AQHU0CDWFirrfLg2r02YWYZoncasoQ== Date: Fri, 1 Mar 2019 11:20:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [2001:14b8:1829:11:9032:6c5a:3308:5eb7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2e9d6242-04f6-4fe4-47a0-08d69e37f8c3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4236; x-ms-traffictypediagnostic: HE1PR07MB4236: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUI0MjM2OzIzOitkN0g5cWR5TnlxbXpZeVBBb0J2WGtmLzha?= =?utf-8?B?YWlHN3B6UFpRZGQ1WEFwNjdxZWpvNzU5YjhMRC9sVDd2QzlqVk5FeElkTHFn?= =?utf-8?B?WERQejc3aHJ1SC84dUZJRW12T1VnM2ZPbmcvUnFnWU5vZHJsYXJ4YzdCbEp3?= =?utf-8?B?YVM5TnZKTDFWQlpyTVd1SnJVY1NTYkhQR3ZXVjNsNUxPNGwvS2dXSTc0cnhj?= =?utf-8?B?NHlhN1IrWWt4WXdzYkc4YkV3Q2dxMlVEdXE2VGwzbEZ1M3pXdmhmMzhoS0tP?= =?utf-8?B?WWdqSnVRWnB4bmlvUHAyTDBoT0RzYTB3cVVjZkVQTFFWa1ZnSVhCcWhJTjFu?= =?utf-8?B?WXBwbk1QUlZla2FJNUI2TVgyOEhubzgwTXJOMjI2aWtNMEU3WlhneFkzT3hj?= =?utf-8?B?UzhtTlUrV3RPZ1dzWld5T0RxRUE4czBNNndpdmlORk9WSTB4SmlEZ1ZIcW1D?= =?utf-8?B?c05zQ3NJRUZwVFNjVmRjY1k0VFdNYXlnU0R2QVUxVnYyMHloV3lVVi9jZmZi?= =?utf-8?B?ZTBrRmZSMDFJWjg4MXd4TDRJVFpOcHo0UFVWVHlaUGRmK3lLbXluUG9WNUtQ?= =?utf-8?B?MnJZYU9odCsxNjlxR0syL28rNGo5STRJR2t5aHNRemxLMXYvN2Q4d0RHZzlp?= =?utf-8?B?eldsaWF2aW45aFh0SGNvSmwzSWMyWldybTVXNlpWRmYyVTkxakladU10bDg5?= =?utf-8?B?dVlaM0NmOThESmhUdWdDZSs3T1p4NEJteWREQTBadUxscFJnclNqZlhPRFJN?= =?utf-8?B?RTJOZHprZXpqZG5XRDh0ZUJXQXBTM21RRnFTT0FwNjRXcUk3dFdodFdncFNW?= =?utf-8?B?emdyenBmWFlwU0NvWSs4M3NrNStTdWxlaVdpUnp4Q2dqcU9rUW5oelRmUFRq?= =?utf-8?B?d3lveUVxRDRlUm1nMkd0RENNYTRqY1NnWVZaaFhZRWphK0NkVzNCSS9mZTlj?= =?utf-8?B?emdUZHlCZHpaV21aSnlnSHU5OGlZaFpoOS9aajBaeTNoRUl0RGx6ZGxRU3lz?= =?utf-8?B?S1p0cUV3dnpNOUpVRVdGcEZhVTk2Njkzc2hWTmdiWW00MUVXdHJXT2VkQ2VI?= =?utf-8?B?Z0VaYTFwZStwa2ZaWWxVVWwxTmtjVEwxTG92WWgzOTQ1dXhrYVpxUVd2c1Qv?= =?utf-8?B?S0Q3OVZXekpmSElSelFFZ1FUekp0am9zSm5ucnp6RlluUHI1ZUl3QnVpem5B?= =?utf-8?B?S1ZQRE5VQjB3TjJxcTJLdU16ZFR1KytqU3c0Uk44UDRyWWl3cnJoT2NJQnVS?= =?utf-8?B?YzFxaWd5WGh3b3lqQUorT2dodktBUzZCekM5S2FLTVpkdlNKcUJOZUNacHk2?= =?utf-8?B?ZGtJVEdlNXp0ZVp5YjlRZTFXd09idGtYV3RDOVFSQk9iWlB0TENCYXk3SmtI?= =?utf-8?B?NnNZSGN5cjZQRy9HUjh0cCswd0VxY2tmUExWNERDVjdMcm9XYkdSRU8wdTE5?= =?utf-8?B?UnpLZ1JWL0hBT1hBNUNZV0N2SXlDajVSR0RYOVFuZVp3bUhzQmtyMzhYSUVp?= =?utf-8?B?bS9DSExjdEI4SlhmKzBmWXdiY1ltNHp1NStTdmdXTTdLUDYzU2l5ZXRxbm5S?= =?utf-8?B?WVBtVFhwWHViQTRBSkw4WTZlTkRmRzY2TkNMQ3QrU0FaMlFXTWpmcE1WNERF?= =?utf-8?B?STBVMjVLcFdxOUdhKzhRUFVyM3FwOW1OWXV3MFM2Z1NKM29Ra2hiRnBnPT0=?= x-microsoft-antispam-prvs: x-forefront-prvs: 09634B1196 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(39860400002)(346002)(136003)(366004)(189003)(199004)(316002)(8936002)(6116002)(68736007)(54906003)(14454004)(186003)(478600001)(58126008)(2906002)(305945005)(966005)(99286004)(82746002)(7736002)(110136005)(86362001)(46003)(33656002)(14444005)(256004)(6246003)(97736004)(6436002)(486006)(44832011)(6486002)(71190400001)(83716004)(476003)(71200400001)(6306002)(6512007)(53936002)(4326008)(106356001)(36756003)(25786009)(105586002)(8676002)(102836004)(81166006)(2616005)(81156014)(6506007)(5660300002)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4236; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5XOJuxVoaT9pEacmwg5azIdn6+z/asxwW/gg2tZ/OrRGB5MDPRHdYGvA2+0Jw4165zcoaLke9Wtp9UOPb3lVfbw5MlqL6ZitSYxbbIaANOQdyTHM9aYNOFSsVGgi2ZEnoILDl2yZWi1XvqNnv8SuVWCwA7Zqq/SA+Z2cNWLVh9PE9qYQi6JiaWsphwPj0BEMaXXZTm73Tsl1fM7OnPO2WAJWlfrV0m7MTj4GAGdssk24S5X20gYMc8VrcyyLdeQHd3X4C16OstT2X9xBvM3GXrKE32464GGrWgFOhLxLJSO1xoHp/CvfYW1WWwYmYGUv2qUIqv38ayRvgHb8jK/K+GUuIwNJPlXelpEKRnOXQYQVcWTGXS2Uol1IyLoJvfI69OVLMKLaCwyqD67sD3I/kFPVg7Jo/3Vz+x483a5HOEw= Content-Type: text/plain; charset="utf-8" Content-ID: <19562DA19052E742824ADE0EF7D10A6E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2e9d6242-04f6-4fe4-47a0-08d69e37f8c3 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2019 11:20:55.1409 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4236 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGPffebdfh7Dg1X9QIlyVqzW9aEGmROQNTCiJDyFteVNQ5tmVZ CAZFpmiW/qETWqZmqWWJ4EeKtAymVjoHaR+KHxtpCzTDNFaa213Qf7/nfZ73nPO+HJoU3+f5 0tkKDatSMLkSvpCqPdN1aV+dd2Fa+IrZXaa7NSKQlf+oJ2Wr6x18me35FBlHyXu0UwJ5Y+Mv Qq7tMVMp5FnhwQw2N7uAVYUdShdmGS0TPOVk6OV7liWyGBlCSpErDTga3iz3kaVISIvxIIL6 kmsEJ1YRjE8NOkUDAeOlM3y7oHAlCQtDBsQ5VQQYb5soTswimLtZv+XQNB/LoGwj1H6JF46H zVcDpJ1JnA6mGithZ0+cCM9aVgVc5jjMlfcSHEtBv7iM7EzhQOh/2MSzswjHgmGpxMEIb4e1 4TaCO9MHPpp1BDcQhsa+UZJjb1ic33DkvXEYdFbMUFwvAwMtM87MAVgYaXHyDhjXlSGOk2DT 2u5YDOAPCPq7up1GCHR/fUdx7Atr898FXMiEYVlb7nxFDlgsNTz7IgD7w6OnRVzGwINPxlJH sxiz0PzkBqpEUu1/Q2i3WkgcDO29YVxZDtU2s4DjAKgum3WwCHvAUK2Zuo94LchbzarP52VG RklZVfYFtTpfIVWwmg609W9edtp2dyPTt8N6hGkkcRPdERSmiXlMgbowT4+AJiVeIneXrZIo gym8wqryz6ku5rJqPfKjKYmP6LfYI02MMxkNm8OySlb1zyVoV99iVNH5Xrn3VGxUyk83F+vO z6LTVfOvSVuAtMBvW6uv7oHnH8mKLa7ybbvhqOd1cUJa8pdJQ0TbyZWkpLvHjmjCi6wTTINl NOjxUkzwLlG0ooke69X5T6QLm+taT6RuKl9EJu53MQYNx5fPSPrWp8MykxMSlGPWnIxAWUzq 1T1VzLSEUmcxESGkSs38BX8LgVMzAwAA Archived-At: Subject: Re: [sipcore] Draft new version: SIP Push -26 - the pull request X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 11:21:06 -0000 SGksDQoNCkJhc2VkIG9uIEJlbidzIGNvbW1lbnRzLCBJIGhhdmUgY3JlYXRlZCBhIHB1bGwgcmVx dWVzdDoNCg0KaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LXNpcC1wdXNoL3B1bGwvMzgN Cg0KSSBhbHNvIGFkZGVkIGFuIGV4YW1wbGUgd2l0aCB0aGUgJ3NpcC5wbnNyZWcnIG1lZGlhIGZl YXR1cmUgdGFnIGFuZCBmZWF0dXJlLWNhcGFiaWxpdHkgaW5kaWNhdG9yLCBhcyByZXF1ZXN0ZWQg YnkgWWVob3NodWEuDQoNCklmIHBlb3BsZSBhcmUgb2sgd2l0aCB0aGUgY2hhbmdlcywgSSdkIHBy ZWZlciB0byBtZXJnZSB0aGUgcHVsbCByZXF1ZXN0IGFuZCBzdWJtaXQgYSBuZXcgdmVyc2lvbiBv ZiB0aGUgZHJhZnQgYmVmb3JlIGl0IGdvZXMgdG8gQVVUSDQ4IGV0Yy4NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KDQoNCu+7v09uIDAxLzAzLzIwMTksIDEyLjM3LCAic2lwY29yZSBvbiBiZWhh bGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmciIDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQoNCiAgICBIaSwN CiAgICANCiAgICAgICAgPj4+ICAgwqc0LjE6DQogICAgICAgID4+PiANCiAgICAgICAgPj4+ICAg LSAiRm9yIHByaXZhY3kgYW5kIHNlY3VyaXR5IHJlYXNvbnMsIGEgVUEgTVVTVCBOT1QgaW5zZXJ0 IHRoZSBTSVAgVVJJDQogICAgICAgID4+PiAgIHBhcmFtZXRlcnMgKGV4Y2VwdCBmb3IgdGhlIHBu LXB1cnIgcGFyYW1ldGVyKeKAnQ0KICAgICAgICA+Pj4gDQogICAgICAgID4+PiAgIFRoZSDigJxl eGNlcHQgZm9yIHRoZSBwbi1wdXJyIHBhcmFtZXRlcuKAnXBhcnQgaXMgcGFydCBvZiB0aGUgbm9y bWF0aXZlIHJlcXVpcmVtZW50LiBQbGVhc2UgZG9u4oCZdCBidXJ5IGl0IGluIGEgcGFyZW50aGV0 aWNhbCBwaHJhc2UuDQogICAgICAgID4+PiANCiAgICAgICAgPj4+ICAgLSAiaW4gbm9uLVJFR0lT VEVSIHJlcXVlc3QiDQogICAgICAgID4+PiANCiAgICAgICAgPj4+ICAgUGx1cmFsIERpc2FncmVl bWVudA0KICAgICAgICA+PiANCiAgICAgICAgPj4gQ2FuIHlvdSBzdWdnZXN0IGJldHRlciB3b3Jk aW5nPw0KICAgICAgICA+DQogICAgICAgID4gZWl0aGVyIOKAnGluIG5vbi1SRUdJU1RFUiByZXF1 ZXN0c+KAnSBvciDigJxpbiBhIG5vbi1SRUdJU1RFUiByZXF1ZXN04oCdLg0KICAgICAgICANCiAg ICAgICAgQWFhaCwgbm93IEkgZ2V0IGl0LiBUaGUgaW50ZW50aW9uIHdhcyBzbyBzYXkgImluIG5v bi1SRUdJU1RFUiByZXF1ZXN0cyIuIEkgd2lsbCBmaXggaXQuDQogICAgDQogICAgICAgIC0tLQ0K ICAgICAgICAgDQogICAgICAgID4+PiAgIC0gInJlcXVlc3QgdGhhdA0KICAgICAgICA+Pj4gICBh IHB1c2ggbm90aWZpY2F0aW9uIGlzIHNlbnTigJ0NCiAgICAgICAgPj4+IA0KICAgICAgICA+Pj4g ICBzL2lzL2JlICAobm90ZSB0aGF0IHRoaXMgcGF0dGVybiBvY2N1cnMgbWFueSB0aW1lcyBpbiB0 aGUgZHJhZnQuKQ0KICAgICAgICA+PiANCiAgICAgICAgPj4gQXMgSSBpbmRpY2F0ZWQgdG8gSmVh biwgdGhlIHdvcmRpbmcgaXMgdGhlIG91dGNvbWUgb2YgdGhlIHByZXZpb3VzIGRpc2N1c3Npb25z IGFzc29jaWF0ZWQgd2l0aCBFa3IncyBJRVNHIHJldmlldy4NCiAgICAgICAgPg0KICAgICAgICA+ IEnigJlkIGJlIGhpZ2hseSBzdXJwcmlzZWQgaWYgZWtyIG9iamVjdGVkIHRvIOKAnGJl4oCdLiAg aXQgaXMgbW9yZSBncmFtbWF0aWNhbGx5IGNvcnJlY3QgdGhhbiDigJxpc+KAnS4gVGhlIHN1Ymp1 bmN0aXZlIOKAnGJlIiBmb3JtIGlzIGluZGljYXRlZCBieSB0aGUgZmFjdCB0aGF0IHdlIHRhbGsg YWJvdXQgYSByZXF1ZXN0IGZvciBzb21ldGhpbmcgdG8gaGFwcGVuLCBub3QgYSBzdGF0ZW1lbnQg dGhhdCBzb21ldGhpbmcgaXMgdHJ1ZS4NCiAgICAgICAgPg0KICAgICAgICA+IEnigJltIG5vdCBn b2luZyB0byBibG9jayB0aGluZ3Mgb3ZlciBpdCwgYnV0IEkgd291bGQgYmV0IGEgYmVlciB0aGF0 IHRoZSBSRkMgZWRpdG9yIGNoYW5nZXMgaXQuIDotKQ0KICAgICAgICANCiAgICAgICAgU28sIHlv dSB3YW50IHRvIHNheSAicmVxdWVzdCB0aGF0IGEgcHVzaCBub3RpZmljYXRpb24gYmUgc2VudCI/ DQogICAgDQogICAgICAgIElmIHRoYXQncyBtb3JlIGdyYW1tYXRpY2FsbHkgY29ycmVjdCBJIHdp bGwgZml4IGFzIHN1Z2dlc3RlZC4NCiAgICANCiAgICAgICAgLS0tDQogICAgICAgICAgICANCiAg ICAgICAgPj4+ICAgLSAiQSBiaW5kaW5nIGV4cGlyYXRpb24gaW50ZXJ2YWwgTVVTVCBiZSBjb25z aWRlcmVkIHRvbyBzaG9ydCBpZiB0aGUNCiAgICAgICAgPj4+ICAgYmluZGluZyB3b3VsZCBleHBp cmUgYmVmb3JlIHRoZSBwcm94eSB3b3VsZCByZXF1ZXN0IHRoYXQgYSBwdXNoDQogICAgICAgID4+ PiAgIG5vdGlmaWNhdGlvbiBpcyBzZW50IHRvIHRoZSBVQeKAnQ0KICAgICAgICA+Pj4gDQogICAg ICAgID4+PiAgIEnigJltIG5vdCBzdXJlIHdoYXQgdG8gbWFrZSBvZiB0aGF0IHNlbnRlbmNlLiBQ cmVzdW1hYmx5IHRoZSBwcm94eSB3aWxsIHJlcXVlc3QgdGhlIFBOIHdoZW4gaXQgbmVlZHMgdG8N CiAgICAgICAgPj4+ICBkbyBzby4gUGVyaGFwcyB0aGUg4oCcd291bGTigJ0gaW4g4oCccHJveHkg d291bGQgcmVxdWVzdOKAnSBzaG91bGQgYmUg4oCcY2Fu4oCdPyAoVGhhdCBpcywgdGhlIGludGVy dmFsIGlzIHNvIHNob3J0IHRoZQ0KICAgICAgICA+Pj4gIHByb3h5IGlzIHVuYWJsZSB0byByZXF1 ZXN0IGEgUE4gaW4gdGltZT8pDQogICAgDQogICAgICAgIFNlZW1zIGxpa2UgSSBza2lwcGVkIHRo aXMgaW4gbXkgZWFybGllciByZXBseS4gSSBhZ3JlZSB0aGF0ICJjYW4iIGlzIGJldHRlciwgc28g SSB3aWxsIGZpeCBhcyBzdWdnZXN0ZWQuDQogICAgDQogICAgICAgIC0tLQ0KICAgICAgICANCiAg ICAgICAgDQogICAgICAgID4+PiAgIMKnNS42LjEuMiBhbmQgwqc1LjYuMjogQXJlIHRoZSBsaXN0 cyBvZiBwcm9jZWR1cmUgc3RlcHMgc3VwcG9zZWQgdG8gaGF2ZSBidWxsZXRzIG9yIG51bWJlcnM/ DQogICAgICAgID4+IA0KICAgICAgICA+PiBObw0KICAgICAgICA+PiANCiAgICAgICAgPj4gSSB0 aGluayB0aGUgcHJvY2VkdXJlcyBhcmUgdmVyeSBjbGVhciB0aGFua3MgdG8gdGhlIHBhcmFncmFw aCBzZXBhcmF0aW9uLg0KICAgICAgICA+DQogICAgICAgID4gRG8geW91IG1lYW4gdGhlIGluZGVu dGF0aW9uPyBUcmFkaXRpb25hbGx5IGluZGVudGF0aW9uIGhhcyBiZWVuIHVzZWQgaW4gUkZDcyB0 byBzaG93IHBhcmVudGhldGljYWwgZXhwbGFuYXRpb25zIG9yIHNpZGViYXJzLiANCiAgICAgICAg PiBBbHNvLCB0aGUgdXNlIG9mIHRoZSBpbmRlbnRlZCBsaXN0IHJlbW92ZXMgdGhlIHdoaXRlIHNw YWNlIGJldHdlZW4gdGhlIHBhcmFncmFwaHMsIHdoaWNoIG1ha2VzIHRoZW0gaGFyZGVyIHRvIHJl YWQuDQogICAgICAgID4NCiAgICAgICAgPiBCdWxsZXRzIHdvdWxkIG1ha2UgdGhlbSBlYXNpZXIg dG8gcmVhZCwgYW5kIHdvdWxkIGJlIG1vcmUgY29uc2lzdGVudCB3aXRoIHNpbWlsYXIgcHJvY2Vk dXJlIGxpc3RzIGVhcmxpZXIgaW4gdGhlIGRyYWZ0Lg0KICAgICAgICANCiAgICAgICAgQWFhYWgu Li4uIEkgc2VlIHdoYXQgeW91IG1lYW4gKHNlZW1zIGxpa2UgSSB3YXMgdG9vIHRpcmVkIHdoZW4g SSByZXBsaWVkIHllc3RlcmRheSkuDQogICAgDQogICAgICAgIFllcywgdGhlIGluZGVudGVkIHBy b2NlZHVyZXMgc2hhbGwgaGF2ZSBidWxsZXRzLiBUaGF0IHdhcyB0aGUgaW50ZW50aW9uLiBJIGNo ZWNrZWQgdGhlIFhNTCwgYW5kIHRoZSB0ZXN0IGlzIGEgPGxpc3Q+LCBidXQgSSBoYXZlIGZvcmdv dHRlbiANCiAgICAgICAgdG8gYWRkIHRoZSBidWxsZXRzLiBJIHdpbGwgZG8gdGhhdC4NCiAgICAN CiAgICAgICAgUmVnYXJkcywNCiAgICANCiAgICAgICAgQ2hyaXN0ZXIgDQogICAgDQogICAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBzaXBjb3Jl IG1haWxpbmcgbGlzdA0KICAgIHNpcGNvcmVAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCiAgICANCg0K From nobody Fri Mar 1 03:22:39 2019 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 49447130E2F for ; Fri, 1 Mar 2019 03:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=BgJN6URd; dkim=pass (1024-bit key) header.d=ericsson.com header.b=f2sOfgoz 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 Llsi3SMqKhd7 for ; Fri, 1 Mar 2019 03:22:34 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A244128B33 for ; Fri, 1 Mar 2019 03:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551439352; x=1554031352; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qds6gNHoCFg1YB0GacJ0BpbOKS/5qpIvcUawHvUkQ6w=; b=BgJN6URdnXlXedsaFZxWP+npoKURlQRVSCY9gRnU1DT47P9GfjULLLbAhS8PlpgZ RCmlkiRf7Az7yu8WSYNbjgwgZkzNQU/qMVG5n/87I0K+e4FyX2JJc7FqP+4Jvqbe k+V1r02DPw4TjQrRu9/K2HOG38u3jwySxnQxNYe+OWM=; X-AuditID: c1b4fb25-209009e000005ff7-63-5c7915f86edf Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E2.93.24567.8F5197C5; Fri, 1 Mar 2019 12:22:32 +0100 (CET) Received: from ESESBMR502.ericsson.se (153.88.183.134) by ESESBMB501.ericsson.se (153.88.183.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Mar 2019 12:22:27 +0100 Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESBMR502.ericsson.se (153.88.183.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Mar 2019 12:22:27 +0100 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 1 Mar 2019 12:22:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qds6gNHoCFg1YB0GacJ0BpbOKS/5qpIvcUawHvUkQ6w=; b=f2sOfgoz1PT1mh2V0mb+DCjAdcLFBJ50dLOXVudcKTN6MUMvl+0npNQNwq2uU4Qp7rBggrG69O/nqBN8f8XwnngVIXPucvJUX+DCGsHh83iHBQBe1O8ihsTLPumoK3AMjku6wSqfjPew5CKNcFwy7mqv0f3mLsQOL3qFKAS5TAo= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4299.eurprd07.prod.outlook.com (20.176.166.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.11; Fri, 1 Mar 2019 11:22:26 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae%3]) with mapi id 15.20.1686.011; Fri, 1 Mar 2019 11:22:26 +0000 From: Christer Holmberg To: Yehoshua Gev , "eburger@standardstrack.com" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Syntax of Feature-Caps header Thread-Index: AQHU0CEMPi1uLoVZd0+S4VzAw2AncQ== Date: Fri, 1 Mar 2019 11:22:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [2001:14b8:1829:11:9032:6c5a:3308:5eb7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 48d82324-db36-4916-0aca-08d69e382ede x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4299; x-ms-traffictypediagnostic: HE1PR07MB4299: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUI0Mjk5OzIzOi9uaTg2aGUwOUEvcUlJdDVIU0dvd2Z5ZldE?= =?utf-8?B?ZzZseXNlcVhGdzRkQnFMNFdNMlpQeGVjZU9mai9Zc3NtVkxLKzRPOUVOdGRM?= =?utf-8?B?MGlPNURSZ3ZzSnpFV0FyYUIxd1JObTZjdWh1TmFKZHIyOGplWGM5cVpwTzA1?= =?utf-8?B?WHNWbkNvUGdFS2JiVGJ0clhGcVpNbDZnNlB5ODZnWDE4ZWpKTXBOZ2kxdG16?= =?utf-8?B?aGZkNDhGcXgxU0tYblJjekhMQ3hob0wxdHNJM1gyRTlPV3FwK21MVlp1YkdV?= =?utf-8?B?cy9ZWENXUVRwOGQ2ZVFJUEE1VmZBcFd5S05qUlhNbHZFVHREQlZkRVlLcEJn?= =?utf-8?B?NWVUV2t4THhOVFVEOC9uVUFQR1JsY1VSQVZZWFRGWWhqalc0WHRjeVp0dDNH?= =?utf-8?B?Rlp5S1NXUWUxSWF3N1h1SitPNkYzS2NTM3kvRCtEYjlVTXE5RFBvNFQ0aE5M?= =?utf-8?B?bzJ0b3M2TGxVTVdnck9mUEJoMzRBR25hNFQrZXVVNytuOHJvQ3FSZ3BuNU9u?= =?utf-8?B?NkJUbXluQlhoV2lnZGk2Q0JPdUxUSnNCbXRYay9sUE5hd0dPOEtGUTUvM21j?= =?utf-8?B?Mktaa2ZZY0h0Y2dhR0hlMkpLOTJqS1VjQ3BQb0NPaFVxTm9Zc1BmZEhaUHls?= =?utf-8?B?SUNpRWsyZkdidWJXS1VGUFlzdlVYZ01EdFRwVzk1a01ERi9sVjI3OWYvQXgw?= =?utf-8?B?a3VQVVFhK045WG1oSzFkeDl5WU8vTEtObXdsbTVTZlBrR05naG1jZE5aME9M?= =?utf-8?B?SDhkNE56c0FFZzUzbEtoZVQrdXRPb1VuTlpxelRlZmU1Szc1dlVxb0hrMGQy?= =?utf-8?B?WndMejNpMHBTQkdJSEYvN01Oem5mK3lOenBOY3JWOElDSWNJWnJmeEs5YmM1?= =?utf-8?B?MVJIbU1JNmVaekhRVHZGV0o5bzFWc0pQbGgzU1FZT3JISjhGZVdNZU9ndHhi?= =?utf-8?B?ME5FM0xBZ2kySXNNdU4zOHZrMlVMZ3FOVklkMDZxcVN1L3EzckNQR0laMDRF?= =?utf-8?B?dW52dWgvay9DaU5HVCtiVnVwdVVnUmtMNWF3MEplVDV1eDFZVjZzbnB0dXZ6?= =?utf-8?B?SlhMQzhHQ2FOcS9lSkt0MDNqKzhXMVlaMmlxOWYvRXhtcStvTG54YUE4U0Na?= =?utf-8?B?VFUzUDFhc2VDRlQwckg0VThDSzdZY010enFITkNEMWJBUkJNekQ0ZTQ0bmtz?= =?utf-8?B?Y0NxSElOM2U0MEs2ckdzelhVeW16cWJORTcvZjFxR2VRckwyTzlZV01PRjRQ?= =?utf-8?B?Z3kvQkZqd1lUQTlDUXYxZkpqMFNBRXVZbU0rYzNBS0FXUUcyRFRJTWJwQzhG?= =?utf-8?B?eFdQZllJNSsxbkVQTTM4WDkrRGNaLzlBYXZUQjJsSlE2d2JFME9tc2JibFhM?= =?utf-8?B?VmU4SW8wLzY5WTVHWFZnNzFlRlAwNUlKYWpGMkJ1dENGQjlLS3EyLytyeUVX?= =?utf-8?B?bUJHVURyR1Jjc1BqeFVleVVNbGpCL0pUZEJjcnpCVGwzZEgvZ1ZuV05qZ1RI?= =?utf-8?B?ZEtoZzVuZ0o2Y0JwQXNGQ0FETUd2MmY2Z092MFZJSm5XQzNLVzRyR3Z1WGpE?= =?utf-8?B?Q0ZLSElNbzJXQ0NPY09oNjY4dy9WbUpkcnd0dmhaZzFtZEwrSTVHeGlpdE1j?= =?utf-8?B?cGZ1eXBHSitSYzBiQndERGNLM0FFYzNEbWhGMWQrS1lOTGtJWlpGN0ZEUHVF?= =?utf-8?Q?wtsAGNKVEoEttLOux8=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09634B1196 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(136003)(366004)(396003)(199004)(189003)(6246003)(25786009)(7736002)(14454004)(229853002)(44832011)(4326008)(82746002)(8676002)(81156014)(81166006)(966005)(8936002)(256004)(478600001)(36756003)(58126008)(6436002)(6116002)(5660300002)(53936002)(54896002)(6306002)(6512007)(236005)(97736004)(6486002)(2501003)(110136005)(83716004)(71200400001)(2906002)(68736007)(71190400001)(33656002)(476003)(6506007)(486006)(86362001)(2616005)(316002)(102836004)(99286004)(606006)(105586002)(46003)(106356001)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4299; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ied1tMvRnOB2mAEE3kS/oXDPFqizUBXRRAEly2mN+R9BZRyn3hbmGHdThk14uHaSag2SgXInXnHFV0SG1fbQOKlasEo3lXJUX2NlRJ9aN1y56SXt+CZKUdGYiXJQzjZkoPeBlYB3RgXW2r4u3z7W60B0Tte0sVHEZqwcVP5LAIINe6wLUVg2/QCi3s6RZVnlYZUFBTkpOV4BcqZUVnLyxJ1HdgTVvSHbdlWDoY1+YQCjGdCR86MoR9xZbcZKgZMT+mZVbg2c4K7vFGai7vvk4B8Cl076jgUlwk0wdjDy83qTRcsx5xPPIHs4w2QgUz0K317uDXc2FNX+pMtPJWzNj2Umr4gf0A749dyuTsPKM0ccZlXsNkzhlTJavyuy7ZItgTNcdJZ6T8etzdSaXeUhfn//+IrL8ZYCVAo1f5UVC+E= Content-Type: multipart/alternative; boundary="_000_B50E2D380C43407BAA34FA7F02B9CE18ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 48d82324-db36-4916-0aca-08d69e382ede X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2019 11:22:25.9913 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4299 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJKsWRmVeSWpSXmKPExsUyM2J7ke4P0coYg+190hbTdvWyWnz9sYnN 4vfGu8wOzB47Z91l91iy5CeTR1PnYvYA5igum5TUnMyy1CJ9uwSujJ1TbjIX7MuoONYo3sB4 PrWLkZNDQsBEYuKyZWwgtpDAEUaJyzd4uxi5gOyvjBKNj+6ywzk/Og4yQjiLmSS2XFrHCtLC IjCBWWLRUU6IxGQmiV9zrzBDOA8ZJe7d6gJq4eBgE7CQ6P6nDdIgIpAk8efUQkYQm1lAU+LR zr1MILYw0B3P3+5jhagxlWj6dZ8dpFVEQE/i39VqiF0qEjf/rAabyCtgL3FoaTlImFFATOL7 qTVMEBPFJW49mc8E8ZmAxJI955khbFGJl4//gU0XFdCX2NL3gAWiN1Fi/6oHUDWWEi9Or4Ky ZSUuze9mhLB9JfbtuwYVv8ko0b1PEcLWkri0eRJUjZTEiYtHWUE+lxD4LiCx+0cPVCJbYvLM aywgN0sIyEisWFcLET7DKjH1tcAERt1ZSM6GsJMlHv7dyA5i8woISpyc+YRlFlA3KLDW79KH KFGUmNL9kB3C1pBonTMXyvaQmNZ/nxFZzQJGjlWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsY gQnq4JbfqjsYL79xPMQowMGoxMM7kb0yRog1say4MvcQowQHs5IILx8DUIg3JbGyKrUoP76o NCe1+BCjNAeLkjjvHyHBGCGB9MSS1OzU1ILUIpgsEwenVANjVnCp2zuJB7mNE75Gpy0pPdT3 5nAz78w4s07HK7lKE7hPp17gf+Xd58vLZaV8vdc9xKr90+HvNZvnHn9wx1QsTYbhxZ2oS+uu Bne+D3VXuFzVcbjSm0fpo0tS3zK1vCvsj16n2gVlH604bl3StD/7QtXF/igDl3Snd3+EwixF 1mybG7Lp3TwlluKMREMt5qLiRAAWdgPhTAMAAA== Archived-At: Subject: Re: [sipcore] Syntax of Feature-Caps header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 11:22:37 -0000 --_000_B50E2D380C43407BAA34FA7F02B9CE18ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYWxzbyBub3RlZCB0aGF0IGFkZGluZyB0aGUg4oCYK+KAmSBpcyBub3QgZW5vdWdo LiBOb3RlIHRoYXQgdGhlIEZlYXR1cmUtQ2FwcyBoZWFkZXIgZmllbGQgc3ludGF4IGFsc28gbWFu ZGF0ZXMgdGhlIOKAmCrigJkuDQoNClNvLCB0aGUgY29ycmVjdCB3YXkgaXM6DQoNCkZlYXR1cmUt Q2FwczogKjsrc2lwLjYwOA0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IHNpcGNv cmUgPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1i ZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpEYXRlOiBUaHVyc2RheSwgMjgg RmVicnVhcnkgMjAxOSBhdCAxNi41MA0KVG86IFllaG9zaHVhIEdldiA8eW9zaGlnZXZAZ21haWwu Y29tPg0KQ2M6ICJzaXBjb3JlQGlldGYub3JnIiA8c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbc2lwY29yZV0gU3ludGF4IG9mIEZlYXR1cmUtQ2FwcyBoZWFkZXINCg0KSEkgWWVob3No dWEsDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQo+SSBoYXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5n IHRoZSBzeW50YXggb2YgdGhlIEZlYXR1cmUtQ2FwcyBoZWFkZXIgc2luY2UgSSd2ZSBub3QgbWFu YWdlZCB0byBmaW5kIGFueSByZWFsIGV4YW1wbGVzIG9mIGl0cyB1c2FnZS4NCj4NCj5UaGUgQUJO RiBpbiBSRkMgNjgwOSBpcyBkZWZpbmVkIGFzOg0KPiAgIEZlYXR1cmUtQ2FwcyA9ICJGZWF0dXJl LUNhcHMiIEhDT0xPTiBmYy12YWx1ZQ0KPiAgICAgICAgICAgICAgICAgICAqKENPTU1BIGZjLXZh bHVlKQ0KPiAgIGZjLXZhbHVlICAgICA9ICIqIiAqKFNFTUkgZmVhdHVyZS1jYXApDQo+ICAgZmVh dHVyZS1jYXAgICAgICAgPSAgIisiIGZjYXAtbmFtZSBbRVFVQUwgTERRVU9UIChmY2FwLXZhbHVl LWxpc3QNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgLyBmY2FwLXN0cmluZy12YWx1ZSAp IFJEUVVPVF0NCj4NCj4gRm9sbG93aW5nIHRoaXMgc3ludGF4LCBJIGd1ZXNzIHRoYXQgZm9yIHNp cC1wdXNoIHRoZSBoZWFkZXIgd2lsbCBsb29rIGxpa2U6DQo+ICAgRmVhdHVyZS1DYXBzOiAqOytz aXAucG5zPSJ3ZWJwdXNoIg0KPg0KPg0KPk9uZSBleGFtcGxlIEkgY291bGQgZmluZCBpcyBvbiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zaXBjb3JlLXJlamVjdGVkLTAz Og0KPiAgIEZlYXR1cmUtQ2Fwczogc2lwLjYwOA0KPldpdGhvdXQgdGhlIGFzdGVyaXNrIGFuZCB0 aGUgcGx1cyBzaWduLg0KPg0KPiBXaGljaCBvbmUgaXMgY29ycmVjdD8NCg0KVGhlIHNpcC5wbnMg ZXhhbXBsZSBpcyBjb3JyZWN0LiBUaGUgc2lwLjYwOCBleGFtcGxlIG5lZWRzIHRvIGJlIGNvcnJl Y3RlZC4NCg0KKEkgVEhJTksgSSBoYWQgcHJldmlvdXNseSBjb21tZW50ZWQgb24gdGhpcyB3aGVu IHJlYWRpbmcgc2lwY29yZS1yZWplY3RlZCwgYnV0IEkgbWF5IGJlIHdyb25n4oCmKQ0KDQo+RHVl IHRvIHRoZSBsYWNrIG9mIGV4YW1wbGVzLCB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBhZGQgYW4g ZXhhbXBsZSB0byB0aGUgc2lwLXB1c2ggZHJhZnQgdGhhdCBpbmNsdWRlcyBmZWF0dXJlIGNhcGFi aWxpdGllcw0KPmFuZCBtZWRpYSB0YWdzIChlc3BlY2lhbGx5IHRoYXQgc2lwLnBuc3JlZyBpcyB1 c2VkIGZvciBib3RoKT8NCg0KSSB3aWxsIGxvb2sgaW50byBpdC4gSSBndWVzcyB0aGF0IGNvdWxk IGJlIGRvbmUgd2hlbiBhZGRyZXNzaW5nIEJlbuKAmXMgY29tbWVudHMuDQoNClJlZ2FyZHMsDQoN CkNocmlzdGVyDQoNCg== --_000_B50E2D380C43407BAA34FA7F02B9CE18ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <07ECD07538B4B24BA8F9DDDB8704EC98@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25v cm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRkkiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+SSBhbHNvIG5vdGVkIHRoYXQgYWRkaW5nIHRoZSDigJgmIzQzO+KA mSBpcyBub3QgZW5vdWdoLiBOb3RlIHRoYXQgdGhlIEZlYXR1cmUtQ2FwcyBoZWFkZXIgZmllbGQg c3ludGF4IGFsc28gbWFuZGF0ZXMgdGhlIOKAmCrigJkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Tbywg dGhlIGNvcnJlY3Qgd2F5IGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RmVhdHVyZS1DYXBzOiAqOyYj NDM7c2lwLjYwODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+c2lwY29yZSAmbHQ7c2lw Y29yZS1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmcg Jmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ VGh1cnNkYXksIDI4IEZlYnJ1YXJ5IDIwMTkgYXQgMTYuNTA8YnI+DQo8Yj5UbzogPC9iPlllaG9z aHVhIEdldiAmbHQ7eW9zaGlnZXZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7 c2lwY29yZUBpZXRmLm9yZyZxdW90OyAmbHQ7c2lwY29yZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+UmU6IFtzaXBjb3JlXSBTeW50YXggb2YgRmVhdHVyZS1DYXBzIGhlYWRlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ISSBZ ZWhvc2h1YSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIHNlZSBpbmxpbmUuPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0O0kgaGF2ZSBh IHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGUgc3ludGF4IG9mIHRoZSBGZWF0dXJlLUNhcHMgaGVhZGVy IHNpbmNlIEkndmUgbm90IG1hbmFnZWQgdG8gZmluZCBhbnkgcmVhbCBleGFtcGxlcyBvZiBpdHMg dXNhZ2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jmd0O1RoZSBBQk5GIGluIFJGQyZuYnNwOzY4MDkgaXMgZGVmaW5lZCBhczo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mZ3Q7Jm5ic3A7ICZuYnNwO0ZlYXR1cmUtQ2FwcyA9ICZxdW90O0ZlYXR1cmUtQ2FwcyZx dW90OyBIQ09MT04gZmMtdmFsdWU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KihDT01NQSBmYy12YWx1 ZSk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO2ZjLXZhbHVlICZuYnNwOyAmbmJzcDsgPSAmcXVvdDsq JnF1b3Q7ICooU0VNSSBmZWF0dXJlLWNhcCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsmbmJzcDsgJm5ic3A7 ZmVhdHVyZS1jYXAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs9Jm5ic3A7ICZxdW90OyYjNDM7 JnF1b3Q7IGZjYXAtbmFtZSBbRVFVQUwgTERRVU9UIChmY2FwLXZhbHVlLWxpc3Q8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg LyBmY2FwLXN0cmluZy12YWx1ZSApIFJEUVVPVF08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgRm9sbG93aW5nIHRoaXMgc3ludGF4LCBJIGd1ZXNzIHRo YXQgZm9yIHNpcC1wdXNoIHRoZSBoZWFkZXIgd2lsbCBsb29rIGxpa2U6PGJyPg0KPGI+Jmd0OyZu YnNwOyAmbmJzcDtGZWF0dXJlLUNhcHM6ICo7JiM0MztzaXAucG5zPSZxdW90O3dlYnB1c2gmcXVv dDs8L2I+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7T25lIGV4YW1wbGUgSSBjb3VsZCBmaW5kIGlzIG9uJm5i c3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXNpcGNvcmUtcmVqZWN0ZWQtMDMiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zaXBjb3JlLXJlamVjdGVkLTAzPC9zcGFuPjwvYT48c3Bh biBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Jm5ic3A7ICZuYnNw O0ZlYXR1cmUtQ2Fwczogc2lwLjYwODwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0O1dpdGhv dXQgdGhlIGFzdGVyaXNrIGFuZCB0aGUgcGx1cyBzaWduLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m Z3Q7Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgV2hpY2ggb25lIGlzIGNvcnJlY3Q/ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgc2lwLnBucyBleGFt cGxlIGlzIGNvcnJlY3QuIFRoZSBzaXAuNjA4IGV4YW1wbGUgbmVlZHMgdG8gYmUgY29ycmVjdGVk Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4oSSBUSElOSyBJIGhhZCBwcmV2aW91c2x5IGNvbW1lbnRl ZCBvbiB0aGlzIHdoZW4gcmVhZGluZyBzaXBjb3JlLXJlamVjdGVkLCBidXQgSSBtYXkgYmUgd3Jv bmfigKYpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7RHVlIHRvIHRoZSBs YWNrIG9mIGV4YW1wbGVzLCB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBhZGQgYW4gZXhhbXBsZSB0 byB0aGUgc2lwLXB1c2ggZHJhZnQgdGhhdCBpbmNsdWRlcyBmZWF0dXJlIGNhcGFiaWxpdGllcw0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZndDthbmQgbWVkaWEgdGFncyAoZXNwZWNpYWxseSB0aGF0IHNpcC5wbnNyZWcgaXMg dXNlZCBmb3IgYm90aCk/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHdpbGwg bG9vayBpbnRvIGl0LiBJIGd1ZXNzIHRoYXQgY291bGQgYmUgZG9uZSB3aGVuIGFkZHJlc3Npbmcg QmVu4oCZcyBjb21tZW50cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_B50E2D380C43407BAA34FA7F02B9CE18ericssoncom_-- From nobody Fri Mar 1 09:15:15 2019 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 64F16130E27; Fri, 1 Mar 2019 09:15:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-sipcore-sip-push@ietf.org, Brian Rosen , sipcore-chairs@ietf.org, br@brianrosen.net, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155146051337.6186.9467252084775433080.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 09:15:13 -0800 Archived-At: Subject: [sipcore] Adam Roach's No Objection on draft-ietf-sipcore-sip-push-26: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 17:15:13 -0000 Adam Roach has entered the following ballot position for draft-ietf-sipcore-sip-push-26: 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-sip-push/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss points. Although I find the solution for SUBSCRIBE dialogs particularly unsatisifying, I'm not going to get in the way of working group consensus here. The original discuss points (and original comments) are detailed below. --------------------------------------------------------------------------- Thanks to everyone who is put work into defining this mechanism. I think it will be very useful to have a solution for integrating push mechanisms into SIP networks. I've identified three issues that I think need to be addressed in the current document before it can move forward, and a fourth serious flaw that I call out in my comments below. --------------------------------------------------------------------------- It's nice that this document has considered the impact of inbound mid-dialog messages in long-lived dialogs. However, it appears to have a major hole in it: handing of outbound messages for the purpose of maintaining soft-state in those dialogs isn't handled correctly. In particular: networks that deploy this mechanism will cause SUBSCRIBE dialogs to time out and be destroyed while they are still in use. Additionally, if RFC 4028 (session timers) is negotiated, then INVITE dialogs will suffer the same fate. I can think of a couple of ways for these situations to be handled, but they need explicit text in the document. One approach would be to specify that the User Agent selects its requested "Expires" value in its registration to be the smallest value before its set of subscriptions and session timers needs to be refreshed. This would cause a push notification to happen to prevent registration timeout, and the client could refresh the other soft state at that time. Complications arise if the registrar responds with a 483 (Interval too Brief), and we'd need to find a solution for that. Another approach would be for the clients to refresh all soft state whenever they send a registration, and set the timeout for that soft state to be equal to or greater than the registration timeout. A complication could arise if the notifier or the peer in an invite dialog shortens the requested time, and we'd need to find a solution for that. A third approach would be getting the proxy involved in some way -- either by requiring it to observe subscription and session timer timeouts and requiring it to send push notifications prior to their expiration, or by an explicit communication between the UA and the proxy that indicates when the next push notification should be scheduled. If the latter approach is taken, I would suggest that it needs to be taken for REGISTER messages as well. I really don't think this mechanism is feasibly deployable without a solution to this problem. --------------------------------------------------------------------------- §4.1: > For privacy and security reasons, the UA MUST NOT include the SIP URI > parameters defined in this document in non-REGISTER request, to > prevent the PNS information associated with the UA from reaching the > remote peer. This seems to ignore the availability of Contact URI parameters via RFC 3680 subscriptions. This would seem to impose a requirement on Registrars to strip this information before making it available to any other party (which, in turn, requires that the system have explicit Registrar *and* Proxy support). As far as I can tell, the system so far has not required explicit proxy support (and there's certainly no mechanism built-in that ensures that a proxy has any special handling regarding this mechanism). If the PNS information is sensitive, and cannot be allowed to leak out to other users, then we need some way to ensure the registrar has provided positive confirmation that it will not do so before allowing it to come into possession of them. --------------------------------------------------------------------------- §4.2: > The UA can do so by only including the pn-provider > SIP URI parameter in the SIP Contact header field URI of the REGISTER > request, but without including the pn-prid SIP URI parameter. Unless I'm mistaken, this is a barrier to interoperation. It's not 100% clear, but I suspect the intended implication is that the pn-provider parameter here will contain a single value? The syntax of the parameter certainly seems to imply that. This seems to be a pretty big problem, since it presupposes that the client will know which PNSes the Proxy supports. Consider, for example, an iOS client that can use any of RFC 8030, FCM, and APN (cf https://firebase.google.com/docs/cloud-messaging/ios/client). If the client doesn't know a priori what the proxy supports (and this entire section only makes sense if that's true), then it won't know which of those three services to indicate in its REGISTER request. If it guesses wrong, this mechanism simply fails. I think you need a different discovery mechanism here -- either have one that has the client offering multiple PNS protocols and the proxy responding with one, or have one in which the proxy indicates all of its supported services in a response, and the client chooses one to use in its next REGISTER message. --------------------------------------------------------------------------- Figure 1: This diagram includes both a ladder diagram and an example REGISTER message. While both of these are useful at this point in the document, neither of them is an "Architecture," and they're really two different things. I suggest breaking this into two Figures, entitled "Typical Information Flow" and "Example REGISTER Message" (or similar), respectively. --------------------------------------------------------------------------- §4.1: > As long as the UA wants to receive push notifications (requested by > the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param > (if required for the specific PNS provider) SIP URI parameter in each > binding-refresh REGISTER request. Please be clear that these parameters appear in the Contact URI. --------------------------------------------------------------------------- §5.2: > In order to request push notifications towards a SIP UA that will > trigger the UA to send binding-refresh SIP REGISTER requests, the SIP > proxy needs to have information about when a registration will > expire. The proxy needs to be able to retrieve the information from > the registrar using some mechanism. Such mechanisms are outside the > scope of this document, but could be implemented e.g., using the > SIPregistration event package mechanism [RFC3680]. Nit: "SIP registration" This mechanism seems to be predicated on an architecture in which the proxy must be on the traffic path. Although it's problematic from a "what proxies are expected to do" perspective, it seems like the proxy could glean this information from the 200 response to the REGISTER request. (I mean, the proxy is already reading parameters out of the contact header field, so the behavior of acting on registration information is already assumed). The proxy would, of course, need to run its own timers, but that seems to be a pretty minor requirement, given everything else involved here. --------------------------------------------------------------------------- §5.3.1: This is a major comment, and one that has a sufficient impact on interop that I had a long debate with myself about whether it should be a DISCUSS. Please take it very seriously. > Otherwise, if the pn-provider SIP URI parameter identifies a type of > PNS that the proxy does not support, or if the REGISTER request does > not contain all additional information required for the specific type > of PNS, the proxy MUST either forward the request (e.g., if the proxy > knows that another proxy that will receive the REGISTER request > supports the type of PNS)... How would the proxy know this? Features like suppressing PNS behavior when a "sip.pns" feature capability is present in the REGISTER imply that the various nodes in the network discover capabilities of their neighbors automatically (which is consistent with the way SIP does features), while this provision seems to require provisioned knowledge. This is going to be operationally very confusing. At the very least, the document needs to call out how this "knowledge" is obtained. In the more general sense, since a client cannot rely on the proxy supporting *any* kind of PNS, the use of 555 in the way specified here is at best an optimization -- and, since the configured information can conflict with actual reality, it's an optimization that can actually break things unless extreme care is exercised. (e.g., if the proxy is configured to "know" that the next proxy cannot provide push service, but this knowledge is wrong, then the network is unnecessarily broken.) My rather strong recommendation is to remove this code, and let the client rely on the lack of indication of support in the response indicate that the feature is not supported. --------------------------------------------------------------------------- §5.3.1: > o if the proxy received a 'sip.pnsreg' media feature tag in the > REGISTER request, the proxy SHOULD include a 'sip.pnsreg' feature- > capability indicator with an indicator value bigger than 120 in > the response, unless the proxy always want to request push Nit: "...wants..." --------------------------------------------------------------------------- §5.3.2: > If the contact of the REGISTER request does not match > the Request-URI of the SIP request to be forwarded, or if the contact > was not present in the REGISTER response, the proxy MUST reject the > SIP request with a 404 (Not Found) response. This seems to be a very strong requirement ("MUST") when, e.g., many or most networks may want to return a 480 instead of a 404. I think what you want to say is something like "...MUST reject the SIP request. Response codes of either 404 (Not Found) or 480 (Temporarily Unavailable) are RECOMMENDED, but other appropriate codes may be used as well." --------------------------------------------------------------------------- §5.3.2: > The reason the proxy needs to wait for the REGISTER response before > forwarding the SIP request is to make sure that the REGISTER request > has been accepted by the registrar, and that the UA which initiated Nit: "...the UA that initiated..." --------------------------------------------------------------------------- §5.3.2: > In case of non-2xx response to the REGISTER request, the proxy MUST > reject the SIP request with a 404 (Not Found) response. > > If the push notification request fails (see PNS-specific > documentation for details), the proxy MUST reject the SIP request > with a 480 (Temporarily Unavailable) response. > > If the proxy does not receive the REGISTER request from the UA within > a given time after the proxy has requested the push notification, the > proxy MUST reject the request with a 480 (Temporarily Unavailable) > response. The time value is set based on local policy. As above, this seems way too restrictive in terms of mandating specific error codes. It may well be the case that a network would want to treat these situations identically from the perspective of the calling party. --------------------------------------------------------------------------- §5.3.2: > Otherwise the > proxy MUST reject the SIP request with a 480 (Temporarily > Unavailable) response. Same comment as above. --------------------------------------------------------------------------- §6.1.1: > When the UA sends in initial request for a dialog, or a 2xx response Nit: "...sends an initial request..." > purr' SIP URI parameter in the Contact header of the request or Nit: "...Contact header field..." > NOTE: As the 'pn-purr' SIP URI parameter only applies to a give > dialog, the UA needs to include a 'pn-purr' parameter in the Contact Nit: "...given dialog..." > dialog, the UA needs to include a 'pn-purr' parameter in the Contact > header of the request or response for each dialog in which the UA is Nit: "...Contact header field..." --------------------------------------------------------------------------- §6.1.1: > The UA MUST include a parameter value identical to the the > last 'sip.pnspurr' feature-capability indicator that it received in a > REGISTER response. This is incredibly confusing, as the "sip.pnspurr" indicator has not been mentioned in the document so far. Please revise as something along the lines of: > The UA MUST include a parameter value identical to the the last > 'sip.pnspurr' feature-capability indicator (see Section 6.2.1) that it > received in a REGISTER response. Alternately, reverse the order of sections 6.1 and 6.2 so that the PURR concept is properly introduced before protocol procedures are defined for it. --------------------------------------------------------------------------- §6.1.1: > NOTE: As the 'pn-purr' SIP URI parameter only applies to a give > dialog, the UA needs to include a 'pn-purr' parameter in the Contact > header of the request or response for each dialog in which the UA is > willing to receive push notifications triggered by incoming mid- > dialog requests. Similar to the above, this is a very confusing introduction of the "pn-purr" URI parameter. --------------------------------------------------------------------------- §6.2.2: > Contact header field with a PURR value that the proxy has generated > Section 6.2.2, the proxy MUST add a Record-Route header to the > request, to insert itself in the dialog route [RFC3261]. This "Section 6.2.2" makes the sentence impossible to read. Is it intended to be in parentheses? --------------------------------------------------------------------------- §6.2.3: > As described in Section 5.3.2, while waiting for the push > notification request to succeed, and the associated REGISTER request > to arrive from the SIP UA, the proxy needs to take into consideration > that the transaction associated with the NOTIFY request will > eventually time out at the sender of the request (UAC), and the > sender will consider the transaction a failure. I think this needs some discussion about the impact of the error codes selected by the proxy on the dialog and its usages. For example: * If the proxy sends a 404 to prevent a transaction timeout, it will destroy the dialog and all of its usages * If the proxy sends a 480 to prevent a transaction timeout, it will destroy the usage, but not other usages in the dialog (if any) * If the proxy sends a 504 to prevent a transaction timeout, it will keep the dialog and the usage alive, and allow the client to re-try at a later time. Simply allowing the transaction to time out will have the same effect, albeit with more message retransmissions. Pointing to RFC 5057 might be useful here. --------------------------------------------------------------------------- §8.7: > Parameter value characters that are not part of pvalue needs to be > escaped, as defined in RFC 3261. Nit: "...need to be escaped..." --------------------------------------------------------------------------- §9: > When a new value is registered to the PNS Sub-registry, a reference > to a specification which describes the usage of the PNS associated Nit: "...specification that describes..." --------------------------------------------------------------------------- §§10-12: Nit: It seems like these should all be subsections of section 9. --------------------------------------------------------------------------- §10: > The Topic consists of the Bundle ID, which uniquelly identifies an > appliciation, and a service value that identifies a service Nit: "uniquely" Nit: "application" --------------------------------------------------------------------------- §10: > Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp.voip Please use an RFC 2026 domain for this example; e.g.: > Example: pn-param = DEF123GHIJ.com.example.yourexampleapp.voip --------------------------------------------------------------------------- §11: > [RFC8292] defines a mechanism which allows a proxy to identity itself Nit: "...mechanism that allows..." From nobody Fri Mar 1 12:49:00 2019 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 EF1AA130EBE; Fri, 1 Mar 2019 12:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 lmb9QAFYSpEp; Fri, 1 Mar 2019 12:48:57 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56DFE1200B3; Fri, 1 Mar 2019 12:48:57 -0800 (PST) Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x21KmokE005608 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 1 Mar 2019 14:48:51 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551473332; bh=A5B5CMv5WgpWBhZ1x4mFrif/5VX3dXU4JCX4Aka/tvM=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=FWwtKEaPGtq2cBwMAyIBfd+jtAJYA2BkMt7X8wLeN3cn64FAfaQkc+doeaSEXnPsw VQDXAkoVzJ3NHP7aH7IabMHEsYyh+ZRVsziuTWCaZfBdPsJb/t4Z/hteh0cEi17V0A c0Uw2MF6t+UDnTFZJ5nCnI9tMfuhC/TXcSB76+Lc= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29] From: Ben Campbell Message-Id: <1F7703E8-9132-4D49-A7D8-B09143B175B9@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_74B0DADE-7D44-4E53-923B-6D50326928FB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 1 Mar 2019 14:48:46 -0600 In-Reply-To: <010FF140-EFC4-4833-A526-826D69A49DB5@ericsson.com> Cc: "sipcore@ietf.org" , "sipcore-chairs@ietf.org" To: Christer Holmberg References: <8F397308-9ED7-4CB7-B1F6-DC1A78018672@nostrum.com> <9673FB23-BB4C-4C6F-8E48-90650A5D0409@ericsson.com> <010FF140-EFC4-4833-A526-826D69A49DB5@ericsson.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [sipcore] Draft new version: SIP Push -26 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 20:48:59 -0000 --Apple-Mail=_74B0DADE-7D44-4E53-923B-6D50326928FB Content-Type: multipart/alternative; boundary="Apple-Mail=_C292264E-1790-49FB-A7DD-B4642829C49A" --Apple-Mail=_C292264E-1790-49FB-A7DD-B4642829C49A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 1, 2019, at 4:36 AM, Christer Holmberg = wrote: >=20 >>>>=20 >>>> - "request that >>>> a push notification is sent=E2=80=9D >>>>=20 >>>> s/is/be (note that this pattern occurs many times in the draft.) >>>=20 >>> As I indicated to Jean, the wording is the outcome of the previous = discussions associated with Ekr's IESG review. >>=20 >> I=E2=80=99d be highly surprised if ekr objected to =E2=80=9Cbe=E2=80=9D= . it is more grammatically correct than =E2=80=9Cis=E2=80=9D. The = subjunctive =E2=80=9Cbe" form is indicated by the fact that we talk = about a request for something to happen, not a statement that something = is true. >>=20 >> I=E2=80=99m not going to block things over it, but I would bet a beer = that the RFC editor changes it. :-) >=20 > So, you want to say "request that a push notification be sent"? >=20 > If that's more grammatically correct I will fix as suggested. Yes, that was what I had in mind. Thanks! Ben. --Apple-Mail=_C292264E-1790-49FB-A7DD-B4642829C49A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 1, 2019, at 4:36 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:


 - "request = that
 a push notification is sent=E2=80=9D

 s/is/be  (note that this pattern = occurs many times in the draft.)

As I indicated to Jean, the wording is the outcome of the = previous discussions associated with Ekr's IESG review.

I=E2=80=99d be highly surprised = if ekr objected to =E2=80=9Cbe=E2=80=9D.  it is more grammatically = correct than =E2=80=9Cis=E2=80=9D. The subjunctive =E2=80=9Cbe" form is = indicated by the fact that we talk about a request for something to = happen, not a statement that something is true.

I=E2=80=99m not going to block things over it, but I would = bet a beer that the RFC editor changes it. :-)

   So, you want to say "request that a push = notification be sent"?

   If that's more grammatically correct I will = fix as suggested.


Yes, that was what I had = in mind.

Thanks!

Ben.

= --Apple-Mail=_C292264E-1790-49FB-A7DD-B4642829C49A-- --Apple-Mail=_74B0DADE-7D44-4E53-923B-6D50326928FB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlx5mq8ACgkQgFZKbJXz 1A0pbRAAv8im7hzXFFd2d9CvfAf60L0wutTK5dOMkbqi9MMzG5ZVQ7SMGMAdYlIR tURbQoDDDoQYQs3GsvxnUnFiATv2Fd4I8KJlBLaUd7u0JKxkUlEkiB5KxXS2ahyr 5zBwV+opxqglUQtGt84QD84fu6C+EpJLDITuznVbPE4xLeT4lEwCYBpEGrn38bED 37N5te1OdKYQvaByB7SFCCQfx8IMw+9DpYkvPgcKdVzWAWbboJDa9+kiJLWCm/vr 1e77HKpdZgqkgthUco2jEnO6eoxPvh27giX6omOltyeICA4eYqWXUnWqQWP5wX/m HhGDGRg701GVTSd+tHjovzDxM2/+1UKcKE02Gilyn8yk8xYGkGayC8xYWr7tLDVo FR/29lkC8UaghAQ4mXhZJqXmkRxruTUnpox7AyoxEmeHvG9QRkmp4ZSHW76PDTfB IIMiS5/twEBx96lbLZBi7zs7lFJnX2AQx5KQwxyLUYD74TDUC/0Yn+nuS/uBpLtI bqRwx4nQAVy/RWKUCLNxprvkDmlLO0GgdUN/tniPgyM/l3xjVGCuoqNRWTFKLz74 3taC9Xw9vlwnyvkRguC5Y72uNn1yblCxgFo+skv/mJLfZFq/SMRdrXGLs2jMuutO cAURAxg3BTXnhsv1eT+JnOAfnZCyDp46JfcT/MdJ6pOwBJnI074= =pD1O -----END PGP SIGNATURE----- --Apple-Mail=_74B0DADE-7D44-4E53-923B-6D50326928FB-- From nobody Fri Mar 1 13:32:05 2019 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 A4C02130FC1 for ; Fri, 1 Mar 2019 13:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.291 X-Spam-Level: X-Spam-Status: No, score=-4.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Pr8qKpOQ; dkim=pass (1024-bit key) header.d=ericsson.com header.b=gqSVKMOc 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 IUKb4Kj8I7fG for ; Fri, 1 Mar 2019 13:31:49 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF004130F47 for ; Fri, 1 Mar 2019 13:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551475904; x=1554067904; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9CwPUbggsAsB44yaojtCbMWIOat9r/K8eW/6OdoxbVc=; b=Pr8qKpOQmco/HPlyKiNZ+k/MsbRGaY86/KiYUm7xErnweWNxenLm6XjjpQr0jv3X TQ+XPh2zXEJXNYrQTt0ddiorovx4u8YV6XoarACqaKqARUN2x4ytzsO+HhKNIxLJ VyI7ndC0FG/oycMN3f1xgkfj1NeHTT+Mc2UNz1jsXgM=; X-AuditID: c1b4fb30-41b3a9e00000355c-57-5c79a4c08e6d Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6C.9E.13660.0C4A97C5; Fri, 1 Mar 2019 22:31:44 +0100 (CET) Received: from ESESBMR502.ericsson.se (153.88.183.134) by ESESSMB505.ericsson.se (153.88.183.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Mar 2019 22:31:42 +0100 Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMR502.ericsson.se (153.88.183.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Mar 2019 22:31:42 +0100 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 1 Mar 2019 22:31:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9CwPUbggsAsB44yaojtCbMWIOat9r/K8eW/6OdoxbVc=; b=gqSVKMOc9qhG8z2QLS+n1RwEOl4vuT9BlUtmX4Fc76WChX2RRlMHZAVtZ776b/bC2U+YrBUT1753z+GoXLPbg3Ol+Z/YdvTrXeOB/moRGc91QXmc3uTqO2fiJUWmsnnOWDTQX9FzV75z8rFLQkY4vsjHHTD/l2moCBRFbwnfaTg= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3449.eurprd07.prod.outlook.com (10.170.247.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.13; Fri, 1 Mar 2019 21:31:40 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae%3]) with mapi id 15.20.1686.011; Fri, 1 Mar 2019 21:31:40 +0000 From: Christer Holmberg To: Adam Roach , The IESG CC: "draft-ietf-sipcore-sip-push@ietf.org" , Brian Rosen , "sipcore-chairs@ietf.org" , Brian Rosen , "sipcore@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-sipcore-sip-push-26: (with COMMENT) Thread-Index: AQHU0FJlSNJTji9dnkaJCVYOkLIdYKX3Ink4 Date: Fri, 1 Mar 2019 21:31:40 +0000 Message-ID: References: <155146051337.6186.9467252084775433080.idtracker@ietfa.amsl.com> In-Reply-To: <155146051337.6186.9467252084775433080.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.136.1.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 429e3f46-06c2-44bc-c84d-08d69e8d4abf x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3449; x-ms-traffictypediagnostic: HE1PR07MB3449: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?iso-8859-1?Q?1; HE1PR07MB3449; 23:1OuelnHnN1amCa6pd2ylxCaZZBOGvJribxakLyY?= =?iso-8859-1?Q?0fRzEGftFX8A5QMdWvNu/qLB12GGnuGX6aVVEu978NUzOVYdRGXyEv44Kz?= =?iso-8859-1?Q?gPEZI2V+cRBBUZEPehQA4jFA/qa31j2WQCWx6cvZzk3+p1jsxMepVuJIYf?= =?iso-8859-1?Q?iXlHVLK1+yTdOR0v5emUgrctfJLICSBygIz2VDlpYrgDZM4UNnAxawI9YJ?= =?iso-8859-1?Q?AAfwx4+l4GBCAM70axt9PYGbe6dz94TrW0/LMPKF2hgC9jtQ2doffCUy2z?= =?iso-8859-1?Q?M6HyWvx14g5fWFNajDcaDE+Kk3DCOzqcfHsD/JHPuQN22G825uXWMQL5/b?= =?iso-8859-1?Q?0lt28GVBNbskY5S1asna4XpocNeEKh2RjvBWSJxsVpkqSU8US7735+CUKb?= =?iso-8859-1?Q?Ge41VA9AbjOkK/0AL3UyGgpQX6o8cAafpO4DC+TRZrVktywoz0KH/Mw0Tc?= =?iso-8859-1?Q?blljju8lowrzdjExn4aD8TZTavRG3woyLwi8MqiX0JFugVOQXU2atZ3vpI?= =?iso-8859-1?Q?hbW3p1cN9TQVyEpG7wLAqXUViifEnCG45+w5taK1E0NCKrwQYJksEAsZEc?= =?iso-8859-1?Q?GCEqV2XZqrTalVfqEWFEn+C0THYjb7eLBx2oZMXQupFS0E+aeVgqEFa1CE?= =?iso-8859-1?Q?PI03J/NTFFGhE3OSG3rGBYPj0PekgnxicX7uEkBlRy47l1bufYpbYabNwx?= =?iso-8859-1?Q?LpD78jjFuGg9B+ZJzyZRa8xMJKBShYdf47jYYkMegyqD/3oWHwC96wsHnA?= =?iso-8859-1?Q?K8ZSoL9ICjBcGNfk0dBws1na5M1tejXquCpbym/0XeHP2m8hVMQ6xMAc3A?= =?iso-8859-1?Q?rTuqlc+35j9eCTivBKCLILQOSegc8qwmwv8gAIIn1JWOKaPS0IPMA2mmNl?= =?iso-8859-1?Q?9np+9btZRtpWtWhYrLfBfHE83TD1PdqM3Qf1c/v4+6CAywhKgA6keOdrSN?= =?iso-8859-1?Q?uYQI++Ejd7ooGPMk88EADY7avZIjY+hUBa+PQBGIGuNomGZWLcBqnUVNhE?= =?iso-8859-1?Q?Ibld1BJBxlnjBcjl+uvh3hSDHYFwSOMcDQUEZWX3gLVq5Zi7hK4+shJwRc?= =?iso-8859-1?Q?5liE75FcjgbhSRV/Vk3QsLgsblptDOPwR1+DwYxuuR11ne5kP9gbGMxGqO?= =?iso-8859-1?Q?ERAiR8G/yjDJDh3krrYrlKsRHlx+17TiFFFOXS/WwGt9hrCi00LMFNduRy?= =?iso-8859-1?Q?MBPESF1DupMuc8Xy8safqgUYvBgNGTwPJiJzfyECmvHJMxDXKhSGlUnWOe?= =?iso-8859-1?Q?YbBc1S38gOFfRhNO2IXNsEFgA5IyqQ08/TDYXy8OUTqJh1yNDqyK9Rmj9q?= =?iso-8859-1?Q?jvMV1sef2W/D7uKuKLildjnoK3BtyxZl2fUijr0AeH21/4hOyJxHXxiAUs?= =?iso-8859-1?Q?8NdJ11ZqHKQruo9icpOoLWslQ2G/56a0K/UzolllHGK/R+T6/hamaZejqv?= =?iso-8859-1?Q?stfsvFkVGc5R8cxvlEYIOUetpPWkI7QtflDYnE26Np3NRFwCnMW956/qlp?= =?iso-8859-1?Q?PzF7+RQxcjSp+5swoWzwhT5UB1t8rN0SWULUqpJHm?= x-microsoft-antispam-prvs: x-forefront-prvs: 09634B1196 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(136003)(346002)(39860400002)(376002)(50854003)(199004)(189003)(256004)(14444005)(4326008)(25786009)(316002)(229853002)(110136005)(53936002)(11346002)(476003)(54906003)(53946003)(44832011)(86362001)(54896002)(6306002)(9686003)(236005)(19627405001)(6436002)(76176011)(26005)(7696005)(106356001)(1015004)(186003)(6506007)(446003)(486006)(71190400001)(71200400001)(52536013)(6116002)(55016002)(6246003)(97736004)(105586002)(6346003)(3846002)(102836004)(74316002)(606006)(478600001)(81156014)(68736007)(8936002)(6606003)(33656002)(66066001)(99286004)(81166006)(8676002)(2906002)(7736002)(14454004)(966005)(5660300002)(30864003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3449; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: NGDVEIL8u/Kw81bT41vQrog4rXCRcwD6rlUUo/nV+Q4S4HFroQgH67NXQBEJfjlurksov8jdpSQCw3KU8k7sWajBQ61bvLSmSed2UHmDcoKulSsMbcJQxKsHiI9JL902wxq0Xgo92L0MECw8ZYsiSHkEd5eNv71118fxc0LHRgugre73tQsMqpaVmjpZYEr3AYMMWo7HEie1PM0CNL0jeQs60jhKcL7BmEKxonlGM7DiuZy8cYA8Z5pysUZT5aYmceECLBWgchD9qEL595ssRbbDNJ/DgoRLKabxBLsroRpXjn2IxlkLntPZORL9H8e3ojfmrXQ5svIQwlPvTdrNvOlB5Ddggl7/ko/FeYCkRrCRg16TZEdJ6hueBOf2PmvNyzeiaww/7Ne8hMOKfFBE3DDvWLH1FDjX5FK9BiLg4XA= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB31616FC1F5E8B496C5C14A9F93760HE1PR07MB3161eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 429e3f46-06c2-44bc-c84d-08d69e8d4abf X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2019 21:31:40.0223 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3449 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH+917d3cdrn4uzYMVyQqDJNNhNioiK8VaL1BDllQrLzqcUzcT H0mikaGIkzQfFStbz1VqD9KwnGNqPiiMRFNRRCvEEGGYpW7m3bXwv8/5fs85v/OFH0NKbAIf Rq1NY3ValUZKi6iqmDfZ2y2mzNjA/tEgeZOjRij/NnKDlufZzYS8cqGUlBfb75Lymd8v6P10 xMgvhzDCZPpDRFQ3jlMnSaVobxyrUaezuh37zokSyuqnBSlTFjKjrrmRykUVs0QhcmMAB8Pt tga6EIkYCbYhqGlvE/LFDIIhq5n6Xwzfall27hFQU+8kuYLCBhJ6C8zLC64TUGIvJfhiFEGX oW/JYRgay6HI6c+96In3QFd+h2ua5PZesbQLOGMtVkLlwnch33QappzFAp5lYHvbR3B7KLwF pmwxnCzGsXCz+D7JsQQfBeNiLcWxGz4GJnOLaxThdTDb+dSVlMTeMDBuXE6NwdT0ieTZCybG nAKeN0FZ7ReK543w2ViEeD4GP+oWXfEBf0VQ0d1J88Y2+FnXsNzkAx96WgV809waWBwaFHJH A06E6fnDPG6AR89z+PZGGpoNCgMKqF5xHs/JYHhpIKtdMT2go2qc4vUA6C8vo3n2hwd3J0me t0Ol00qt1O8g4RPkpWf155PiZbIAVqe+oNcnawO0bNoLtPS3Wl7NBzagiR+hVoQZJHUXh1dk xkoEqnR9ZpIVAUNKPcWXkpYkcZwqM4vVJZ/VXdSweitaz1BSb/GCxCNWguNVaWwiy6awun8u wbj55CLhicEWzWxd+JHjZ555Kf2yV+UZq3zfWya9Pw7sLr9GHDQqFKuD46O0pjvjkW93VUXa o3oVSo1ozZnoyZwZZ+LD+TDVfYujNSqU2pyrcPSYZYKs+pCSfOWhdLH/zgOXt0afShxWO2Y0 Y69TfVMKUjNeBb8L2zXoF+J71f3xXHf9kJTSJ6iCtpE6veovARhMplcDAAA= Archived-At: Subject: Re: [sipcore] Adam Roach's No Objection on draft-ietf-sipcore-sip-push-26: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:32:04 -0000 --_000_HE1PR07MB31616FC1F5E8B496C5C14A9F93760HE1PR07MB3161eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Adam, Thank You! Your issues have been addressed. In this reply I more or less copy/paste wh= at I said in my previous reply to your review, and give some extra details = on how issues were solved. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >It's nice that this document has considered the impact of inbound mid-dial= og >messages in long-lived dialogs. However, it appears to have a major hole i= n it: >handing of outbound messages for the purpose of maintaining soft-state in = those >dialogs isn't handled correctly. > >In particular: networks that deploy this mechanism will cause SUBSCRIBE >dialogs to time out and be destroyed while they are still in use. >Additionally, if RFC 4028 (session timers) is negotiated, then INVITE dial= ogs >will suffer the same fate. > >I can think of a couple of ways for these situations to be handled, but th= ey >need explicit text in the document. > >One approach would be to specify that the User Agent selects its requested >"Expires" value in its registration to be the smallest value before its se= t of >subscriptions and session timers needs to be refreshed. This would cause a= push >notification to happen to prevent registration timeout, and the client cou= ld >refresh the other soft state at that time. Complications arise if the regi= strar >responds with a 483 (Interval too Brief), and we'd need to find a solution= for >that. > >Another approach would be for the clients to refresh all soft state whenev= er >they send a registration, and set the timeout for that soft state to be eq= ual to >or greater than the registration timeout. A complication could arise if th= e >notifier or the peer in an invite dialog shortens the requested time, and = we'd >need to find a solution for that. > >A third approach would be getting the proxy involved in some way -- either= by >requiring it to observe subscription and session timer timeouts and requir= ing it >to send push notifications prior to their expiration, or by an explicit >communication between the UA and the proxy that indicates when the next pu= sh >notification should be scheduled. If the latter approach is taken, I would >suggest that it needs to be taken for REGISTER messages as well. > >I really don't think this mechanism is feasibly deployable without a solut= ion to >this problem. This has been addressed, and the text in section 4.1.1 now says: "This specification does not define a mechanism to explicitly request push notifications from the SIP network for usages other than triggering binding-refresh REGISTER requests (e.g., for sending periodic subscription-refresh SUBSCRIBE requests [RFC6665]), nor does it describe how to distinguish push notifications associated with such usages from the push notifications used to trigger binding- refresh REGISTER requests. If a SIP UA wants to use push notifications for other usages, the UA can perform actions associated with such usages (in addition to sending a binding-refresh REGISTER request) whenever it receives a push notification by using the same refresh interval that is used for the binding-refreshes." --------------------------------------------------------------------------- =A74.1: > For privacy and security reasons, the UA MUST NOT include the SIP URI > parameters defined in this document in non-REGISTER request, to > prevent the PNS information associated with the UA from reaching the > remote peer. > >This seems to ignore the availability of Contact URI parameters via RFC 36= 80 >subscriptions. This would seem to impose a requirement on Registrars to st= rip >this information before making it available to any other party (which, in >turn, requires that the system have explicit Registrar *and* Proxy support= ). >As far as I can tell, the system so far has not required explicit proxy su= pport >(and there's certainly no mechanism built-in that ensures that a proxy has= any >special handling regarding this mechanism). > >If the PNS information is sensitive, and cannot be allowed to leak out to >other users, then we need some way to ensure the registrar has provided >positive confirmation that it will not do so before allowing it to come in= to >possession of them. This has been addressed, and the text now says: "For privacy and security reasons, a UA MUST NOT insert the SIP URI parameters (except for the pn-purr parameter) defined in this specification in non-REGISTER request in order to prevent the PNS information associated with the UA from reaching the remote peer. For example, the UA MUST NOT insert the pn-prid SIP URI parameter in the Contact header field URI of an INVITE request. REGISTER requests will not reach the remote peer, as they will be terminated by the registrar of the UA. However, the registrar MUST still ensure that the parameters are not sent to other users, e.g., using the SIP event package for registrations mechanism [RFC3680]. See Section 13 for more information." Section 13 (Security Considerations) contains the following text: "Operators MUST ensure that the PNS-related SIP URI parameters conveyed by a user in the Contact URI of a REGISTER request are not sent to other users, or to non-trusted network entities. One way to convey contact information is by using the the SIP event package for registrations mechanism [RFC3680]. [RFC3680] defines generic security considerations for the SIP event package for registrations. As the PNS-related SIP URI parameters conveyed in the REGISTER request contain sensitive information, operators that support the event package MUST ensure that event package subscriptions are properly authenticated and authorized, and that the SIP URI parameters are not inserted in event notifications sent to other users, or to non-trusted network entities." --------------------------------------------------------------------------- =A74.2: > The UA can do so by only including the pn-provider > SIP URI parameter in the SIP Contact header field URI of the REGISTER > request, but without including the pn-prid SIP URI parameter. > >Unless I'm mistaken, this is a barrier to interoperation. > >It's not 100% clear, but I suspect the intended implication is that the >pn-provider parameter here will contain a single value? The syntax of the >parameter certainly seems to imply that. This seems to be a pretty big >problem, since it presupposes that the client will know which PNSes the Pr= oxy >supports. Consider, for example, an iOS client that can use any of RFC 80= 30, >FCM, and APN (cf https://firebase.google.com/docs/cloud-messaging/ios/clie= nt). >If the client doesn't know a priori what the proxy supports (and this enti= re >section only makes sense if that's true), then it won't know which of thos= e >three services to indicate in its REGISTER request. If it guesses wrong, t= his >mechanism simply fails. > >I think you need a different discovery mechanism here -- either have one t= hat >has the client offering multiple PNS protocols and the proxy responding wi= th >one, or have one in which the proxy indicates all of its supported service= s in >a response, and the client chooses one to use in its next REGISTER message= . This has been addressed in section 4.1.5 (Query Network PNS Capabilities). = The UA can now choose to not include the pn-provider parameter, in which case the network = will return all PNS protocols supported. --------------------------------------------------------------------------- >Figure 1: > >This diagram includes both a ladder diagram and an example REGISTER messag= e. >While both of these are useful at this point in the document, neither of t= hem is >an "Architecture," and they're really two different things. I suggest brea= king >this into two Figures, entitled "Typical Information Flow" and "Example RE= GISTER >Message" (or similar), respectively. This has been addressed as suggested in Section 1 (Introduction). --------------------------------------------------------------------------- * =A74.1: > As long as the UA wants to receive push notifications (requested by > the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param > (if required for the specific PNS provider) SIP URI parameter in each > binding-refresh REGISTER request. > >Please be clear that these parameters appear in the Contact URI. Eventhough the text above does no longer exist, it has now been generally c= larified that the parameters appear in the Contact URI. (I did note a bug in section 4.1.2. I says "UA MUST include", but it shall = be "UA MUST NOT include") --------------------------------------------------------------------------- =A75.2: > In order to request push notifications towards a SIP UA that will > trigger the UA to send binding-refresh SIP REGISTER requests, the SIP > proxy needs to have information about when a registration will > expire. The proxy needs to be able to retrieve the information from > the registrar using some mechanism. Such mechanisms are outside the > scope of this document, but could be implemented e.g., using the > SIPregistration event package mechanism [RFC3680]. > >Nit: "SIP registration" Has been fixed. >This mechanism seems to be predicated on an architecture in which the prox= y must >be on the traffic path. Although it's problematic from a "what proxies are >expected to do" perspective, it seems like the proxy could glean this >information from the 200 response to the REGISTER request. (I mean, the pr= oxy is >already reading parameters out of the contact header field, so the behavio= r of >acting on registration information is already assumed). The proxy would, o= f >course, need to run its own timers, but that seems to be a pretty minor >requirement, given everything else involved here. When I previously replied to your COMMENT, I said the following: "One way to implement the "retrieve the information from the registrar" cou= ld of course be using own timers. But, I don't think we should specify such behavior. Also, in some cases the proxy might be co-located with the "home proxy", or= some other network node, where the interface with the registrar already exists." No changes were done based on the comment. --------------------------------------------------------------------------- =A75.3.1: >This is a major comment, and one that has a sufficient impact on interop t= hat I >had a long debate with myself about whether it should be a DISCUSS. Please= take >it very seriously. > > Otherwise, if the pn-provider SIP URI parameter identifies a type of > PNS that the proxy does not support, or if the REGISTER request does > not contain all additional information required for the specific type > of PNS, the proxy MUST either forward the request (e.g., if the proxy > knows that another proxy that will receive the REGISTER request > supports the type of PNS)... > >How would the proxy know this? In the previous reply, I said "local configuration". It has been clarified in the text, and the text in section 5.6.1.1 now says= : "If the proxy knows (by means of local configuration)" >Features like suppressing PNS behavior when a "sip.pns" feature capability= is >present in the REGISTER imply that the various nodes in the network discov= er >capabilities of their neighbors automatically (which is consistent with th= e way >SIP does features), while this provision seems to require provisioned know= ledge. >This is going to be operationally very confusing. > >At the very least, the document needs to call out how this "knowledge" is >obtained. In the more general sense, since a client cannot rely on the pro= xy >supporting *any* kind of PNS, the use of 555 in the way specified here is = at >best an optimization -- and, since the configured information can conflict= with >actual reality, it's an optimization that can actually break things unless >extreme care is exercised. (e.g., if the proxy is configured to "know" tha= t the >next proxy cannot provide push service, but this knowledge is wrong, then = the >network is unnecessarily broken.) > >My rather strong recommendation is to remove this code, and let the client= rely >on the lack of indication of support in the response indicate that the fea= ture >is not supported. In my previous reply I said: "I would like to keep the code, because there are cases where one wants the= register to be rejected (rather than accepted, but without indication of supported PNS) if the PNS = is not supported. Also, there are already deployments of 555, so I'd prefer to keep it, as it= doesn't break anything." The 555 response code has been kept, and regarding the proxy knowing it was= clarified that it is based on local configuration (see above). --------------------------------------------------------------------------- =A75.3.1: > o if the proxy received a 'sip.pnsreg' media feature tag in the > REGISTER request, the proxy SHOULD include a 'sip.pnsreg' feature- > capability indicator with an indicator value bigger than 120 in > the response, unless the proxy always want to request push > >Nit: "...wants..." Has been fixed. --------------------------------------------------------------------------- =A75.3.2: > If the contact of the REGISTER request does not match > the Request-URI of the SIP request to be forwarded, or if the contact > was not present in the REGISTER response, the proxy MUST reject the > SIP request with a 404 (Not Found) response. > >This seems to be a very strong requirement ("MUST") when, e.g., many or mo= st >networks may want to return a 480 instead of a 404. I think what you want = to say >is something like "...MUST reject the SIP request. Response codes of eithe= r >404 (Not Found) or 480 (Temporarily Unavailable) are RECOMMENDED, but othe= r >appropriate codes may be used as well." This has been addressed with the following text: "It is RECOMMENDED that the proxy sends either a 404 (Not Found) response or a 480 (Temporarily Unavailable) response to the SIP request, but other response codes can be used as well." --------------------------------------------------------------------------- =A75.3.2: > The reason the proxy needs to wait for the REGISTER response before > forwarding the SIP request is to make sure that the REGISTER request > has been accepted by the registrar, and that the UA which initiated > >Nit: "...the UA that initiated..." Has been fixed. --------------------------------------------------------------------------- =A75.3.2: > In case of non-2xx response to the REGISTER request, the proxy MUST > reject the SIP request with a 404 (Not Found) response. > > If the push notification request fails (see PNS-specific > documentation for details), the proxy MUST reject the SIP request > with a 480 (Temporarily Unavailable) response. > > If the proxy does not receive the REGISTER request from the UA within > a given time after the proxy has requested the push notification, the > proxy MUST reject the request with a 480 (Temporarily Unavailable) > response. The time value is set based on local policy. > >As above, this seems way too restrictive in terms of mandating specific er= ror >codes. It may well be the case that a network would want to treat these >situations identically from the perspective of the calling party. Has been addressed (see above). --------------------------------------------------------------------------- =A75.3.2: > Otherwise the > proxy MUST reject the SIP request with a 480 (Temporarily > Unavailable) response. > >Same comment as above. Has been addressed (see above). --------------------------------------------------------------------------- =A76.1.1: > When the UA sends in initial request for a dialog, or a 2xx response > >Nit: "...sends an initial request..." Has been fixed. > purr' SIP URI parameter in the Contact header of the request or > >Nit: "...Contact header field..." Has been fixed. > NOTE: As the 'pn-purr' SIP URI parameter only applies to a give > dialog, the UA needs to include a 'pn-purr' parameter in the Contact > >Nit: "...given dialog..." Has been fixed. > dialog, the UA needs to include a 'pn-purr' parameter in the Contact > header of the request or response for each dialog in which the UA is > >Nit: "...Contact header field..." Has been fixed. --------------------------------------------------------------------------- =A76.1.1: > The UA MUST include a parameter value identical to the the > last 'sip.pnspurr' feature-capability indicator that it received in a > REGISTER response. > >This is incredibly confusing, as the "sip.pnspurr" indicator has not been >mentioned in the document so far. Please revise as something along the lin= es of: > > The UA MUST include a parameter value identical to the the last > 'sip.pnspurr' feature-capability indicator (see Section 6.2.1) that it > received in a REGISTER response. > >Alternately, reverse the order of sections 6.1 and 6.2 so that the PURR >concept is properly introduced before protocol procedures are defined for = it. This has been addressed, by adding a reference to Section 6.2.1. --------------------------------------------------------------------------- * =A76.1.1: > NOTE: As the 'pn-purr' SIP URI parameter only applies to a give > dialog, the UA needs to include a 'pn-purr' parameter in the Contact > header of the request or response for each dialog in which the UA is > willing to receive push notifications triggered by incoming mid- > dialog requests. > >Similar to the above, this is a very confusing introduction of the "pn-pur= r" URI >parameter. I realized this has been fixed in the wrong section. I will fix that by add= ing a reference to Section 6.2.1. Note, though, that the first occurrence of 'pn-purr' SIP URI parameter is i= n the first paragraph of section 6.1.1, so I will add the reference there. --------------------------------------------------------------------------- =A76.2.2: > Contact header field with a PURR value that the proxy has generated > Section 6.2.2, the proxy MUST add a Record-Route header to the > request, to insert itself in the dialog route [RFC3261]. > >This "Section 6.2.2" makes the sentence impossible to read. Is it intended= to be >in parentheses? Has been fixed. --------------------------------------------------------------------------- =A76.2.3: > As described in Section 5.3.2, while waiting for the push > notification request to succeed, and the associated REGISTER request > to arrive from the SIP UA, the proxy needs to take into consideration > that the transaction associated with the NOTIFY request will > eventually time out at the sender of the request (UAC), and the > sender will consider the transaction a failure. > >I think this needs some discussion about the impact of the error codes sel= ected >by the proxy on the dialog and its usages. For example: > >* If the proxy sends a 404 to prevent a transaction timeout, it will destr= oy the > dialog and all of its usages > >* If the proxy sends a 480 to prevent a transaction timeout, it will destr= oy the > usage, but not other usages in the dialog (if any) > >* If the proxy sends a 504 to prevent a transaction timeout, it will keep = the > dialog and the usage alive, and allow the client to re-try at a later ti= me. > Simply allowing the transaction to time out will have the same effect, a= lbeit > with more message retransmissions. > > Pointing to RFC 5057 might be useful here. This has been addressed. The text in Section 6.2.3 now says: "When a proxy sends an error response to a mid-dialog request (e.g., due to a transaction time out), the proxy SHOULD select a response code that only impacts the transaction associated with the request ([RFC5079])." --------------------------------------------------------------------------- =A78.7: > Parameter value characters that are not part of pvalue needs to be > escaped, as defined in RFC 3261. > >Nit: "...need to be escaped..." Has been fixed. --------------------------------------------------------------------------- =A79: > When a new value is registered to the PNS Sub-registry, a reference > to a specification which describes the usage of the PNS associated > >Nit: "...specification that describes..." Has been fixed. --------------------------------------------------------------------------- =A7=A710-12: >Nit: It seems like these should all be subsections of section 9. In my previous reply I said: "The idea was that the PNS registrations are in separate main sections, as = they could even be in a separate document." No changes were done based on this comment. --------------------------------------------------------------------------- =A710: > The Topic consists of the Bundle ID, which uniquelly identifies an > appliciation, and a service value that identifies a service > >Nit: "uniquely" >Nit: "application" This has been fixed. --------------------------------------------------------------------------- =A710: > Example: pn-param =3D DEF123GHIJ.com.yourcompany.yourexampleapp.voip > >Please use an RFC 2026 domain for this example; e.g.: > > Example: pn-param =3D DEF123GHIJ.com.example.yourexampleapp.voip Has been fixed. --------------------------------------------------------------------------- =A711: > [RFC8292] defines a mechanism which allows a proxy to identity itself > > Nit: "...mechanism that allows..." Has been fixed. --------------------------------------------------------------------------- Regards, Christer --_000_HE1PR07MB31616FC1F5E8B496C5C14A9F93760HE1PR07MB3161eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Adam,


Thank You!


Your issues have been addressed.= In this reply I more or less copy/paste what I said in my previous reply t= o your review, and give some extra details on how issues were solved.


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

COMMENT:
----------------------------------------------------------------------

>It's nice that this document has considered th= e impact of inbound mid-dialog
>messages in long-lived dialogs. However, it appears to have a major hol= e in it:
>handing of outbound messages for the purpose of maintaining soft-state = in those
>dialogs isn't handled correctly.
>
>In particular: networks that deploy this mechanism will cause SUBSCRIBE=
>dialogs to time out and be destroyed while they are still in use.
>Additionally, if RFC 4028 (session timers) is negotiated, then INVITE d= ialogs
>will suffer the same fate.
>
>I can think of a couple of ways for these situations to be handled, but= they
>need explicit text in the document.
>
>One approach would be to specify that the User Agent selects its reques= ted
>"Expires" value in its registration to be the smallest value = before its set of
>subscriptions and session timers needs to be refreshed. This would caus= e a push
>notification to happen to prevent registration timeout, and the client = could
>refresh the other soft state at that time. Complications arise if the r= egistrar
>responds with a 483 (Interval too Brief), and we'd need to find a solut= ion for
>that.
>
>Another approach would be for the clients to refresh all soft state whe= never
>they send a registration, and set the timeout for that soft state to be= equal to
>or greater than the registration timeout. A complication could arise if= the
>notifier or the peer in an invite dialog shortens the requested time, a= nd we'd
>need to find a solution for that.
>
>A third approach would be getting the proxy involved in some way -- eit= her by
>requiring it to observe subscription and session timer timeouts and req= uiring it
>to send push notifications prior to their expiration, or by an explicit=
>communication between the UA and the proxy that indicates when the next= push
>notification should be scheduled. If the latter approach is taken, I wo= uld
>suggest that it needs to be taken for REGISTER messages as well.
>
>I really don't think this mechanism is feasibly deployable without a so= lution to
>this problem.

This has been addressed, and the text in section 4= .1.1 now says:
 "This specification does not define a mechanism to explicit= ly request
   push notifications from the SIP network for usages other than<= br>    triggering binding-refresh REGISTER requests (e.g., for sendin= g
   periodic subscription-refresh SUBSCRIBE requests [RFC6665]), n= or does
   it describe how to distinguish push notifications associated w= ith
   such usages from the push notifications used to trigger bindin= g-
   refresh REGISTER requests.  If a SIP UA wants to use push=
   notifications for other usages, the UA can perform actions ass= ociated
   with such usages (in addition to sending a binding-refresh REG= ISTER
   request) whenever it receives a push notification by using the= same
   refresh interval that is used for the binding-refreshes."=


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

=A74.1:

>  For privacy and security reasons, the UA MUST NOT include the SI= P URI
>  parameters defined in this document in non-REGISTER request, to<= br> >  prevent the PNS information associated with the UA from reaching= the
>  remote peer.
>
>This seems to ignore the availability of Contact URI parameters via RFC= 3680
>subscriptions. This would seem to impose a requirement on Registrars to= strip
>this information before making it available to any other party (which, = in
>turn, requires that the system have explicit Registrar *and* Proxy supp= ort).
>As far as I can tell, the system so far has not required explicit proxy= support
>(and there's certainly no mechanism built-in that ensures that a proxy = has any
>special handling regarding this mechanism).
>
>If the PNS information is sensitive, and cannot be allowed to leak out = to
>other users, then we need some way to ensure the registrar has provided=
>positive confirmation that it will not do so before allowing it to come= into
>possession of them.

This has been addressed, and the text n= ow says:
 "For privacy and security reasons, a UA MUST NOT insert the= SIP URI
   parameters (except for the pn-purr parameter) defined in this<= br>    specification in non-REGISTER request in order to prevent the = PNS
   information associated with the UA from reaching the remote pe= er.
   For example, the UA MUST NOT insert the pn-prid SIP URI parame= ter in
   the Contact header field URI of an INVITE request.  REGIS= TER requests
   will not reach the remote peer, as they will be terminated by = the
   registrar of the UA.  However, the registrar MUST still e= nsure that
   the parameters are not sent to other users, e.g., using the SI= P event
   package for registrations mechanism [RFC3680].  See Secti= on 13 for
   more information."
Section 13 (Security Considerations) contains the following text:
"Operators MUST ensure that the PNS-related SIP URI parameters    conveyed by a user in the Contact URI of a REGISTER request ar= e not
   sent to other users, or to non-trusted network entities. = One way to
   convey contact information is by using the the SIP event packa= ge for
   registrations mechanism [RFC3680].  [RFC3680] defines gen= eric
   security considerations for the SIP event package for registra= tions.
   As the PNS-related SIP URI parameters conveyed in the REGISTER=
   request contain sensitive information, operators that support = the
   event package MUST ensure that event package subscriptions are=
   properly authenticated and authorized, and that the SIP URI    parameters are not inserted in event notifications sent to oth= er
   users, or to non-trusted network entities."

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

=A74.2:

>  The UA can do so by only including the pn-provider
>  SIP URI parameter in the SIP Contact header field URI of the REG= ISTER
>  request, but without including the pn-prid SIP URI parameter. >
>Unless I'm mistaken, this is a barrier to interoperation.
>
>It's not 100% clear, but I suspect the intended implication is that the=
>pn-provider parameter here will contain a single value? The syntax of t= he
>parameter certainly seems to imply that. This seems to be a pretty big<= br> >problem, since it presupposes that the client will know which PNSes the= Proxy
>supports.  Consider, for example, an iOS client that can use any o= f RFC 8030,
>FCM, and APN (cf https://firebase.google.com/docs/cloud-messaging/ios/client).
>If the client doesn't know a priori what the proxy supports (and this e= ntire
>section only makes sense if that's true), then it won't know which of t= hose
>three services to indicate in its REGISTER request. If it guesses wrong= , this
>mechanism simply fails.
>
>I think you need a different discovery mechanism here -- either have on= e that
>has the client offering multiple PNS protocols and the proxy responding= with
>one, or have one in which the proxy indicates all of its supported serv= ices in
>a response, and the client chooses one to use in its next REGISTER mess= age.

This has been addressed in section 4.1.5 (Qu= ery Network PNS Capabilities). The UA can now 
choose to not include the pn-provider parameter, i= n which case the network will return all 
PNS protocols supported.

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

>Figure 1:
>
>This diagram includes both a ladder diagram and an example REGISTER mes= sage.
>While both of these are useful at this point in the document, neither o= f them is
>an "Architecture," and they're really two different things. I= suggest breaking
>this into two Figures, entitled "Typical Information Flow" an= d "Example REGISTER
>Message" (or similar), respectively.

This has been addressed as suggested in Section 1 = (Introduction).

---------------------------------------------------------------------------=
*
=A74.1:

>  As long as the UA wants to receive push notifications (requested= by
>  the proxy), the UA MUST include a pn-provider, pn-prid and a pn-= param
>  (if required for the specific PNS provider) SIP URI parameter in= each
>  binding-refresh REGISTER request.
>
>Please be clear that these parameters appear in the Contact URI.

Eventhough the text above does no longer exist, it= has now been generally clarified that the parameters appear in the Contact= URI.

(I did note a bug in section 4.1.2. I says "U= A MUST include", but it shall be "UA MUST NOT include")

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

=A75.2:

>  In order to request push notifications towards a SIP UA that wil= l
>  trigger the UA to send binding-refresh SIP REGISTER requests, th= e SIP
>  proxy needs to have information about when a registration will >  expire.  The proxy needs to be able to retrieve the informa= tion from
>  the registrar using some mechanism.  Such mechanisms are ou= tside the
>  scope of this document, but could be implemented e.g., using the=
>  SIPregistration event package mechanism [RFC3680].
>
>Nit: "SIP registration"

Has been fixed.

>This mechanism seems to be predicated on an architecture in which the p= roxy must
>be on the traffic path. Although it's problematic from a "what pro= xies are
>expected to do" perspective, it seems like the proxy could glean t= his
>information from the 200 response to the REGISTER request. (I mean, the= proxy is
>already reading parameters out of the contact header field, so the beha= vior of
>acting on registration information is already assumed). The proxy would= , of
>course, need to run its own timers, but that seems to be a pretty minor=
>requirement, given everything else involved here.

When I previously replied to your COMMENT, I said = the following:

"One way to implement the "retrieve the information from the= registrar" could of course be using own timers. 
But, I don't think we should specify such behavior.

Also, in some cases the proxy might be co-located with the "home proxy= ", or some other network node, 
where the interface with the registrar already exists."

No changes were done based on the comment.

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

=A75.3.1:

>This is a major comment, and one that has a sufficient impact on intero= p that I
>had a long debate with myself about whether it should be a DISCUSS. Ple= ase take
>it very seriously.
>
>  Otherwise, if the pn-provider SIP URI parameter identifies a typ= e of
>  PNS that the proxy does not support, or if the REGISTER request = does
>  not contain all additional information required for the specific= type
>  of PNS, the proxy MUST either forward the request (e.g., if the = proxy
>  knows that another proxy that will receive the REGISTER request<= br> >  supports the type of PNS)...
>
>How would the proxy know this?

In the previous reply, I said "local configur= ation".

It has been clarified in the text, and the text in= section 5.6.1.1 now says:

"If the proxy knows (by means of local configuration)"

>Features like suppressing PNS behavior when a "sip.pns" featu= re capability is
>present in the REGISTER imply that the various nodes in the network dis= cover
>capabilities of their neighbors automatically (which is consistent with= the way
>SIP does features), while this provision seems to require provisioned k= nowledge.
>This is going to be operationally very confusing.
>
>At the very least, the document needs to call out how this "knowle= dge" is
>obtained. In the more general sense, since a client cannot rely on the = proxy
>supporting *any* kind of PNS, the use of 555 in the way specified here = is at
>best an optimization -- and, since the configured information can confl= ict with
>actual reality, it's an optimization that can actually break things unl= ess
>extreme care is exercised. (e.g., if the proxy is configured to "k= now" that the
>next proxy cannot provide push service, but this knowledge is wrong, th= en the
>network is unnecessarily broken.)
>
>My rather strong recommendation is to remove this code, and let the cli= ent rely
>on the lack of indication of support in the response indicate that the = feature
>is not supported.

In my previous reply I said:

"I would like to keep the code, because there are cases where one= wants the register to be rejected 
(rather than accepted, but without indication of supported PNS) if the= PNS is not supported.

Also, there are already deployments of 555, so I'd prefer to keep it, as it= doesn't break anything."

The 555 response code has been kept, and regarding the proxy knowing i= t was clarified that it is based on local configuration (see above).

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

=A75.3.1:

>  o  if the proxy received a 'sip.pnsreg' media feature tag i= n the
>     REGISTER request, the proxy SHOULD include a '= sip.pnsreg' feature-
>     capability indicator with an indicator value b= igger than 120 in
>     the response, unless the proxy always want to = request push
>
>Nit: "...wants..."

Has been fixed.

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

=A75.3.2:

>  If the contact of the REGISTER request does not match
>  the Request-URI of the SIP request to be forwarded, or if the co= ntact
>  was not present in the REGISTER response, the proxy MUST reject = the
>  SIP request with a 404 (Not Found) response.
>
>This seems to be a very strong requirement ("MUST") when, e.g= ., many or most
>networks may want to return a 480 instead of a= 404. I think what you want to say
>is something like "...MUST reject the SIP request. Response codes = of either
>404 (Not Found) or 480 (Temporarily Unavailable) are RECOMMENDED, but o= ther
>appropriate codes may be used as well."

This has been addressed with the following text:

"It is RECOMMENDED that the proxy sends either a 404 (Not
 Found) response or a 480 (Temporarily Unavailable) response to the  SIP request, but other response codes can be used as well."

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

=A75.3.2:

>  The reason the proxy needs to wait for the REGISTER response bef= ore
>  forwarding the SIP request is to make sure that the REGISTER req= uest
>  has been accepted by the registrar, and that the UA which initia= ted
>
>Nit: "...the UA that initiated..."

Has been fixed.

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

=A75.3.2:

>  In case of non-2xx response to the REGISTER request, the proxy M= UST
>  reject the SIP request with a 404 (Not Found) response.
>
>  If the push notification request fails (see PNS-specific
>  documentation for details), the proxy MUST reject the SIP reques= t
>  with a 480 (Temporarily Unavailable) response.
>
>  If the proxy does not receive the REGISTER request from the UA w= ithin
>  a given time after the proxy has requested the push notification= , the
>  proxy MUST reject the request with a 480 (Temporarily Unavailabl= e)
>  response.  The time value is set based on local policy.
>
>As above, this seems way too restrictive in terms of mandating specific= error
>codes. It may well be the case that a network would want to treat these=
>situations identically from the perspective of the calling party.

Has been addressed (see above).

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

=A75.3.2:

>  Otherwise the
>  proxy MUST reject the SIP request with a 480 (Temporarily
>  Unavailable) response.
>
>Same comment as above.

Has been addressed (see above).

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

=A76.1.1:

>  When the UA sends in initial request for a dialog, or a 2xx resp= onse
>
>Nit: "...sends an initial request..."

Has been fixed.

>  purr' SIP URI parameter in the Contact header of the request or<= br> >
>Nit: "...Contact header field..."

Has been fixed.

>  NOTE: As the 'pn-purr' SIP URI parameter only applies to a give<= br> >  dialog, the UA needs to include a 'pn-purr' parameter in the Con= tact
>
>Nit: "...given dialog..."

Has been fixed.

>  dialog, the UA needs to include a 'pn-purr' parameter in the Con= tact
>  header of the request or response for each dialog in which the U= A is
>
>Nit: "...Contact header field..."

Has been fixed.

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

=A76.1.1:

>  The UA MUST include a parameter value identical to the the
>  last 'sip.pnspurr' feature-capability indicator that it received= in a
>  REGISTER response.
>
>This is incredibly confusing, as the "sip.pnspurr" indicator = has not been
>mentioned in the document so far. Please revise as something along the = lines of:
>
>  The UA MUST include a parameter value identical to the the last<= br> >  'sip.pnspurr' feature-capability indicator (see Section 6.2.1) t= hat it
>  received in a REGISTER response.
>
>Alternately, reverse the order of sections 6.1 and 6.2 so that the PURR=
>concept is properly introduced before protocol procedures are defined f= or it.

This has been addressed, by adding a reference to = Section 6.2.1.

---------------------------------------------------------------------------=
*
=A76.1.1:

>  NOTE: As the 'pn-purr' SIP URI parameter only applies to a give<= br> >  dialog, the UA needs to include a 'pn-purr' parameter in the Con= tact
>  header of the request or response for each dialog in which the U= A is
>  willing to receive push notifications triggered by incoming mid-=
>  dialog requests.
>
>Similar to the above, this is a very confusing introduction of the &quo= t;pn-purr" URI
>parameter.

I realized this has been fixed in the wrong sectio= n. I will fix that by adding a reference to Section 6.2.1.

Note, though, that the first occurrence of 'pn-purr' SIP URI parameter is in the= first paragraph of section 6.1.1, so I will add the reference there.

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

=A76.2.2:

>  Contact header field with a PURR value that the proxy has genera= ted
>  Section 6.2.2, the proxy MUST add a Record-Route header to the >  request, to insert itself in the dialog route [RFC3261].
>
>This "Section 6.2.2" makes the sentence impossible to read. I= s it intended to be
>in parentheses?

Has been fixed.

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

=A76.2.3:

>  As described in Section 5.3.2, while waiting for the push
>  notification request to succeed, and the associated REGISTER req= uest
>  to arrive from the SIP UA, the proxy needs to take into consider= ation
>  that the transaction associated with the NOTIFY request will
>  eventually time out at the sender of the request (UAC), and the<= br> >  sender will consider the transaction a failure.
>
>I think this needs some discussion about the impact of the error codes = selected
>by the proxy on the dialog and its usages. For example:
>
>* If the proxy sends a 404 to prevent a transaction timeout, it will de= stroy the
>  dialog and all of its usages
>
>* If the proxy sends a 480 to prevent a transaction timeout, it will de= stroy the
>  usage, but not other usages in the dialog (if any)
>
>* If the proxy sends a 504 to prevent a transaction timeout, it will ke= ep the
>  dialog and the usage alive, and allow the client to re-try at a = later time.
>  Simply allowing the transaction to time out will have the same e= ffect, albeit
> with more message retransmissions.
>
> Pointing to RFC 5057 might be useful here.

This has been addressed. The text in Section 6.2.3= now says:

   "When a proxy sends an error response to a mid-dialo= g request (e.g.,
   due to a transaction time out), the proxy SHOULD select a resp= onse
   code that only impacts the transaction associated with the req= uest
   ([RFC5079])."

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

=A78.7:

>    Parameter value characters that are not part of pval= ue needs to be
>    escaped, as defined in RFC 3261.
>
>Nit: "...need to be escaped..."

Has been fixed.

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

=A79:

>  When a new value is registered to the PNS Sub-registry, a refere= nce
>  to a specification which describes the usage of the PNS associat= ed
>
>Nit: "...specification that describes..."

Has been fixed.

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

=A7=A710-12:

>Nit: It seems like these should all be subsections of section 9.

In my previous reply I said:

"The idea was that the PNS registration= s are in separate main sections, as they could even be in a separate docume= nt."

No changes were done based on this comment.

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

=A710:

>  The Topic consists of the Bundle ID, which uniquelly identifies = an
>  appliciation, and a service value that identifies a service
>
>Nit: "uniquely"
>Nit: "application"

This has been fixed.

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

=A710:

>  Example: pn-param =3D DEF123GHIJ.com.yourcompany.yourexampleapp.= voip
>
>Please use an RFC 2026 domain for this example; e.g.:
>
>  Example: pn-param =3D DEF123GHIJ.com.example.yourexampleapp.voip=

Has been fixed.

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

=A711:

>  [RFC8292] defines a mechanism which allows a proxy to identity i= tself
>
> Nit: "...mechanism that allows..."

Has been fixed.

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

Regards,

Christer

--_000_HE1PR07MB31616FC1F5E8B496C5C14A9F93760HE1PR07MB3161eurp_-- From nobody Fri Mar 1 13:47:41 2019 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 9ECE1130F2C; Fri, 1 Mar 2019 13:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 vSpRLRz9Lq5I; Fri, 1 Mar 2019 13:47:09 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15984130F3F; Fri, 1 Mar 2019 13:47:09 -0800 (PST) Received: from Orochi.local (rrcs-24-173-40-58.sw.biz.rr.com [24.173.40.58]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x21Lkxca015596 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 1 Mar 2019 15:47:01 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551476823; bh=6Kw04wI6EPGkMnVpXVIq6UOQExZAM7a5AdXzExTIq3E=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=oDtZDCNS2WnjUd7xucRh6qjI5NzIGvKYKWLd3LFbBbGA6gIcv2IgLTKq1V2yfhYOB 6Em/EH6pxIKwGxLw7/vf5otEz7zf/rrOADZf8HKYBCZQOBI9FGWM9/LfyofSrZ/011 N94uT6/svghn7HP6jEVKAJZlsFkLknBbpt0rxlpQ= X-Authentication-Warning: raven.nostrum.com: Host rrcs-24-173-40-58.sw.biz.rr.com [24.173.40.58] claimed to be Orochi.local To: Christer Holmberg , The IESG Cc: "draft-ietf-sipcore-sip-push@ietf.org" , Brian Rosen , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" References: <155146051337.6186.9467252084775433080.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <377b379d-3747-3748-694d-2c3fa621483b@nostrum.com> Date: Fri, 1 Mar 2019 15:46:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9D7DCED0AAB74BEBDD290DFC" Content-Language: en-US Archived-At: Subject: Re: [sipcore] Adam Roach's No Objection on draft-ietf-sipcore-sip-push-26: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:47:23 -0000 This is a multi-part message in MIME format. --------------9D7DCED0AAB74BEBDD290DFC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit HI! I apologize if it was unclear from my preamble, but the original comments were only included because I wanted the document ballot to retain them for historical purposes. No reply was necessary. /a On 3/1/19 15:31, Christer Holmberg wrote: > > Hi Adam, > > > Thank You! > > > Your issues have been addressed. In this reply I more or less > copy/paste what I said in my previous reply to your review, and give > some extra details on how issues were solved. > > > ---------------------------------------------------------------------- > > COMMENT: > ---------------------------------------------------------------------- > > >It's nice that this document has considered the impact of inbound mid-dialog > >messages in long-lived dialogs. However, it appears to have a major > hole in it: > >handing of outbound messages for the purpose of maintaining > soft-state in those > >dialogs isn't handled correctly. > > > >In particular: networks that deploy this mechanism will cause SUBSCRIBE > >dialogs to time out and be destroyed while they are still in use. > >Additionally, if RFC 4028 (session timers) is negotiated, then INVITE > dialogs > >will suffer the same fate. > > > >I can think of a couple of ways for these situations to be handled, > but they > >need explicit text in the document. > > > >One approach would be to specify that the User Agent selects its > requested > >"Expires" value in its registration to be the smallest value before > its set of > >subscriptions and session timers needs to be refreshed. This would > cause a push > >notification to happen to prevent registration timeout, and the > client could > >refresh the other soft state at that time. Complications arise if the > registrar > >responds with a 483 (Interval too Brief), and we'd need to find a > solution for > >that. > > > >Another approach would be for the clients to refresh all soft state > whenever > >they send a registration, and set the timeout for that soft state to > be equal to > >or greater than the registration timeout. A complication could arise > if the > >notifier or the peer in an invite dialog shortens the requested time, > and we'd > >need to find a solution for that. > > > >A third approach would be getting the proxy involved in some way -- > either by > >requiring it to observe subscription and session timer timeouts and > requiring it > >to send push notifications prior to their expiration, or by an explicit > >communication between the UA and the proxy that indicates when the > next push > >notification should be scheduled. If the latter approach is taken, I > would > >suggest that it needs to be taken for REGISTER messages as well. > > > >I really don't think this mechanism is feasibly deployable without a > solution to > >this problem. > > This has been addressed, and the text in section 4.1.1 now says: >  "This specification does not define a mechanism to explicitly request >    push notifications from the SIP network for usages other than    > triggering binding-refresh REGISTER requests (e.g., for sending    > periodic subscription-refresh SUBSCRIBE requests [RFC6665]), nor does >    it describe how to distinguish push notifications associated with >    such usages from the push notifications used to trigger binding-    > refresh REGISTER requests.  If a SIP UA wants to use push    > notifications for other usages, the UA can perform actions associated >    with such usages (in addition to sending a binding-refresh REGISTER >    request) whenever it receives a push notification by using the same >    refresh interval that is used for the binding-refreshes." > > > --------------------------------------------------------------------------- > > §4.1: > > >  For privacy and security reasons, the UA MUST NOT include the SIP URI > >  parameters defined in this document in non-REGISTER request, to > >  prevent the PNS information associated with the UA from reaching the > >  remote peer. > > > >This seems to ignore the availability of Contact URI parameters via > RFC 3680 > >subscriptions. This would seem to impose a requirement on Registrars > to strip > >this information before making it available to any other party (which, in > >turn, requires that the system have explicit Registrar *and* Proxy > support). > >As far as I can tell, the system so far has not required explicit > proxy support > >(and there's certainly no mechanism built-in that ensures that a > proxy has any > >special handling regarding this mechanism). > > > >If the PNS information is sensitive, and cannot be allowed to leak out to > >other users, then we need some way to ensure the registrar has provided > >positive confirmation that it will not do so before allowing it to > come into > >possession of them. > > This has been addressed, and the text now says: >  "For privacy and security reasons, a UA MUST NOT insert the SIP URI >    parameters (except for the pn-purr parameter) defined in this    > specification in non-REGISTER request in order to prevent the PNS    > information associated with the UA from reaching the remote peer.    > For example, the UA MUST NOT insert the pn-prid SIP URI parameter in >    the Contact header field URI of an INVITE request.  REGISTER > requests    will not reach the remote peer, as they will be terminated > by the    registrar of the UA.  However, the registrar MUST still > ensure that    the parameters are not sent to other users, e.g., using > the SIP event    package for registrations mechanism [RFC3680].  See > Section 13 for    more information." > Section 13 (Security Considerations) contains the following text: > "Operators MUST ensure that the PNS-related SIP URI parameters    > conveyed by a user in the Contact URI of a REGISTER request are not    > sent to other users, or to non-trusted network entities.  One way to >    convey contact information is by using the the SIP event package > for    registrations mechanism [RFC3680].  [RFC3680] defines generic >    security considerations for the SIP event package for > registrations.    As the PNS-related SIP URI parameters conveyed in > the REGISTER    request contain sensitive information, operators that > support the    event package MUST ensure that event package > subscriptions are    properly authenticated and authorized, and that > the SIP URI    parameters are not inserted in event notifications sent > to other    users, or to non-trusted network entities." > > --------------------------------------------------------------------------- > > §4.2: > > >  The UA can do so by only including the pn-provider > >  SIP URI parameter in the SIP Contact header field URI of the REGISTER > >  request, but without including the pn-prid SIP URI parameter. > > > >Unless I'm mistaken, this is a barrier to interoperation. > > > >It's not 100% clear, but I suspect the intended implication is that the > >pn-provider parameter here will contain a single value? The syntax of the > >parameter certainly seems to imply that. This seems to be a pretty big > >problem, since it presupposes that the client will know which PNSes > the Proxy > >supports.  Consider, for example, an iOS client that can use any of > RFC 8030, > >FCM, and APN (cf > https://firebase.google.com/docs/cloud-messaging/ios/client). > >If the client doesn't know a priori what the proxy supports (and this > entire > >section only makes sense if that's true), then it won't know which of > those > >three services to indicate in its REGISTER request. If it guesses > wrong, this > >mechanism simply fails. > > > >I think you need a different discovery mechanism here -- either have > one that > >has the client offering multiple PNS protocols and the proxy > responding with > >one, or have one in which the proxy indicates all of its supported > services in > >a response, and the client chooses one to use in its next REGISTER > message. > > This has been addressed in section 4.1.5 (Query Network PNS > Capabilities). The UA can now > choose to not include the pn-provider parameter, in which case the > network will return all > PNS protocols supported. > > --------------------------------------------------------------------------- > > >Figure 1: > > > >This diagram includes both a ladder diagram and an example REGISTER > message. > >While both of these are useful at this point in the document, neither > of them is > >an "Architecture," and they're really two different things. I suggest > breaking > >this into two Figures, entitled "Typical Information Flow" and > "Example REGISTER > >Message" (or similar), respectively. > > This has been addressed as suggested in Section 1 (Introduction). > > --------------------------------------------------------------------------- > * > §4.1: > > >  As long as the UA wants to receive push notifications (requested by > >  the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param > >  (if required for the specific PNS provider) SIP URI parameter in each > >  binding-refresh REGISTER request. > > > >Please be clear that these parameters appear in the Contact URI. > > Eventhough the text above does no longer exist, it has now been > generally clarified that the parameters appear in the Contact URI. > > (I did note a bug in section 4.1.2. I says "UA MUST include", but it > shall be "UA MUST NOT include") > > --------------------------------------------------------------------------- > > §5.2: > > >  In order to request push notifications towards a SIP UA that will > >  trigger the UA to send binding-refresh SIP REGISTER requests, the SIP > >  proxy needs to have information about when a registration will > >  expire.  The proxy needs to be able to retrieve the information from > >  the registrar using some mechanism.  Such mechanisms are outside the > >  scope of this document, but could be implemented e.g., using the > >  SIPregistration event package mechanism [RFC3680]. > > > >Nit: "SIP registration" > > Has been fixed. > > >This mechanism seems to be predicated on an architecture in which the > proxy must > >be on the traffic path. Although it's problematic from a "what > proxies are > >expected to do" perspective, it seems like the proxy could glean this > >information from the 200 response to the REGISTER request. (I mean, > the proxy is > >already reading parameters out of the contact header field, so the > behavior of > >acting on registration information is already assumed). The proxy > would, of > >course, need to run its own timers, but that seems to be a pretty minor > >requirement, given everything else involved here. > > When I previously replied to your COMMENT, I said the following: > > "One way to implement the "retrieve the information from the > registrar" could of course be using own timers. > But, I don't think we should specify such behavior. > > Also, in some cases the proxy might be co-located with the "home > proxy", or some other network node, > where the interface with the registrar already exists." > > No changes were done based on the comment. > > --------------------------------------------------------------------------- > > §5.3.1: > > >This is a major comment, and one that has a sufficient impact on > interop that I > >had a long debate with myself about whether it should be a DISCUSS. > Please take > >it very seriously. > > > >  Otherwise, if the pn-provider SIP URI parameter identifies a type of > >  PNS that the proxy does not support, or if the REGISTER request does > >  not contain all additional information required for the specific type > >  of PNS, the proxy MUST either forward the request (e.g., if the proxy > >  knows that another proxy that will receive the REGISTER request > >  supports the type of PNS)... > > > >How would the proxy know this? > > In the previous reply, I said "local configuration". > > It has been clarified in the text, and the text in section 5.6.1.1 now > says: > > "If the proxy knows (by means of local configuration)" > >Features like suppressing PNS behavior when a "sip.pns" feature > capability is > >present in the REGISTER imply that the various nodes in the network > discover > >capabilities of their neighbors automatically (which is consistent > with the way > >SIP does features), while this provision seems to require provisioned > knowledge. > >This is going to be operationally very confusing. > > > >At the very least, the document needs to call out how this "knowledge" is > >obtained. In the more general sense, since a client cannot rely on > the proxy > >supporting *any* kind of PNS, the use of 555 in the way specified > here is at > >best an optimization -- and, since the configured information can > conflict with > >actual reality, it's an optimization that can actually break things > unless > >extreme care is exercised. (e.g., if the proxy is configured to > "know" that the > >next proxy cannot provide push service, but this knowledge is wrong, > then the > >network is unnecessarily broken.) > > > >My rather strong recommendation is to remove this code, and let the > client rely > >on the lack of indication of support in the response indicate that > the feature > >is not supported. > > In my previous reply I said: > > "I would like to keep the code, because there are cases where one > wants the register to be rejected > (rather than accepted, but without indication of supported PNS) if the > PNS is not supported. > > Also, there are already deployments of 555, so I'd prefer to keep it, > as it doesn't break anything." > > The 555 response code has been kept, and regarding the proxy knowing > it was clarified that it is based on local configuration (see above). > > --------------------------------------------------------------------------- > > §5.3.1: > > >  o  if the proxy received a 'sip.pnsreg' media feature tag in the > >     REGISTER request, the proxy SHOULD include a 'sip.pnsreg' feature- > >     capability indicator with an indicator value bigger than 120 in > >     the response, unless the proxy always want to request push > > > >Nit: "...wants..." > > Has been fixed. > > --------------------------------------------------------------------------- > > §5.3.2: > > >  If the contact of the REGISTER request does not match > >  the Request-URI of the SIP request to be forwarded, or if the contact > >  was not present in the REGISTER response, the proxy MUST reject the > >  SIP request with a 404 (Not Found) response. > > > >This seems to be a very strong requirement ("MUST") when, e.g., many > or most > >networks may want to return a 480 instead of a 404. I think what you want to say > >is something like "...MUST reject the SIP request. Response codes of > either > >404 (Not Found) or 480 (Temporarily Unavailable) are RECOMMENDED, but > other > >appropriate codes may be used as well." > > This has been addressed with the following text: > > "It is RECOMMENDED that the proxy sends either a 404 (Not >  Found) response or a 480 (Temporarily Unavailable) response to the >  SIP request, but other response codes can be used as well." > > --------------------------------------------------------------------------- > > §5.3.2: > > >  The reason the proxy needs to wait for the REGISTER response before > >  forwarding the SIP request is to make sure that the REGISTER request > >  has been accepted by the registrar, and that the UA which initiated > > > >Nit: "...the UA that initiated..." > > Has been fixed. > > --------------------------------------------------------------------------- > > §5.3.2: > > >  In case of non-2xx response to the REGISTER request, the proxy MUST > >  reject the SIP request with a 404 (Not Found) response. > > > >  If the push notification request fails (see PNS-specific > >  documentation for details), the proxy MUST reject the SIP request > >  with a 480 (Temporarily Unavailable) response. > > > >  If the proxy does not receive the REGISTER request from the UA within > >  a given time after the proxy has requested the push notification, the > >  proxy MUST reject the request with a 480 (Temporarily Unavailable) > >  response.  The time value is set based on local policy. > > > >As above, this seems way too restrictive in terms of mandating > specific error > >codes. It may well be the case that a network would want to treat these > >situations identically from the perspective of the calling party. > > Has been addressed (see above). > > --------------------------------------------------------------------------- > > §5.3.2: > > >  Otherwise the > >  proxy MUST reject the SIP request with a 480 (Temporarily > >  Unavailable) response. > > > >Same comment as above. > > Has been addressed (see above). > > --------------------------------------------------------------------------- > > §6.1.1: > > >  When the UA sends in initial request for a dialog, or a 2xx response > > > >Nit: "...sends an initial request..." > > Has been fixed. > > >  purr' SIP URI parameter in the Contact header of the request or > > > >Nit: "...Contact header field..." > > Has been fixed. > > >  NOTE: As the 'pn-purr' SIP URI parameter only applies to a give > >  dialog, the UA needs to include a 'pn-purr' parameter in the Contact > > > >Nit: "...given dialog..." > > Has been fixed. > > >  dialog, the UA needs to include a 'pn-purr' parameter in the Contact > >  header of the request or response for each dialog in which the UA is > > > >Nit: "...Contact header field..." > > Has been fixed. > > --------------------------------------------------------------------------- > > §6.1.1: > > >  The UA MUST include a parameter value identical to the the > >  last 'sip.pnspurr' feature-capability indicator that it received in a > >  REGISTER response. > > > >This is incredibly confusing, as the "sip.pnspurr" indicator has not been > >mentioned in the document so far. Please revise as something along > the lines of: > > > >  The UA MUST include a parameter value identical to the the last > >  'sip.pnspurr' feature-capability indicator (see Section 6.2.1) that it > >  received in a REGISTER response. > > > >Alternately, reverse the order of sections 6.1 and 6.2 so that the PURR > >concept is properly introduced before protocol procedures are defined > for it. > > This has been addressed, by adding a reference to Section 6.2.1. > > --------------------------------------------------------------------------- > * > §6.1.1: > > >  NOTE: As the 'pn-purr' SIP URI parameter only applies to a give > >  dialog, the UA needs to include a 'pn-purr' parameter in the Contact > >  header of the request or response for each dialog in which the UA is > >  willing to receive push notifications triggered by incoming mid- > >  dialog requests. > > > >Similar to the above, this is a very confusing introduction of the > "pn-purr" URI > >parameter. > > I realized this has been fixed in the wrong section. I will fix that > by adding a reference to Section 6.2.1. > > Note, though, that the first occurrence of 'pn-purr' SIP URI parameter > is in the first paragraph of section 6.1.1, so I will add the > reference there. > > --------------------------------------------------------------------------- > > §6.2.2: > > >  Contact header field with a PURR value that the proxy has generated > >  Section 6.2.2, the proxy MUST add a Record-Route header to the > >  request, to insert itself in the dialog route [RFC3261]. > > > >This "Section 6.2.2" makes the sentence impossible to read. Is it > intended to be > >in parentheses? > > Has been fixed. > > --------------------------------------------------------------------------- > > §6.2.3: > > >  As described in Section 5.3.2, while waiting for the push > >  notification request to succeed, and the associated REGISTER request > >  to arrive from the SIP UA, the proxy needs to take into consideration > >  that the transaction associated with the NOTIFY request will > >  eventually time out at the sender of the request (UAC), and the > >  sender will consider the transaction a failure. > > > >I think this needs some discussion about the impact of the error > codes selected > >by the proxy on the dialog and its usages. For example: > > > >* If the proxy sends a 404 to prevent a transaction timeout, it will > destroy the > >  dialog and all of its usages > > > >* If the proxy sends a 480 to prevent a transaction timeout, it will > destroy the > >  usage, but not other usages in the dialog (if any) > > > >* If the proxy sends a 504 to prevent a transaction timeout, it will > keep the > >  dialog and the usage alive, and allow the client to re-try at a > later time. > >  Simply allowing the transaction to time out will have the same > effect, albeit > > with more message retransmissions. > > > > Pointing to RFC 5057 might be useful here. > > This has been addressed. The text in Section 6.2.3 now says: > >    "When a proxy sends an error response to a mid-dialog request > (e.g.,    due to a transaction time out), the proxy SHOULD select a > response    code that only impacts the transaction associated with the > request    ([RFC5079])." > > --------------------------------------------------------------------------- > > §8.7: > > >    Parameter value characters that are not part of pvalue needs to be > >    escaped, as defined in RFC 3261. > > > >Nit: "...need to be escaped..." > > Has been fixed. > > --------------------------------------------------------------------------- > > §9: > > >  When a new value is registered to the PNS Sub-registry, a reference > >  to a specification which describes the usage of the PNS associated > > > >Nit: "...specification that describes..." > > Has been fixed. > > --------------------------------------------------------------------------- > > §§10-12: > > >Nit: It seems like these should all be subsections of section 9. > > In my previous reply I said: > > "The idea was that the PNS registrations are in separate main > sections, as they could even be in a separate document." > > No changes were done based on this comment. > > --------------------------------------------------------------------------- > > §10: > > >  The Topic consists of the Bundle ID, which uniquelly identifies an > >  appliciation, and a service value that identifies a service > > > >Nit: "uniquely" > >Nit: "application" > > This has been fixed. > > --------------------------------------------------------------------------- > > §10: > > >  Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp.voip > > > >Please use an RFC 2026 domain for this example; e.g.: > > > >  Example: pn-param = DEF123GHIJ.com.example.yourexampleapp.voip > > Has been fixed. > > --------------------------------------------------------------------------- > > §11: > > >  [RFC8292] defines a mechanism which allows a proxy to identity itself > > > > Nit: "...mechanism that allows..." > > Has been fixed. > > --------------------------------------------------------------------------- > > Regards, > > Christer > --------------9D7DCED0AAB74BEBDD290DFC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
HI! I apologize if it was unclear from my preamble, but the original comments were only included because I wanted the document ballot to retain them for historical purposes. No reply was necessary.

/a

On 3/1/19 15:31, Christer Holmberg wrote:

Hi Adam,


Thank You!


Your issues have been addressed. In this reply I more or less copy/paste what I said in my previous reply to your review, and give some extra details on how issues were solved.


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

COMMENT:
----------------------------------------------------------------------

>It's nice that this document has considered the impact of inbound mid-dialog
>messages in long-lived dialogs. However, it appears to have a major hole in it:
>handing of outbound messages for the purpose of maintaining soft-state in those
>dialogs isn't handled correctly.
>
>In particular: networks that deploy this mechanism will cause SUBSCRIBE
>dialogs to time out and be destroyed while they are still in use.
>Additionally, if RFC 4028 (session timers) is negotiated, then INVITE dialogs
>will suffer the same fate.
>
>I can think of a couple of ways for these situations to be handled, but they
>need explicit text in the document.
>
>One approach would be to specify that the User Agent selects its requested
>"Expires" value in its registration to be the smallest value before its set of
>subscriptions and session timers needs to be refreshed. This would cause a push
>notification to happen to prevent registration timeout, and the client could
>refresh the other soft state at that time. Complications arise if the registrar
>responds with a 483 (Interval too Brief), and we'd need to find a solution for
>that.
>
>Another approach would be for the clients to refresh all soft state whenever
>they send a registration, and set the timeout for that soft state to be equal to
>or greater than the registration timeout. A complication could arise if the
>notifier or the peer in an invite dialog shortens the requested time, and we'd
>need to find a solution for that.
>
>A third approach would be getting the proxy involved in some way -- either by
>requiring it to observe subscription and session timer timeouts and requiring it
>to send push notifications prior to their expiration, or by an explicit
>communication between the UA and the proxy that indicates when the next push
>notification should be scheduled. If the latter approach is taken, I would
>suggest that it needs to be taken for REGISTER messages as well.
>
>I really don't think this mechanism is feasibly deployable without a solution to
>this problem.

This has been addressed, and the text in section 4.1.1 now says:
 "This specification does not define a mechanism to explicitly request    push notifications from the SIP network for usages other than    triggering binding-refresh REGISTER requests (e.g., for sending    periodic subscription-refresh SUBSCRIBE requests [RFC6665]), nor does    it describe how to distinguish push notifications associated with    such usages from the push notifications used to trigger binding-    refresh REGISTER requests.  If a SIP UA wants to use push    notifications for other usages, the UA can perform actions associated    with such usages (in addition to sending a binding-refresh REGISTER    request) whenever it receives a push notification by using the same    refresh interval that is used for the binding-refreshes."


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

§4.1:

>  For privacy and security reasons, the UA MUST NOT include the SIP URI
>  parameters defined in this document in non-REGISTER request, to
>  prevent the PNS information associated with the UA from reaching the
>  remote peer.
>
>This seems to ignore the availability of Contact URI parameters via RFC 3680
>subscriptions. This would seem to impose a requirement on Registrars to strip
>this information before making it available to any other party (which, in
>turn, requires that the system have explicit Registrar *and* Proxy support).
>As far as I can tell, the system so far has not required explicit proxy support
>(and there's certainly no mechanism built-in that ensures that a proxy has any
>special handling regarding this mechanism).
>
>If the PNS information is sensitive, and cannot be allowed to leak out to
>other users, then we need some way to ensure the registrar has provided
>positive confirmation that it will not do so before allowing it to come into
>possession of them.

This has been addressed, and the text now says:
 "For privacy and security reasons, a UA MUST NOT insert the SIP URI    parameters (except for the pn-purr parameter) defined in this    specification in non-REGISTER request in order to prevent the PNS    information associated with the UA from reaching the remote peer.    For example, the UA MUST NOT insert the pn-prid SIP URI parameter in    the Contact header field URI of an INVITE request.  REGISTER requests    will not reach the remote peer, as they will be terminated by the    registrar of the UA.  However, the registrar MUST still ensure that    the parameters are not sent to other users, e.g., using the SIP event    package for registrations mechanism [RFC3680].  See Section 13 for    more information."
Section 13 (Security Considerations) contains the following text:
"Operators MUST ensure that the PNS-related SIP URI parameters    conveyed by a user in the Contact URI of a REGISTER request are not    sent to other users, or to non-trusted network entities.  One way to    convey contact information is by using the the SIP event package for    registrations mechanism [RFC3680].  [RFC3680] defines generic    security considerations for the SIP event package for registrations.    As the PNS-related SIP URI parameters conveyed in the REGISTER    request contain sensitive information, operators that support the    event package MUST ensure that event package subscriptions are    properly authenticated and authorized, and that the SIP URI    parameters are not inserted in event notifications sent to other    users, or to non-trusted network entities."

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

§4.2:

>  The UA can do so by only including the pn-provider
>  SIP URI parameter in the SIP Contact header field URI of the REGISTER
>  request, but without including the pn-prid SIP URI parameter.
>
>Unless I'm mistaken, this is a barrier to interoperation.
>
>It's not 100% clear, but I suspect the intended implication is that the
>pn-provider parameter here will contain a single value? The syntax of the
>parameter certainly seems to imply that. This seems to be a pretty big
>problem, since it presupposes that the client will know which PNSes the Proxy
>supports.  Consider, for example, an iOS client that can use any of RFC 8030,
>FCM, and APN (cf https://firebase.google.com/docs/cloud-messaging/ios/client).
>If the client doesn't know a priori what the proxy supports (and this entire
>section only makes sense if that's true), then it won't know which of those
>three services to indicate in its REGISTER request. If it guesses wrong, this
>mechanism simply fails.
>
>I think you need a different discovery mechanism here -- either have one that
>has the client offering multiple PNS protocols and the proxy responding with
>one, or have one in which the proxy indicates all of its supported services in
>a response, and the client chooses one to use in its next REGISTER message.

This has been addressed in section 4.1.5 (Query Network PNS Capabilities). The UA can now 
choose to not include the pn-provider parameter, in which case the network will return all 
PNS protocols supported.

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

>Figure 1:
>
>This diagram includes both a ladder diagram and an example REGISTER message.
>While both of these are useful at this point in the document, neither of them is
>an "Architecture," and they're really two different things. I suggest breaking
>this into two Figures, entitled "Typical Information Flow" and "Example REGISTER
>Message" (or similar), respectively.

This has been addressed as suggested in Section 1 (Introduction).

---------------------------------------------------------------------------
*
§4.1:

>  As long as the UA wants to receive push notifications (requested by
>  the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param
>  (if required for the specific PNS provider) SIP URI parameter in each
>  binding-refresh REGISTER request.
>
>Please be clear that these parameters appear in the Contact URI.

Eventhough the text above does no longer exist, it has now been generally clarified that the parameters appear in the Contact URI.

(I did note a bug in section 4.1.2. I says "UA MUST include", but it shall be "UA MUST NOT include")

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

§5.2:

>  In order to request push notifications towards a SIP UA that will
>  trigger the UA to send binding-refresh SIP REGISTER requests, the SIP
>  proxy needs to have information about when a registration will
>  expire.  The proxy needs to be able to retrieve the information from
>  the registrar using some mechanism.  Such mechanisms are outside the
>  scope of this document, but could be implemented e.g., using the
>  SIPregistration event package mechanism [RFC3680].
>
>Nit: "SIP registration"

Has been fixed.

>This mechanism seems to be predicated on an architecture in which the proxy must
>be on the traffic path. Although it's problematic from a "what proxies are
>expected to do" perspective, it seems like the proxy could glean this
>information from the 200 response to the REGISTER request. (I mean, the proxy is
>already reading parameters out of the contact header field, so the behavior of
>acting on registration information is already assumed). The proxy would, of
>course, need to run its own timers, but that seems to be a pretty minor
>requirement, given everything else involved here.

When I previously replied to your COMMENT, I said the following:

"One way to implement the "retrieve the information from the registrar" could of course be using own timers. 
But, I don't think we should specify such behavior.

Also, in some cases the proxy might be co-located with the "home proxy", or some other network node, 
where the interface with the registrar already exists."

No changes were done based on the comment.

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

§5.3.1:

>This is a major comment, and one that has a sufficient impact on interop that I
>had a long debate with myself about whether it should be a DISCUSS. Please take
>it very seriously.
>
>  Otherwise, if the pn-provider SIP URI parameter identifies a type of
>  PNS that the proxy does not support, or if the REGISTER request does
>  not contain all additional information required for the specific type
>  of PNS, the proxy MUST either forward the request (e.g., if the proxy
>  knows that another proxy that will receive the REGISTER request
>  supports the type of PNS)...
>
>How would the proxy know this?

In the previous reply, I said "local configuration".

It has been clarified in the text, and the text in section 5.6.1.1 now says:

"If the proxy knows (by means of local configuration)"
>Features like suppressing PNS behavior when a "sip.pns" feature capability is
>present in the REGISTER imply that the various nodes in the network discover
>capabilities of their neighbors automatically (which is consistent with the way
>SIP does features), while this provision seems to require provisioned knowledge.
>This is going to be operationally very confusing.
>
>At the very least, the document needs to call out how this "knowledge" is
>obtained. In the more general sense, since a client cannot rely on the proxy
>supporting *any* kind of PNS, the use of 555 in the way specified here is at
>best an optimization -- and, since the configured information can conflict with
>actual reality, it's an optimization that can actually break things unless
>extreme care is exercised. (e.g., if the proxy is configured to "know" that the
>next proxy cannot provide push service, but this knowledge is wrong, then the
>network is unnecessarily broken.)
>
>My rather strong recommendation is to remove this code, and let the client rely
>on the lack of indication of support in the response indicate that the feature
>is not supported.

In my previous reply I said:

"I would like to keep the code, because there are cases where one wants the register to be rejected 
(rather than accepted, but without indication of supported PNS) if the PNS is not supported.

Also, there are already deployments of 555, so I'd prefer to keep it, as it doesn't break anything."

The 555 response code has been kept, and regarding the proxy knowing it was clarified that it is based on local configuration (see above).

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

§5.3.1:

>  o  if the proxy received a 'sip.pnsreg' media feature tag in the
>     REGISTER request, the proxy SHOULD include a 'sip.pnsreg' feature-
>     capability indicator with an indicator value bigger than 120 in
>     the response, unless the proxy always want to request push
>
>Nit: "...wants..."

Has been fixed.

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

§5.3.2:

>  If the contact of the REGISTER request does not match
>  the Request-URI of the SIP request to be forwarded, or if the contact
>  was not present in the REGISTER response, the proxy MUST reject the
>  SIP request with a 404 (Not Found) response.
>
>This seems to be a very strong requirement ("MUST") when, e.g., many or most
>networks may want to return a 480 instead of a 404. I think what you want to say
>is something like "...MUST reject the SIP request. Response codes of either
>404 (Not Found) or 480 (Temporarily Unavailable) are RECOMMENDED, but other
>appropriate codes may be used as well."

This has been addressed with the following text:

"It is RECOMMENDED that the proxy sends either a 404 (Not
 Found) response or a 480 (Temporarily Unavailable) response to the
 SIP request, but other response codes can be used as well."

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

§5.3.2:

>  The reason the proxy needs to wait for the REGISTER response before
>  forwarding the SIP request is to make sure that the REGISTER request
>  has been accepted by the registrar, and that the UA which initiated
>
>Nit: "...the UA that initiated..."

Has been fixed.

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

§5.3.2:

>  In case of non-2xx response to the REGISTER request, the proxy MUST
>  reject the SIP request with a 404 (Not Found) response.
>
>  If the push notification request fails (see PNS-specific
>  documentation for details), the proxy MUST reject the SIP request
>  with a 480 (Temporarily Unavailable) response.
>
>  If the proxy does not receive the REGISTER request from the UA within
>  a given time after the proxy has requested the push notification, the
>  proxy MUST reject the request with a 480 (Temporarily Unavailable)
>  response.  The time value is set based on local policy.
>
>As above, this seems way too restrictive in terms of mandating specific error
>codes. It may well be the case that a network would want to treat these
>situations identically from the perspective of the calling party.

Has been addressed (see above).

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

§5.3.2:

>  Otherwise the
>  proxy MUST reject the SIP request with a 480 (Temporarily
>  Unavailable) response.
>
>Same comment as above.

Has been addressed (see above).

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

§6.1.1:

>  When the UA sends in initial request for a dialog, or a 2xx response
>
>Nit: "...sends an initial request..."

Has been fixed.

>  purr' SIP URI parameter in the Contact header of the request or
>
>Nit: "...Contact header field..."

Has been fixed.

>  NOTE: As the 'pn-purr' SIP URI parameter only applies to a give
>  dialog, the UA needs to include a 'pn-purr' parameter in the Contact
>
>Nit: "...given dialog..."

Has been fixed.

>  dialog, the UA needs to include a 'pn-purr' parameter in the Contact
>  header of the request or response for each dialog in which the UA is
>
>Nit: "...Contact header field..."

Has been fixed.

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

§6.1.1:

>  The UA MUST include a parameter value identical to the the
>  last 'sip.pnspurr' feature-capability indicator that it received in a
>  REGISTER response.
>
>This is incredibly confusing, as the "sip.pnspurr" indicator has not been
>mentioned in the document so far. Please revise as something along the lines of:
>
>  The UA MUST include a parameter value identical to the the last
>  'sip.pnspurr' feature-capability indicator (see Section 6.2.1) that it
>  received in a REGISTER response.
>
>Alternately, reverse the order of sections 6.1 and 6.2 so that the PURR
>concept is properly introduced before protocol procedures are defined for it.

This has been addressed, by adding a reference to Section 6.2.1.

---------------------------------------------------------------------------
*
§6.1.1:

>  NOTE: As the 'pn-purr' SIP URI parameter only applies to a give
>  dialog, the UA needs to include a 'pn-purr' parameter in the Contact
>  header of the request or response for each dialog in which the UA is
>  willing to receive push notifications triggered by incoming mid-
>  dialog requests.
>
>Similar to the above, this is a very confusing introduction of the "pn-purr" URI
>parameter.

I realized this has been fixed in the wrong section. I will fix that by adding a reference to Section 6.2.1.

Note, though, that the first occurrence of 'pn-purr' SIP URI parameter is in the first paragraph of section 6.1.1, so I will add the reference there.

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

§6.2.2:

>  Contact header field with a PURR value that the proxy has generated
>  Section 6.2.2, the proxy MUST add a Record-Route header to the
>  request, to insert itself in the dialog route [RFC3261].
>
>This "Section 6.2.2" makes the sentence impossible to read. Is it intended to be
>in parentheses?

Has been fixed.

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

§6.2.3:

>  As described in Section 5.3.2, while waiting for the push
>  notification request to succeed, and the associated REGISTER request
>  to arrive from the SIP UA, the proxy needs to take into consideration
>  that the transaction associated with the NOTIFY request will
>  eventually time out at the sender of the request (UAC), and the
>  sender will consider the transaction a failure.
>
>I think this needs some discussion about the impact of the error codes selected
>by the proxy on the dialog and its usages. For example:
>
>* If the proxy sends a 404 to prevent a transaction timeout, it will destroy the
>  dialog and all of its usages
>
>* If the proxy sends a 480 to prevent a transaction timeout, it will destroy the
>  usage, but not other usages in the dialog (if any)
>
>* If the proxy sends a 504 to prevent a transaction timeout, it will keep the
>  dialog and the usage alive, and allow the client to re-try at a later time.
>  Simply allowing the transaction to time out will have the same effect, albeit
> with more message retransmissions.
>
> Pointing to RFC 5057 might be useful here.

This has been addressed. The text in Section 6.2.3 now says:

   "When a proxy sends an error response to a mid-dialog request (e.g.,    due to a transaction time out), the proxy SHOULD select a response    code that only impacts the transaction associated with the request    ([RFC5079])."

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

§8.7:

>    Parameter value characters that are not part of pvalue needs to be
>    escaped, as defined in RFC 3261.
>
>Nit: "...need to be escaped..."

Has been fixed.

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

§9:

>  When a new value is registered to the PNS Sub-registry, a reference
>  to a specification which describes the usage of the PNS associated
>
>Nit: "...specification that describes..."

Has been fixed.

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

§§10-12:

>Nit: It seems like these should all be subsections of section 9.

In my previous reply I said:

"The idea was that the PNS registrations are in separate main sections, as they could even be in a separate document."

No changes were done based on this comment.

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

§10:

>  The Topic consists of the Bundle ID, which uniquelly identifies an
>  appliciation, and a service value that identifies a service
>
>Nit: "uniquely"
>Nit: "application"

This has been fixed.

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

§10:

>  Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp.voip
>
>Please use an RFC 2026 domain for this example; e.g.:
>
>  Example: pn-param = DEF123GHIJ.com.example.yourexampleapp.voip

Has been fixed.

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

§11:

>  [RFC8292] defines a mechanism which allows a proxy to identity itself
>
> Nit: "...mechanism that allows..."

Has been fixed.

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

Regards,

Christer


--------------9D7DCED0AAB74BEBDD290DFC-- From nobody Fri Mar 1 13:56:14 2019 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 4106B128766 for ; Fri, 1 Mar 2019 13:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.291 X-Spam-Level: X-Spam-Status: No, score=-4.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=FWAmASFh; dkim=pass (1024-bit key) header.d=ericsson.com header.b=CzN9RH6l 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 9pi9p74pYZei for ; Fri, 1 Mar 2019 13:56:06 -0800 (PST) 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 86679130EBF for ; Fri, 1 Mar 2019 13:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551477363; x=1554069363; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tdaXdlNNjiZOurioRIxQ7zFdXhmk2JH73L8E6mB+uwM=; b=FWAmASFh/vuaqw9tqxHZFbIrMVuWQKfoOILvvqyBUfRd8ozFqesmMZWAY6tCmB+/ 5duyfuo5ged/OGLgrFl4OYYaeCrpu8UY6iPiUjt4Nds/BXtHrLBOGpwJRH4VcWTF YN3Us7Atp3WWo3X3Nk60lDuRs6MDo2gNqtF7TdA1hiY=; X-AuditID: c1b4fb2d-db5ff7000000062f-1f-5c79aa736ea6 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 83.41.01583.37AA97C5; Fri, 1 Mar 2019 22:56:03 +0100 (CET) Received: from ESESBMR502.ericsson.se (153.88.183.134) by ESESBMB502.ericsson.se (153.88.183.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Mar 2019 22:56:03 +0100 Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMR502.ericsson.se (153.88.183.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Mar 2019 22:56:03 +0100 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 1 Mar 2019 22:56:02 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tdaXdlNNjiZOurioRIxQ7zFdXhmk2JH73L8E6mB+uwM=; b=CzN9RH6lMcXyNIV7hfnGP1yYYR3XCMlKrEXw7oF6+84CxHEVmclcoQV708UT557+2VTeLfaje//cZ5aXpdzhidz7+E8EIDBoU2h57IOPsxMXeD/zZMbtOA2tyCfCuorewUyoErzMKK7CKAdwNIhF3Ydeoknm3KR2hDwwupwrPf0= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3355.eurprd07.prod.outlook.com (10.170.247.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.13; Fri, 1 Mar 2019 21:55:58 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae%3]) with mapi id 15.20.1686.011; Fri, 1 Mar 2019 21:55:58 +0000 From: Christer Holmberg To: Adam Roach , The IESG CC: "draft-ietf-sipcore-sip-push@ietf.org" , Brian Rosen , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-sipcore-sip-push-26: (with COMMENT) Thread-Index: AQHU0FJlSNJTji9dnkaJCVYOkLIdYKX3Ink4gAAteoCAAAIJAg== Date: Fri, 1 Mar 2019 21:55:58 +0000 Message-ID: References: <155146051337.6186.9467252084775433080.idtracker@ietfa.amsl.com> , <377b379d-3747-3748-694d-2c3fa621483b@nostrum.com> In-Reply-To: <377b379d-3747-3748-694d-2c3fa621483b@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.136.1.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 12806254-a2bc-4087-03a8-08d69e90b038 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3355; x-ms-traffictypediagnostic: HE1PR07MB3355: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIzMzU1OzIzOjJ4QUcrV3liTWp5eURHeHdUWFpzWVR1YUhl?= =?utf-8?B?ZXE3YUxFTEU1MHgrRVlabWFWZGtMT2JnaEg1empZM3FtSGtkZWkwWTMyL0s4?= =?utf-8?B?RnlBYlZKaERLRG9CZ0JNMDRySDNnME1KaXF1UDFyWDBFWHgwZ1JudHZ3RVFq?= =?utf-8?B?d3Rmc1FxMG9QRlVQOGx2UE5DYmpSUTcwTzFwMmhNejJVb3pPNFRDcHRoazkw?= =?utf-8?B?bkFNeWhReGxnQTgxOFVndndrNUk1M2o2YXVORldtQVRENkZpWnFtbFU5S1BC?= =?utf-8?B?MzJZZ1hZVnZVQUdYN3BDam0xVnJlY3BPbDZRaWxVa3dLZ2JkcU1zVE05dWtP?= =?utf-8?B?NlJkMXlodG53NGVPMCtYYXFwOUtDaUtpRkFmNU90b3lQUGpLUnhwczBZRG9W?= =?utf-8?B?aTYrR01nUExzSWJPcU1EZzBKczVUVmF1dzhNTUVkQko0MVBlZHdNRWRqUmRo?= =?utf-8?B?UmhWMitiT3IwOWVtVWcwQ0NnU2srTTZCbGEyREczN2dZU051aHdSVis1Nkoz?= =?utf-8?B?RlVNY2p4RGJSNlNKZjNlRDlNZ1plSi9KT0lLV09FQ2VGRVBIWThzK1d0MlU1?= =?utf-8?B?aWJMTWNRSlhqemlGbjk5MTVCQks4aVZOdGNNNVNEWUhVQlJsd2ZGU3djK0Nw?= =?utf-8?B?M2pESnh6VnZGQkl4akFRWjJzNVlneVArMVd4MFhlem1DSGx2Qm1wY1c1cjh2?= =?utf-8?B?MHV0anZOa2kxR0ZiN2w2V094eGRCVFBCbnJtL0xXOFFjS1NJdUdoaSt5djdU?= =?utf-8?B?UUt1Z1lsclRwTStJQ3pHb2lFVDhKY0dDaWNoOEpqWXduU0psdWxrMDVXWVZz?= =?utf-8?B?aFdNL2ZGZks1ZFRJVkIxVUFxVzY4UnYySmx2dnNXUVFjY25PcHFPNHY2SnJk?= =?utf-8?B?K3ZjbERVV2lFTjVPSjdIQVlkeUt1L1lOMlJrNm94Q3N5Z3IyMjhXZVpEQmtt?= =?utf-8?B?QXdUMDFnSUF1cEFZeWJtNDMvcXNHVjNHNmRpVlVFY0ZiQ1p5c3Z0Z21OcDdy?= =?utf-8?B?RXNMNmprNTlEQktoTnMxYWtiaXY5NTlRQ1BuK1V5aER0QXJ1b0lHMmpXdUxQ?= =?utf-8?B?c1hDVG9CRHAwM0Z3MlVaVzNkenZrVGJDLzVjbFNYL0NLd1Vjalhaalgrd0RQ?= =?utf-8?B?NzIyNG8ycnpZd3lSa1dKRjRhdVZqalA5aXE2SlcxZjRMbnpyZDhDb2RVZVZh?= =?utf-8?B?SHl2RnY5bVAxNU0vUVh4OWVwcSs2dHZ3NC9zcm1EQVl5SFE3WEJBaTZmdEVW?= =?utf-8?B?RGJnbWdpNWFEazRETkJhSk4yWUYyMFBSTkFvY0VpUVIzY1VpQWlZSE9tVDdL?= =?utf-8?B?ZnZCK3hvRWtlM0hvd3NIeXZ6WGRwR1VGNjB1TzRtOUtIV3kyN2NlbENOTVpF?= =?utf-8?B?SFRKaTN0L253R2ttRzdQbDRJVC9IWEdJTUJKN255dnpxa0NSZmRHeDJwYytS?= =?utf-8?B?a0lDT1RDa3ZSamRlWHF2NldKUzdPZmxRc2Nqa2xKQlBMZ3M3ejhoN0IxZjZw?= =?utf-8?B?RnFKSUJ4RnE3WjV0TkZZcUpDT3hhOG1wNUZjWFk5dE9UeUZUbzVodUNVYmE3?= =?utf-8?B?cmpFQmY2c09mcU1DU2NtcStTTXVNNVVOcS9VQ1pQcE1Uc3U3MDVxd0c0WlVj?= =?utf-8?B?bTMvUk5QV1RMSHZhWDJJQTY2aUpZeHlUN1V0K3pPRnUvemlJc0diL29UZnBQ?= =?utf-8?B?Tmc5a2EyTjZDc2wwaFFTMGwvd09vUnplZmhlc3prM29xb2FiSWh4Um5vc2dK?= =?utf-8?B?UlIvUzliK01tRkM5VVN4K3Z4dlM1NndFMG9PWE9Lamw5amJrVXpGdVFHZXRP?= =?utf-8?B?SHRsNWpHSXMzejRyZFMrdFFYMTF3KzJVTnN4WmdnQnBpR3BOL3YwWE45Zytq?= =?utf-8?B?ZnJDUzV4UEtQcXdZVlRnYm4wRVJQOW5URXJWZ3RsZlZvV0ZYRVFtYW1YRG1l?= =?utf-8?B?RTZMMlhwV3pORVBjcEtvWUUwWUtzV2dZUWl3TVFzK3loOEVTc1NwOUI2VUMy?= =?utf-8?Q?/uwf04?= x-microsoft-antispam-prvs: x-forefront-prvs: 09634B1196 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(39860400002)(136003)(366004)(50854003)(189003)(199004)(30864003)(5660300002)(14444005)(256004)(53936002)(19627405001)(2906002)(106356001)(99286004)(606006)(105586002)(86362001)(71190400001)(66066001)(25786009)(97736004)(4326008)(52536013)(6246003)(71200400001)(7696005)(76176011)(6116002)(6506007)(14454004)(44832011)(6306002)(54896002)(68736007)(81166006)(476003)(486006)(9686003)(33656002)(3846002)(102836004)(186003)(26005)(6346003)(478600001)(55016002)(53946003)(316002)(446003)(110136005)(8936002)(11346002)(54906003)(7736002)(966005)(6606003)(229853002)(53546011)(236005)(6436002)(81156014)(8676002)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3355; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7Qv7PPAB/1r1tLLg0XGCCDHXIiQ3Oiq2Rkqq5xDamJpvP4hltInw7ouxRFsrVGkZbSxtAK5VYcppr1YfQeAOpqddXK1f5dYnJc0soH5dyDCBlieTXRwR4u4FTOMF8AwsZ1RHT4GCWo1jiZqvD7TdEQQoYnV+luZStMyZ9Urj7kJly27Rjl80t2wU9V7KVuEe6IoYskEfuHQMKVsmNsfKyufG+cXr44ls1lwYaHfReb/ULNf1N7uxVaW/kgatOzB4e9fuk/IPmHbEQzZGvrJHxNYim2G6pYwkhEl2ib46/MlZKZ+RIFjvfotYroZTB9b6Gi4f+xbGKrYggA9EheHsIy51QM4kB71q0JisERJPYQsp2VlX8boHXaNff4bV1VENuppdynODHhaeJOev6gEqg6GDd3NqdAM0uRWqsRNhXW0= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3161189E5C9F82A14BBC873F93760HE1PR07MB3161eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 12806254-a2bc-4087-03a8-08d69e90b038 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2019 21:55:58.7533 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3355 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH++3ebVdp9HPTPFhmjigznVoio6dagUlC/We6sJHXt1N2zVpk iKmVc2G5fAzFNP8wlSzNLGdBI8tHpJnkg3D5yBBxvjCtVPJ6V/jf55zv9wvnHA5FiFv5TlSs KoVWq5QJUoEtWRzaxHgy1RqFd+6ATN6yUiGUfzcXCOQZ8zU8edHyXUKumy8n5AtL9QJ/QZD5 54owqLLyFy/I8HKMPEOE2R6OpBNiU2m119ELtjHfusvJ5CUzeSVzYgqlo6JuMgfZUIB9YfJO AS8H2VJi/BZBVqlRyBULCDLbnpL/i66hRj4bEeOHPOjoP8gKJM4jIHuk1Oq6x4Oh7BZrMYyg 936/IAdRlADLQbu6j03b40PQeaOdYD0E7kXQP5gvZAUJDoOi5XEhZwoHy6qOz3EgZJhf81gm 8S5o6CwkWBZhBYwXm62T9yB4/7ECsYINPgZDVTPrJoS3wmJH7XqYwI4wOFbG49bGUNnSRXDs ABOjq3yOXUBf12s9jTP0lGkRxyGgbciyZgcQzC6e4NgdfhvrrH0naPvUymcHAmyWwMLcjFWI B31bO2IvAXg7VD1O4zzNAsgbnER5SGbYMB/HSWDRj/AN64vaQXvxGGlYixN4L9Q1e3EWV9Br h4Ucu0FWSalwY/8BElYjB4ZmmMTo/QdktDr2IsMkqWQqOqUerT3Xm2d/PF+gmskAE8IUkm4W RRVqFGK+MpXRJJoQUITUXnQtca0lilRqrtLqpAj1pQSaMaFtFCl1FC2L7RRiHK1MoeNpOplW /1N5lI1TOkp2kdEdlwMtN8no8GkX8bgxOi5CMy/ZpPf70pfSfoTpu3W6aS53SvJqdk9osOXU O38XS36jR5Sridq5ZdRjtPDRydtxXjHG0p7uHWlPAp26p67rzmsG5ZbdHxQ/RG6JaSWfnwfr 8kQ+ZSH4nG+199lZh2lnv6/YxqchIEY2UntcSjIxSh93Qs0o/wLuIuBzWAMAAA== Archived-At: Subject: Re: [sipcore] Adam Roach's No Objection on draft-ietf-sipcore-sip-push-26: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:56:13 -0000 --_000_HE1PR07MB3161189E5C9F82A14BBC873F93760HE1PR07MB3161eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSwNCg0KPkhJISBJIGFwb2xvZ2l6ZSBpZiBpdCB3YXMgdW5jbGVhciBmcm9tIG15IHByZWFt YmxlLCBidXQgdGhlIG9yaWdpbmFsIGNvbW1lbnRzIHdlcmUgb25seQ0KPmluY2x1ZGVkIGJlY2F1 c2UgSSB3YW50ZWQgdGhlIGRvY3VtZW50IGJhbGxvdCB0byByZXRhaW4gdGhlbSBmb3IgaGlzdG9y aWNhbCBwdXJwb3Nlcy4gTm8NCj5yZXBseSB3YXMgbmVjZXNzYXJ5Lg0KDQpXZWxsLCB3aGVuIEkg d2VudCB0aHJvdWdoIHZlcnNpb24gLTI2IHRvIG1ha2Ugc3VyZSB5b3VyIGlzc3VlcyBoYWQgYmVl biBhZGRyZXNzZWQgSSBkaWQgZmluZCBhIGNvdXBsZSBvZiBtaW5vciBuaXRzIHRoYXQgSSBzdGls bCBuZWVkIHRvIGZpeCwgc28gaXQgd2FzIG5vdCB3YXN0ZWQgdGltZSDwn5iKDQoNClJlZ2FyZHMs DQoNCkNocmlzdGVyDQoNCg0KDQpPbiAzLzEvMTkgMTU6MzEsIENocmlzdGVyIEhvbG1iZXJnIHdy b3RlOg0KDQpIaSBBZGFtLA0KDQoNClRoYW5rIFlvdSENCg0KDQpZb3VyIGlzc3VlcyBoYXZlIGJl ZW4gYWRkcmVzc2VkLiBJbiB0aGlzIHJlcGx5IEkgbW9yZSBvciBsZXNzIGNvcHkvcGFzdGUgd2hh dCBJIHNhaWQgaW4gbXkgcHJldmlvdXMgcmVwbHkgdG8geW91ciByZXZpZXcsIGFuZCBnaXZlIHNv bWUgZXh0cmEgZGV0YWlscyBvbiBob3cgaXNzdWVzIHdlcmUgc29sdmVkLg0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KPkl0J3MgbmljZSB0aGF0IHRoaXMg ZG9jdW1lbnQgaGFzIGNvbnNpZGVyZWQgdGhlIGltcGFjdCBvZiBpbmJvdW5kIG1pZC1kaWFsb2cN Cj5tZXNzYWdlcyBpbiBsb25nLWxpdmVkIGRpYWxvZ3MuIEhvd2V2ZXIsIGl0IGFwcGVhcnMgdG8g aGF2ZSBhIG1ham9yIGhvbGUgaW4gaXQ6DQo+aGFuZGluZyBvZiBvdXRib3VuZCBtZXNzYWdlcyBm b3IgdGhlIHB1cnBvc2Ugb2YgbWFpbnRhaW5pbmcgc29mdC1zdGF0ZSBpbiB0aG9zZQ0KPmRpYWxv Z3MgaXNuJ3QgaGFuZGxlZCBjb3JyZWN0bHkuDQo+DQo+SW4gcGFydGljdWxhcjogbmV0d29ya3Mg dGhhdCBkZXBsb3kgdGhpcyBtZWNoYW5pc20gd2lsbCBjYXVzZSBTVUJTQ1JJQkUNCj5kaWFsb2dz IHRvIHRpbWUgb3V0IGFuZCBiZSBkZXN0cm95ZWQgd2hpbGUgdGhleSBhcmUgc3RpbGwgaW4gdXNl Lg0KPkFkZGl0aW9uYWxseSwgaWYgUkZDIDQwMjggKHNlc3Npb24gdGltZXJzKSBpcyBuZWdvdGlh dGVkLCB0aGVuIElOVklURSBkaWFsb2dzDQo+d2lsbCBzdWZmZXIgdGhlIHNhbWUgZmF0ZS4NCj4N Cj5JIGNhbiB0aGluayBvZiBhIGNvdXBsZSBvZiB3YXlzIGZvciB0aGVzZSBzaXR1YXRpb25zIHRv IGJlIGhhbmRsZWQsIGJ1dCB0aGV5DQo+bmVlZCBleHBsaWNpdCB0ZXh0IGluIHRoZSBkb2N1bWVu dC4NCj4NCj5PbmUgYXBwcm9hY2ggd291bGQgYmUgdG8gc3BlY2lmeSB0aGF0IHRoZSBVc2VyIEFn ZW50IHNlbGVjdHMgaXRzIHJlcXVlc3RlZA0KPiJFeHBpcmVzIiB2YWx1ZSBpbiBpdHMgcmVnaXN0 cmF0aW9uIHRvIGJlIHRoZSBzbWFsbGVzdCB2YWx1ZSBiZWZvcmUgaXRzIHNldCBvZg0KPnN1YnNj cmlwdGlvbnMgYW5kIHNlc3Npb24gdGltZXJzIG5lZWRzIHRvIGJlIHJlZnJlc2hlZC4gVGhpcyB3 b3VsZCBjYXVzZSBhIHB1c2gNCj5ub3RpZmljYXRpb24gdG8gaGFwcGVuIHRvIHByZXZlbnQgcmVn aXN0cmF0aW9uIHRpbWVvdXQsIGFuZCB0aGUgY2xpZW50IGNvdWxkDQo+cmVmcmVzaCB0aGUgb3Ro ZXIgc29mdCBzdGF0ZSBhdCB0aGF0IHRpbWUuIENvbXBsaWNhdGlvbnMgYXJpc2UgaWYgdGhlIHJl Z2lzdHJhcg0KPnJlc3BvbmRzIHdpdGggYSA0ODMgKEludGVydmFsIHRvbyBCcmllZiksIGFuZCB3 ZSdkIG5lZWQgdG8gZmluZCBhIHNvbHV0aW9uIGZvcg0KPnRoYXQuDQo+DQo+QW5vdGhlciBhcHBy b2FjaCB3b3VsZCBiZSBmb3IgdGhlIGNsaWVudHMgdG8gcmVmcmVzaCBhbGwgc29mdCBzdGF0ZSB3 aGVuZXZlcg0KPnRoZXkgc2VuZCBhIHJlZ2lzdHJhdGlvbiwgYW5kIHNldCB0aGUgdGltZW91dCBm b3IgdGhhdCBzb2Z0IHN0YXRlIHRvIGJlIGVxdWFsIHRvDQo+b3IgZ3JlYXRlciB0aGFuIHRoZSBy ZWdpc3RyYXRpb24gdGltZW91dC4gQSBjb21wbGljYXRpb24gY291bGQgYXJpc2UgaWYgdGhlDQo+ bm90aWZpZXIgb3IgdGhlIHBlZXIgaW4gYW4gaW52aXRlIGRpYWxvZyBzaG9ydGVucyB0aGUgcmVx dWVzdGVkIHRpbWUsIGFuZCB3ZSdkDQo+bmVlZCB0byBmaW5kIGEgc29sdXRpb24gZm9yIHRoYXQu DQo+DQo+QSB0aGlyZCBhcHByb2FjaCB3b3VsZCBiZSBnZXR0aW5nIHRoZSBwcm94eSBpbnZvbHZl ZCBpbiBzb21lIHdheSAtLSBlaXRoZXIgYnkNCj5yZXF1aXJpbmcgaXQgdG8gb2JzZXJ2ZSBzdWJz Y3JpcHRpb24gYW5kIHNlc3Npb24gdGltZXIgdGltZW91dHMgYW5kIHJlcXVpcmluZyBpdA0KPnRv IHNlbmQgcHVzaCBub3RpZmljYXRpb25zIHByaW9yIHRvIHRoZWlyIGV4cGlyYXRpb24sIG9yIGJ5 IGFuIGV4cGxpY2l0DQo+Y29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBVQSBhbmQgdGhlIHByb3h5 IHRoYXQgaW5kaWNhdGVzIHdoZW4gdGhlIG5leHQgcHVzaA0KPm5vdGlmaWNhdGlvbiBzaG91bGQg YmUgc2NoZWR1bGVkLiBJZiB0aGUgbGF0dGVyIGFwcHJvYWNoIGlzIHRha2VuLCBJIHdvdWxkDQo+ c3VnZ2VzdCB0aGF0IGl0IG5lZWRzIHRvIGJlIHRha2VuIGZvciBSRUdJU1RFUiBtZXNzYWdlcyBh cyB3ZWxsLg0KPg0KPkkgcmVhbGx5IGRvbid0IHRoaW5rIHRoaXMgbWVjaGFuaXNtIGlzIGZlYXNp Ymx5IGRlcGxveWFibGUgd2l0aG91dCBhIHNvbHV0aW9uIHRvDQo+dGhpcyBwcm9ibGVtLg0KDQpU aGlzIGhhcyBiZWVuIGFkZHJlc3NlZCwgYW5kIHRoZSB0ZXh0IGluIHNlY3Rpb24gNC4xLjEgbm93 IHNheXM6DQogIlRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBkZWZpbmUgYSBtZWNoYW5pc20g dG8gZXhwbGljaXRseSByZXF1ZXN0ICAgIHB1c2ggbm90aWZpY2F0aW9ucyBmcm9tIHRoZSBTSVAg bmV0d29yayBmb3IgdXNhZ2VzIG90aGVyIHRoYW4gICAgdHJpZ2dlcmluZyBiaW5kaW5nLXJlZnJl c2ggUkVHSVNURVIgcmVxdWVzdHMgKGUuZy4sIGZvciBzZW5kaW5nICAgIHBlcmlvZGljIHN1YnNj cmlwdGlvbi1yZWZyZXNoIFNVQlNDUklCRSByZXF1ZXN0cyBbUkZDNjY2NV0pLCBub3IgZG9lcyAg ICBpdCBkZXNjcmliZSBob3cgdG8gZGlzdGluZ3Vpc2ggcHVzaCBub3RpZmljYXRpb25zIGFzc29j aWF0ZWQgd2l0aCAgICBzdWNoIHVzYWdlcyBmcm9tIHRoZSBwdXNoIG5vdGlmaWNhdGlvbnMgdXNl ZCB0byB0cmlnZ2VyIGJpbmRpbmctICAgIHJlZnJlc2ggUkVHSVNURVIgcmVxdWVzdHMuICBJZiBh IFNJUCBVQSB3YW50cyB0byB1c2UgcHVzaCAgICBub3RpZmljYXRpb25zIGZvciBvdGhlciB1c2Fn ZXMsIHRoZSBVQSBjYW4gcGVyZm9ybSBhY3Rpb25zIGFzc29jaWF0ZWQgICAgd2l0aCBzdWNoIHVz YWdlcyAoaW4gYWRkaXRpb24gdG8gc2VuZGluZyBhIGJpbmRpbmctcmVmcmVzaCBSRUdJU1RFUiAg ICByZXF1ZXN0KSB3aGVuZXZlciBpdCByZWNlaXZlcyBhIHB1c2ggbm90aWZpY2F0aW9uIGJ5IHVz aW5nIHRoZSBzYW1lICAgIHJlZnJlc2ggaW50ZXJ2YWwgdGhhdCBpcyB1c2VkIGZvciB0aGUgYmlu ZGluZy1yZWZyZXNoZXMuIg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQrCpzQuMToNCg0KPiAg Rm9yIHByaXZhY3kgYW5kIHNlY3VyaXR5IHJlYXNvbnMsIHRoZSBVQSBNVVNUIE5PVCBpbmNsdWRl IHRoZSBTSVAgVVJJDQo+ICBwYXJhbWV0ZXJzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBpbiBu b24tUkVHSVNURVIgcmVxdWVzdCwgdG8NCj4gIHByZXZlbnQgdGhlIFBOUyBpbmZvcm1hdGlvbiBh c3NvY2lhdGVkIHdpdGggdGhlIFVBIGZyb20gcmVhY2hpbmcgdGhlDQo+ICByZW1vdGUgcGVlci4N Cj4NCj5UaGlzIHNlZW1zIHRvIGlnbm9yZSB0aGUgYXZhaWxhYmlsaXR5IG9mIENvbnRhY3QgVVJJ IHBhcmFtZXRlcnMgdmlhIFJGQyAzNjgwDQo+c3Vic2NyaXB0aW9ucy4gVGhpcyB3b3VsZCBzZWVt IHRvIGltcG9zZSBhIHJlcXVpcmVtZW50IG9uIFJlZ2lzdHJhcnMgdG8gc3RyaXANCj50aGlzIGlu Zm9ybWF0aW9uIGJlZm9yZSBtYWtpbmcgaXQgYXZhaWxhYmxlIHRvIGFueSBvdGhlciBwYXJ0eSAo d2hpY2gsIGluDQo+dHVybiwgcmVxdWlyZXMgdGhhdCB0aGUgc3lzdGVtIGhhdmUgZXhwbGljaXQg UmVnaXN0cmFyICphbmQqIFByb3h5IHN1cHBvcnQpLg0KPkFzIGZhciBhcyBJIGNhbiB0ZWxsLCB0 aGUgc3lzdGVtIHNvIGZhciBoYXMgbm90IHJlcXVpcmVkIGV4cGxpY2l0IHByb3h5IHN1cHBvcnQN Cj4oYW5kIHRoZXJlJ3MgY2VydGFpbmx5IG5vIG1lY2hhbmlzbSBidWlsdC1pbiB0aGF0IGVuc3Vy ZXMgdGhhdCBhIHByb3h5IGhhcyBhbnkNCj5zcGVjaWFsIGhhbmRsaW5nIHJlZ2FyZGluZyB0aGlz IG1lY2hhbmlzbSkuDQo+DQo+SWYgdGhlIFBOUyBpbmZvcm1hdGlvbiBpcyBzZW5zaXRpdmUsIGFu ZCBjYW5ub3QgYmUgYWxsb3dlZCB0byBsZWFrIG91dCB0bw0KPm90aGVyIHVzZXJzLCB0aGVuIHdl IG5lZWQgc29tZSB3YXkgdG8gZW5zdXJlIHRoZSByZWdpc3RyYXIgaGFzIHByb3ZpZGVkDQo+cG9z aXRpdmUgY29uZmlybWF0aW9uIHRoYXQgaXQgd2lsbCBub3QgZG8gc28gYmVmb3JlIGFsbG93aW5n IGl0IHRvIGNvbWUgaW50bw0KPnBvc3Nlc3Npb24gb2YgdGhlbS4NCg0KVGhpcyBoYXMgYmVlbiBh ZGRyZXNzZWQsIGFuZCB0aGUgdGV4dCBub3cgc2F5czoNCiAiRm9yIHByaXZhY3kgYW5kIHNlY3Vy aXR5IHJlYXNvbnMsIGEgVUEgTVVTVCBOT1QgaW5zZXJ0IHRoZSBTSVAgVVJJICAgIHBhcmFtZXRl cnMgKGV4Y2VwdCBmb3IgdGhlIHBuLXB1cnIgcGFyYW1ldGVyKSBkZWZpbmVkIGluIHRoaXMgICAg c3BlY2lmaWNhdGlvbiBpbiBub24tUkVHSVNURVIgcmVxdWVzdCBpbiBvcmRlciB0byBwcmV2ZW50 IHRoZSBQTlMgICAgaW5mb3JtYXRpb24gYXNzb2NpYXRlZCB3aXRoIHRoZSBVQSBmcm9tIHJlYWNo aW5nIHRoZSByZW1vdGUgcGVlci4gICAgRm9yIGV4YW1wbGUsIHRoZSBVQSBNVVNUIE5PVCBpbnNl cnQgdGhlIHBuLXByaWQgU0lQIFVSSSBwYXJhbWV0ZXIgaW4gICAgdGhlIENvbnRhY3QgaGVhZGVy IGZpZWxkIFVSSSBvZiBhbiBJTlZJVEUgcmVxdWVzdC4gIFJFR0lTVEVSIHJlcXVlc3RzICAgIHdp bGwgbm90IHJlYWNoIHRoZSByZW1vdGUgcGVlciwgYXMgdGhleSB3aWxsIGJlIHRlcm1pbmF0ZWQg YnkgdGhlICAgIHJlZ2lzdHJhciBvZiB0aGUgVUEuICBIb3dldmVyLCB0aGUgcmVnaXN0cmFyIE1V U1Qgc3RpbGwgZW5zdXJlIHRoYXQgICAgdGhlIHBhcmFtZXRlcnMgYXJlIG5vdCBzZW50IHRvIG90 aGVyIHVzZXJzLCBlLmcuLCB1c2luZyB0aGUgU0lQIGV2ZW50ICAgIHBhY2thZ2UgZm9yIHJlZ2lz dHJhdGlvbnMgbWVjaGFuaXNtIFtSRkMzNjgwXS4gIFNlZSBTZWN0aW9uIDEzIGZvciAgICBtb3Jl IGluZm9ybWF0aW9uLiINClNlY3Rpb24gMTMgKFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKSBjb250 YWlucyB0aGUgZm9sbG93aW5nIHRleHQ6DQoiT3BlcmF0b3JzIE1VU1QgZW5zdXJlIHRoYXQgdGhl IFBOUy1yZWxhdGVkIFNJUCBVUkkgcGFyYW1ldGVycyAgICBjb252ZXllZCBieSBhIHVzZXIgaW4g dGhlIENvbnRhY3QgVVJJIG9mIGEgUkVHSVNURVIgcmVxdWVzdCBhcmUgbm90ICAgIHNlbnQgdG8g b3RoZXIgdXNlcnMsIG9yIHRvIG5vbi10cnVzdGVkIG5ldHdvcmsgZW50aXRpZXMuICBPbmUgd2F5 IHRvICAgIGNvbnZleSBjb250YWN0IGluZm9ybWF0aW9uIGlzIGJ5IHVzaW5nIHRoZSB0aGUgU0lQ IGV2ZW50IHBhY2thZ2UgZm9yICAgIHJlZ2lzdHJhdGlvbnMgbWVjaGFuaXNtIFtSRkMzNjgwXS4g IFtSRkMzNjgwXSBkZWZpbmVzIGdlbmVyaWMgICAgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9y IHRoZSBTSVAgZXZlbnQgcGFja2FnZSBmb3IgcmVnaXN0cmF0aW9ucy4gICAgQXMgdGhlIFBOUy1y ZWxhdGVkIFNJUCBVUkkgcGFyYW1ldGVycyBjb252ZXllZCBpbiB0aGUgUkVHSVNURVIgICAgcmVx dWVzdCBjb250YWluIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiwgb3BlcmF0b3JzIHRoYXQgc3VwcG9y dCB0aGUgICAgZXZlbnQgcGFja2FnZSBNVVNUIGVuc3VyZSB0aGF0IGV2ZW50IHBhY2thZ2Ugc3Vi c2NyaXB0aW9ucyBhcmUgICAgcHJvcGVybHkgYXV0aGVudGljYXRlZCBhbmQgYXV0aG9yaXplZCwg YW5kIHRoYXQgdGhlIFNJUCBVUkkgICAgcGFyYW1ldGVycyBhcmUgbm90IGluc2VydGVkIGluIGV2 ZW50IG5vdGlmaWNhdGlvbnMgc2VudCB0byBvdGhlciAgICB1c2Vycywgb3IgdG8gbm9uLXRydXN0 ZWQgbmV0d29yayBlbnRpdGllcy4iDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQrCpzQuMjoNCg0K PiAgVGhlIFVBIGNhbiBkbyBzbyBieSBvbmx5IGluY2x1ZGluZyB0aGUgcG4tcHJvdmlkZXINCj4g IFNJUCBVUkkgcGFyYW1ldGVyIGluIHRoZSBTSVAgQ29udGFjdCBoZWFkZXIgZmllbGQgVVJJIG9m IHRoZSBSRUdJU1RFUg0KPiAgcmVxdWVzdCwgYnV0IHdpdGhvdXQgaW5jbHVkaW5nIHRoZSBwbi1w cmlkIFNJUCBVUkkgcGFyYW1ldGVyLg0KPg0KPlVubGVzcyBJJ20gbWlzdGFrZW4sIHRoaXMgaXMg YSBiYXJyaWVyIHRvIGludGVyb3BlcmF0aW9uLg0KPg0KPkl0J3Mgbm90IDEwMCUgY2xlYXIsIGJ1 dCBJIHN1c3BlY3QgdGhlIGludGVuZGVkIGltcGxpY2F0aW9uIGlzIHRoYXQgdGhlDQo+cG4tcHJv dmlkZXIgcGFyYW1ldGVyIGhlcmUgd2lsbCBjb250YWluIGEgc2luZ2xlIHZhbHVlPyBUaGUgc3lu dGF4IG9mIHRoZQ0KPnBhcmFtZXRlciBjZXJ0YWlubHkgc2VlbXMgdG8gaW1wbHkgdGhhdC4gVGhp cyBzZWVtcyB0byBiZSBhIHByZXR0eSBiaWcNCj5wcm9ibGVtLCBzaW5jZSBpdCBwcmVzdXBwb3Nl cyB0aGF0IHRoZSBjbGllbnQgd2lsbCBrbm93IHdoaWNoIFBOU2VzIHRoZSBQcm94eQ0KPnN1cHBv cnRzLiAgQ29uc2lkZXIsIGZvciBleGFtcGxlLCBhbiBpT1MgY2xpZW50IHRoYXQgY2FuIHVzZSBh bnkgb2YgUkZDIDgwMzAsDQo+RkNNLCBhbmQgQVBOIChjZiBodHRwczovL2ZpcmViYXNlLmdvb2ds ZS5jb20vZG9jcy9jbG91ZC1tZXNzYWdpbmcvaW9zL2NsaWVudCkuDQo+SWYgdGhlIGNsaWVudCBk b2Vzbid0IGtub3cgYSBwcmlvcmkgd2hhdCB0aGUgcHJveHkgc3VwcG9ydHMgKGFuZCB0aGlzIGVu dGlyZQ0KPnNlY3Rpb24gb25seSBtYWtlcyBzZW5zZSBpZiB0aGF0J3MgdHJ1ZSksIHRoZW4gaXQg d29uJ3Qga25vdyB3aGljaCBvZiB0aG9zZQ0KPnRocmVlIHNlcnZpY2VzIHRvIGluZGljYXRlIGlu IGl0cyBSRUdJU1RFUiByZXF1ZXN0LiBJZiBpdCBndWVzc2VzIHdyb25nLCB0aGlzDQo+bWVjaGFu aXNtIHNpbXBseSBmYWlscy4NCj4NCj5JIHRoaW5rIHlvdSBuZWVkIGEgZGlmZmVyZW50IGRpc2Nv dmVyeSBtZWNoYW5pc20gaGVyZSAtLSBlaXRoZXIgaGF2ZSBvbmUgdGhhdA0KPmhhcyB0aGUgY2xp ZW50IG9mZmVyaW5nIG11bHRpcGxlIFBOUyBwcm90b2NvbHMgYW5kIHRoZSBwcm94eSByZXNwb25k aW5nIHdpdGgNCj5vbmUsIG9yIGhhdmUgb25lIGluIHdoaWNoIHRoZSBwcm94eSBpbmRpY2F0ZXMg YWxsIG9mIGl0cyBzdXBwb3J0ZWQgc2VydmljZXMgaW4NCj5hIHJlc3BvbnNlLCBhbmQgdGhlIGNs aWVudCBjaG9vc2VzIG9uZSB0byB1c2UgaW4gaXRzIG5leHQgUkVHSVNURVIgbWVzc2FnZS4NCg0K VGhpcyBoYXMgYmVlbiBhZGRyZXNzZWQgaW4gc2VjdGlvbiA0LjEuNSAoUXVlcnkgTmV0d29yayBQ TlMgQ2FwYWJpbGl0aWVzKS4gVGhlIFVBIGNhbiBub3cNCmNob29zZSB0byBub3QgaW5jbHVkZSB0 aGUgcG4tcHJvdmlkZXIgcGFyYW1ldGVyLCBpbiB3aGljaCBjYXNlIHRoZSBuZXR3b3JrIHdpbGwg cmV0dXJuIGFsbA0KUE5TIHByb3RvY29scyBzdXBwb3J0ZWQuDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQo+RmlndXJlIDE6DQo+DQo+VGhpcyBkaWFncmFtIGluY2x1ZGVzIGJvdGggYSBsYWRkZXIg ZGlhZ3JhbSBhbmQgYW4gZXhhbXBsZSBSRUdJU1RFUiBtZXNzYWdlLg0KPldoaWxlIGJvdGggb2Yg dGhlc2UgYXJlIHVzZWZ1bCBhdCB0aGlzIHBvaW50IGluIHRoZSBkb2N1bWVudCwgbmVpdGhlciBv ZiB0aGVtIGlzDQo+YW4gIkFyY2hpdGVjdHVyZSwiIGFuZCB0aGV5J3JlIHJlYWxseSB0d28gZGlm ZmVyZW50IHRoaW5ncy4gSSBzdWdnZXN0IGJyZWFraW5nDQo+dGhpcyBpbnRvIHR3byBGaWd1cmVz LCBlbnRpdGxlZCAiVHlwaWNhbCBJbmZvcm1hdGlvbiBGbG93IiBhbmQgIkV4YW1wbGUgUkVHSVNU RVINCj5NZXNzYWdlIiAob3Igc2ltaWxhciksIHJlc3BlY3RpdmVseS4NCg0KVGhpcyBoYXMgYmVl biBhZGRyZXNzZWQgYXMgc3VnZ2VzdGVkIGluIFNlY3Rpb24gMSAoSW50cm9kdWN0aW9uKS4NCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoqDQrCpzQuMToNCg0KPiAgQXMgbG9uZyBhcyB0aGUgVUEgd2Fu dHMgdG8gcmVjZWl2ZSBwdXNoIG5vdGlmaWNhdGlvbnMgKHJlcXVlc3RlZCBieQ0KPiAgdGhlIHBy b3h5KSwgdGhlIFVBIE1VU1QgaW5jbHVkZSBhIHBuLXByb3ZpZGVyLCBwbi1wcmlkIGFuZCBhIHBu LXBhcmFtDQo+ICAoaWYgcmVxdWlyZWQgZm9yIHRoZSBzcGVjaWZpYyBQTlMgcHJvdmlkZXIpIFNJ UCBVUkkgcGFyYW1ldGVyIGluIGVhY2gNCj4gIGJpbmRpbmctcmVmcmVzaCBSRUdJU1RFUiByZXF1 ZXN0Lg0KPg0KPlBsZWFzZSBiZSBjbGVhciB0aGF0IHRoZXNlIHBhcmFtZXRlcnMgYXBwZWFyIGlu IHRoZSBDb250YWN0IFVSSS4NCg0KRXZlbnRob3VnaCB0aGUgdGV4dCBhYm92ZSBkb2VzIG5vIGxv bmdlciBleGlzdCwgaXQgaGFzIG5vdyBiZWVuIGdlbmVyYWxseSBjbGFyaWZpZWQgdGhhdCB0aGUg cGFyYW1ldGVycyBhcHBlYXIgaW4gdGhlIENvbnRhY3QgVVJJLg0KDQooSSBkaWQgbm90ZSBhIGJ1 ZyBpbiBzZWN0aW9uIDQuMS4yLiBJIHNheXMgIlVBIE1VU1QgaW5jbHVkZSIsIGJ1dCBpdCBzaGFs bCBiZSAiVUEgTVVTVCBOT1QgaW5jbHVkZSIpDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQrCpzUu MjoNCg0KPiAgSW4gb3JkZXIgdG8gcmVxdWVzdCBwdXNoIG5vdGlmaWNhdGlvbnMgdG93YXJkcyBh IFNJUCBVQSB0aGF0IHdpbGwNCj4gIHRyaWdnZXIgdGhlIFVBIHRvIHNlbmQgYmluZGluZy1yZWZy ZXNoIFNJUCBSRUdJU1RFUiByZXF1ZXN0cywgdGhlIFNJUA0KPiAgcHJveHkgbmVlZHMgdG8gaGF2 ZSBpbmZvcm1hdGlvbiBhYm91dCB3aGVuIGEgcmVnaXN0cmF0aW9uIHdpbGwNCj4gIGV4cGlyZS4g IFRoZSBwcm94eSBuZWVkcyB0byBiZSBhYmxlIHRvIHJldHJpZXZlIHRoZSBpbmZvcm1hdGlvbiBm cm9tDQo+ICB0aGUgcmVnaXN0cmFyIHVzaW5nIHNvbWUgbWVjaGFuaXNtLiAgU3VjaCBtZWNoYW5p c21zIGFyZSBvdXRzaWRlIHRoZQ0KPiAgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCwgYnV0IGNvdWxk IGJlIGltcGxlbWVudGVkIGUuZy4sIHVzaW5nIHRoZQ0KPiAgU0lQcmVnaXN0cmF0aW9uIGV2ZW50 IHBhY2thZ2UgbWVjaGFuaXNtIFtSRkMzNjgwXS4NCj4NCj5OaXQ6ICJTSVAgcmVnaXN0cmF0aW9u Ig0KDQpIYXMgYmVlbiBmaXhlZC4NCg0KPlRoaXMgbWVjaGFuaXNtIHNlZW1zIHRvIGJlIHByZWRp Y2F0ZWQgb24gYW4gYXJjaGl0ZWN0dXJlIGluIHdoaWNoIHRoZSBwcm94eSBtdXN0DQo+YmUgb24g dGhlIHRyYWZmaWMgcGF0aC4gQWx0aG91Z2ggaXQncyBwcm9ibGVtYXRpYyBmcm9tIGEgIndoYXQg cHJveGllcyBhcmUNCj5leHBlY3RlZCB0byBkbyIgcGVyc3BlY3RpdmUsIGl0IHNlZW1zIGxpa2Ug dGhlIHByb3h5IGNvdWxkIGdsZWFuIHRoaXMNCj5pbmZvcm1hdGlvbiBmcm9tIHRoZSAyMDAgcmVz cG9uc2UgdG8gdGhlIFJFR0lTVEVSIHJlcXVlc3QuIChJIG1lYW4sIHRoZSBwcm94eSBpcw0KPmFs cmVhZHkgcmVhZGluZyBwYXJhbWV0ZXJzIG91dCBvZiB0aGUgY29udGFjdCBoZWFkZXIgZmllbGQs IHNvIHRoZSBiZWhhdmlvciBvZg0KPmFjdGluZyBvbiByZWdpc3RyYXRpb24gaW5mb3JtYXRpb24g aXMgYWxyZWFkeSBhc3N1bWVkKS4gVGhlIHByb3h5IHdvdWxkLCBvZg0KPmNvdXJzZSwgbmVlZCB0 byBydW4gaXRzIG93biB0aW1lcnMsIGJ1dCB0aGF0IHNlZW1zIHRvIGJlIGEgcHJldHR5IG1pbm9y DQo+cmVxdWlyZW1lbnQsIGdpdmVuIGV2ZXJ5dGhpbmcgZWxzZSBpbnZvbHZlZCBoZXJlLg0KDQpX aGVuIEkgcHJldmlvdXNseSByZXBsaWVkIHRvIHlvdXIgQ09NTUVOVCwgSSBzYWlkIHRoZSBmb2xs b3dpbmc6DQoNCiJPbmUgd2F5IHRvIGltcGxlbWVudCB0aGUgInJldHJpZXZlIHRoZSBpbmZvcm1h dGlvbiBmcm9tIHRoZSByZWdpc3RyYXIiIGNvdWxkIG9mIGNvdXJzZSBiZSB1c2luZyBvd24gdGlt ZXJzLg0KQnV0LCBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBzcGVjaWZ5IHN1Y2ggYmVoYXZpb3Iu DQoNCkFsc28sIGluIHNvbWUgY2FzZXMgdGhlIHByb3h5IG1pZ2h0IGJlIGNvLWxvY2F0ZWQgd2l0 aCB0aGUgImhvbWUgcHJveHkiLCBvciBzb21lIG90aGVyIG5ldHdvcmsgbm9kZSwNCndoZXJlIHRo ZSBpbnRlcmZhY2Ugd2l0aCB0aGUgcmVnaXN0cmFyIGFscmVhZHkgZXhpc3RzLiINCg0KTm8gY2hh bmdlcyB3ZXJlIGRvbmUgYmFzZWQgb24gdGhlIGNvbW1lbnQuDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQrCpzUuMy4xOg0KDQo+VGhpcyBpcyBhIG1ham9yIGNvbW1lbnQsIGFuZCBvbmUgdGhhdCBo YXMgYSBzdWZmaWNpZW50IGltcGFjdCBvbiBpbnRlcm9wIHRoYXQgSQ0KPmhhZCBhIGxvbmcgZGVi YXRlIHdpdGggbXlzZWxmIGFib3V0IHdoZXRoZXIgaXQgc2hvdWxkIGJlIGEgRElTQ1VTUy4gUGxl YXNlIHRha2UNCj5pdCB2ZXJ5IHNlcmlvdXNseS4NCj4NCj4gIE90aGVyd2lzZSwgaWYgdGhlIHBu LXByb3ZpZGVyIFNJUCBVUkkgcGFyYW1ldGVyIGlkZW50aWZpZXMgYSB0eXBlIG9mDQo+ICBQTlMg dGhhdCB0aGUgcHJveHkgZG9lcyBub3Qgc3VwcG9ydCwgb3IgaWYgdGhlIFJFR0lTVEVSIHJlcXVl c3QgZG9lcw0KPiAgbm90IGNvbnRhaW4gYWxsIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gcmVxdWly ZWQgZm9yIHRoZSBzcGVjaWZpYyB0eXBlDQo+ICBvZiBQTlMsIHRoZSBwcm94eSBNVVNUIGVpdGhl ciBmb3J3YXJkIHRoZSByZXF1ZXN0IChlLmcuLCBpZiB0aGUgcHJveHkNCj4gIGtub3dzIHRoYXQg YW5vdGhlciBwcm94eSB0aGF0IHdpbGwgcmVjZWl2ZSB0aGUgUkVHSVNURVIgcmVxdWVzdA0KPiAg c3VwcG9ydHMgdGhlIHR5cGUgb2YgUE5TKS4uLg0KPg0KPkhvdyB3b3VsZCB0aGUgcHJveHkga25v dyB0aGlzPw0KDQpJbiB0aGUgcHJldmlvdXMgcmVwbHksIEkgc2FpZCAibG9jYWwgY29uZmlndXJh dGlvbiIuDQoNCkl0IGhhcyBiZWVuIGNsYXJpZmllZCBpbiB0aGUgdGV4dCwgYW5kIHRoZSB0ZXh0 IGluIHNlY3Rpb24gNS42LjEuMSBub3cgc2F5czoNCg0KIklmIHRoZSBwcm94eSBrbm93cyAoYnkg bWVhbnMgb2YgbG9jYWwgY29uZmlndXJhdGlvbikiDQo+RmVhdHVyZXMgbGlrZSBzdXBwcmVzc2lu ZyBQTlMgYmVoYXZpb3Igd2hlbiBhICJzaXAucG5zIiBmZWF0dXJlIGNhcGFiaWxpdHkgaXMNCj5w cmVzZW50IGluIHRoZSBSRUdJU1RFUiBpbXBseSB0aGF0IHRoZSB2YXJpb3VzIG5vZGVzIGluIHRo ZSBuZXR3b3JrIGRpc2NvdmVyDQo+Y2FwYWJpbGl0aWVzIG9mIHRoZWlyIG5laWdoYm9ycyBhdXRv bWF0aWNhbGx5ICh3aGljaCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIHdheQ0KPlNJUCBkb2VzIGZl YXR1cmVzKSwgd2hpbGUgdGhpcyBwcm92aXNpb24gc2VlbXMgdG8gcmVxdWlyZSBwcm92aXNpb25l ZCBrbm93bGVkZ2UuDQo+VGhpcyBpcyBnb2luZyB0byBiZSBvcGVyYXRpb25hbGx5IHZlcnkgY29u ZnVzaW5nLg0KPg0KPkF0IHRoZSB2ZXJ5IGxlYXN0LCB0aGUgZG9jdW1lbnQgbmVlZHMgdG8gY2Fs bCBvdXQgaG93IHRoaXMgImtub3dsZWRnZSIgaXMNCj5vYnRhaW5lZC4gSW4gdGhlIG1vcmUgZ2Vu ZXJhbCBzZW5zZSwgc2luY2UgYSBjbGllbnQgY2Fubm90IHJlbHkgb24gdGhlIHByb3h5DQo+c3Vw cG9ydGluZyAqYW55KiBraW5kIG9mIFBOUywgdGhlIHVzZSBvZiA1NTUgaW4gdGhlIHdheSBzcGVj aWZpZWQgaGVyZSBpcyBhdA0KPmJlc3QgYW4gb3B0aW1pemF0aW9uIC0tIGFuZCwgc2luY2UgdGhl IGNvbmZpZ3VyZWQgaW5mb3JtYXRpb24gY2FuIGNvbmZsaWN0IHdpdGgNCj5hY3R1YWwgcmVhbGl0 eSwgaXQncyBhbiBvcHRpbWl6YXRpb24gdGhhdCBjYW4gYWN0dWFsbHkgYnJlYWsgdGhpbmdzIHVu bGVzcw0KPmV4dHJlbWUgY2FyZSBpcyBleGVyY2lzZWQuIChlLmcuLCBpZiB0aGUgcHJveHkgaXMg Y29uZmlndXJlZCB0byAia25vdyIgdGhhdCB0aGUNCj5uZXh0IHByb3h5IGNhbm5vdCBwcm92aWRl IHB1c2ggc2VydmljZSwgYnV0IHRoaXMga25vd2xlZGdlIGlzIHdyb25nLCB0aGVuIHRoZQ0KPm5l dHdvcmsgaXMgdW5uZWNlc3NhcmlseSBicm9rZW4uKQ0KPg0KPk15IHJhdGhlciBzdHJvbmcgcmVj b21tZW5kYXRpb24gaXMgdG8gcmVtb3ZlIHRoaXMgY29kZSwgYW5kIGxldCB0aGUgY2xpZW50IHJl bHkNCj5vbiB0aGUgbGFjayBvZiBpbmRpY2F0aW9uIG9mIHN1cHBvcnQgaW4gdGhlIHJlc3BvbnNl IGluZGljYXRlIHRoYXQgdGhlIGZlYXR1cmUNCj5pcyBub3Qgc3VwcG9ydGVkLg0KDQpJbiBteSBw cmV2aW91cyByZXBseSBJIHNhaWQ6DQoNCiJJIHdvdWxkIGxpa2UgdG8ga2VlcCB0aGUgY29kZSwg YmVjYXVzZSB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgb25lIHdhbnRzIHRoZSByZWdpc3RlciB0byBi ZSByZWplY3RlZA0KKHJhdGhlciB0aGFuIGFjY2VwdGVkLCBidXQgd2l0aG91dCBpbmRpY2F0aW9u IG9mIHN1cHBvcnRlZCBQTlMpIGlmIHRoZSBQTlMgaXMgbm90IHN1cHBvcnRlZC4NCg0KQWxzbywg dGhlcmUgYXJlIGFscmVhZHkgZGVwbG95bWVudHMgb2YgNTU1LCBzbyBJJ2QgcHJlZmVyIHRvIGtl ZXAgaXQsIGFzIGl0IGRvZXNuJ3QgYnJlYWsgYW55dGhpbmcuIg0KDQpUaGUgNTU1IHJlc3BvbnNl IGNvZGUgaGFzIGJlZW4ga2VwdCwgYW5kIHJlZ2FyZGluZyB0aGUgcHJveHkga25vd2luZyBpdCB3 YXMgY2xhcmlmaWVkIHRoYXQgaXQgaXMgYmFzZWQgb24gbG9jYWwgY29uZmlndXJhdGlvbiAoc2Vl IGFib3ZlKS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCsKnNS4zLjE6DQoNCj4gIG8gIGlmIHRo ZSBwcm94eSByZWNlaXZlZCBhICdzaXAucG5zcmVnJyBtZWRpYSBmZWF0dXJlIHRhZyBpbiB0aGUN Cj4gICAgIFJFR0lTVEVSIHJlcXVlc3QsIHRoZSBwcm94eSBTSE9VTEQgaW5jbHVkZSBhICdzaXAu cG5zcmVnJyBmZWF0dXJlLQ0KPiAgICAgY2FwYWJpbGl0eSBpbmRpY2F0b3Igd2l0aCBhbiBpbmRp Y2F0b3IgdmFsdWUgYmlnZ2VyIHRoYW4gMTIwIGluDQo+ICAgICB0aGUgcmVzcG9uc2UsIHVubGVz cyB0aGUgcHJveHkgYWx3YXlzIHdhbnQgdG8gcmVxdWVzdCBwdXNoDQo+DQo+Tml0OiAiLi4ud2Fu dHMuLi4iDQoNCkhhcyBiZWVuIGZpeGVkLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0Kwqc1LjMu MjoNCg0KPiAgSWYgdGhlIGNvbnRhY3Qgb2YgdGhlIFJFR0lTVEVSIHJlcXVlc3QgZG9lcyBub3Qg bWF0Y2gNCj4gIHRoZSBSZXF1ZXN0LVVSSSBvZiB0aGUgU0lQIHJlcXVlc3QgdG8gYmUgZm9yd2Fy ZGVkLCBvciBpZiB0aGUgY29udGFjdA0KPiAgd2FzIG5vdCBwcmVzZW50IGluIHRoZSBSRUdJU1RF UiByZXNwb25zZSwgdGhlIHByb3h5IE1VU1QgcmVqZWN0IHRoZQ0KPiAgU0lQIHJlcXVlc3Qgd2l0 aCBhIDQwNCAoTm90IEZvdW5kKSByZXNwb25zZS4NCj4NCj5UaGlzIHNlZW1zIHRvIGJlIGEgdmVy eSBzdHJvbmcgcmVxdWlyZW1lbnQgKCJNVVNUIikgd2hlbiwgZS5nLiwgbWFueSBvciBtb3N0DQo+ bmV0d29ya3MgbWF5IHdhbnQgdG8gcmV0dXJuIGEgNDgwIGluc3RlYWQgb2YgYSA0MDQuIEkgdGhp bmsgd2hhdCB5b3Ugd2FudCB0byBzYXkNCj5pcyBzb21ldGhpbmcgbGlrZSAiLi4uTVVTVCByZWpl Y3QgdGhlIFNJUCByZXF1ZXN0LiBSZXNwb25zZSBjb2RlcyBvZiBlaXRoZXINCj40MDQgKE5vdCBG b3VuZCkgb3IgNDgwIChUZW1wb3JhcmlseSBVbmF2YWlsYWJsZSkgYXJlIFJFQ09NTUVOREVELCBi dXQgb3RoZXINCj5hcHByb3ByaWF0ZSBjb2RlcyBtYXkgYmUgdXNlZCBhcyB3ZWxsLiINCg0KVGhp cyBoYXMgYmVlbiBhZGRyZXNzZWQgd2l0aCB0aGUgZm9sbG93aW5nIHRleHQ6DQoNCiJJdCBpcyBS RUNPTU1FTkRFRCB0aGF0IHRoZSBwcm94eSBzZW5kcyBlaXRoZXIgYSA0MDQgKE5vdA0KIEZvdW5k KSByZXNwb25zZSBvciBhIDQ4MCAoVGVtcG9yYXJpbHkgVW5hdmFpbGFibGUpIHJlc3BvbnNlIHRv IHRoZQ0KIFNJUCByZXF1ZXN0LCBidXQgb3RoZXIgcmVzcG9uc2UgY29kZXMgY2FuIGJlIHVzZWQg YXMgd2VsbC4iDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQrCpzUuMy4yOg0KDQo+ICBUaGUgcmVh c29uIHRoZSBwcm94eSBuZWVkcyB0byB3YWl0IGZvciB0aGUgUkVHSVNURVIgcmVzcG9uc2UgYmVm b3JlDQo+ICBmb3J3YXJkaW5nIHRoZSBTSVAgcmVxdWVzdCBpcyB0byBtYWtlIHN1cmUgdGhhdCB0 aGUgUkVHSVNURVIgcmVxdWVzdA0KPiAgaGFzIGJlZW4gYWNjZXB0ZWQgYnkgdGhlIHJlZ2lzdHJh ciwgYW5kIHRoYXQgdGhlIFVBIHdoaWNoIGluaXRpYXRlZA0KPg0KPk5pdDogIi4uLnRoZSBVQSB0 aGF0IGluaXRpYXRlZC4uLiINCg0KSGFzIGJlZW4gZml4ZWQuDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQrCpzUuMy4yOg0KDQo+ICBJbiBjYXNlIG9mIG5vbi0yeHggcmVzcG9uc2UgdG8gdGhlIFJF R0lTVEVSIHJlcXVlc3QsIHRoZSBwcm94eSBNVVNUDQo+ICByZWplY3QgdGhlIFNJUCByZXF1ZXN0 IHdpdGggYSA0MDQgKE5vdCBGb3VuZCkgcmVzcG9uc2UuDQo+DQo+ICBJZiB0aGUgcHVzaCBub3Rp ZmljYXRpb24gcmVxdWVzdCBmYWlscyAoc2VlIFBOUy1zcGVjaWZpYw0KPiAgZG9jdW1lbnRhdGlv biBmb3IgZGV0YWlscyksIHRoZSBwcm94eSBNVVNUIHJlamVjdCB0aGUgU0lQIHJlcXVlc3QNCj4g IHdpdGggYSA0ODAgKFRlbXBvcmFyaWx5IFVuYXZhaWxhYmxlKSByZXNwb25zZS4NCj4NCj4gIElm IHRoZSBwcm94eSBkb2VzIG5vdCByZWNlaXZlIHRoZSBSRUdJU1RFUiByZXF1ZXN0IGZyb20gdGhl IFVBIHdpdGhpbg0KPiAgYSBnaXZlbiB0aW1lIGFmdGVyIHRoZSBwcm94eSBoYXMgcmVxdWVzdGVk IHRoZSBwdXNoIG5vdGlmaWNhdGlvbiwgdGhlDQo+ICBwcm94eSBNVVNUIHJlamVjdCB0aGUgcmVx dWVzdCB3aXRoIGEgNDgwIChUZW1wb3JhcmlseSBVbmF2YWlsYWJsZSkNCj4gIHJlc3BvbnNlLiAg VGhlIHRpbWUgdmFsdWUgaXMgc2V0IGJhc2VkIG9uIGxvY2FsIHBvbGljeS4NCj4NCj5BcyBhYm92 ZSwgdGhpcyBzZWVtcyB3YXkgdG9vIHJlc3RyaWN0aXZlIGluIHRlcm1zIG9mIG1hbmRhdGluZyBz cGVjaWZpYyBlcnJvcg0KPmNvZGVzLiBJdCBtYXkgd2VsbCBiZSB0aGUgY2FzZSB0aGF0IGEgbmV0 d29yayB3b3VsZCB3YW50IHRvIHRyZWF0IHRoZXNlDQo+c2l0dWF0aW9ucyBpZGVudGljYWxseSBm cm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgY2FsbGluZyBwYXJ0eS4NCg0KSGFzIGJlZW4gYWRk cmVzc2VkIChzZWUgYWJvdmUpLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0Kwqc1LjMuMjoNCg0K PiAgT3RoZXJ3aXNlIHRoZQ0KPiAgcHJveHkgTVVTVCByZWplY3QgdGhlIFNJUCByZXF1ZXN0IHdp dGggYSA0ODAgKFRlbXBvcmFyaWx5DQo+ICBVbmF2YWlsYWJsZSkgcmVzcG9uc2UuDQo+DQo+U2Ft ZSBjb21tZW50IGFzIGFib3ZlLg0KDQpIYXMgYmVlbiBhZGRyZXNzZWQgKHNlZSBhYm92ZSkuDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQrCpzYuMS4xOg0KDQo+ICBXaGVuIHRoZSBVQSBzZW5kcyBp biBpbml0aWFsIHJlcXVlc3QgZm9yIGEgZGlhbG9nLCBvciBhIDJ4eCByZXNwb25zZQ0KPg0KPk5p dDogIi4uLnNlbmRzIGFuIGluaXRpYWwgcmVxdWVzdC4uLiINCg0KSGFzIGJlZW4gZml4ZWQuDQoN Cj4gIHB1cnInIFNJUCBVUkkgcGFyYW1ldGVyIGluIHRoZSBDb250YWN0IGhlYWRlciBvZiB0aGUg cmVxdWVzdCBvcg0KPg0KPk5pdDogIi4uLkNvbnRhY3QgaGVhZGVyIGZpZWxkLi4uIg0KDQpIYXMg YmVlbiBmaXhlZC4NCg0KPiAgTk9URTogQXMgdGhlICdwbi1wdXJyJyBTSVAgVVJJIHBhcmFtZXRl ciBvbmx5IGFwcGxpZXMgdG8gYSBnaXZlDQo+ICBkaWFsb2csIHRoZSBVQSBuZWVkcyB0byBpbmNs dWRlIGEgJ3BuLXB1cnInIHBhcmFtZXRlciBpbiB0aGUgQ29udGFjdA0KPg0KPk5pdDogIi4uLmdp dmVuIGRpYWxvZy4uLiINCg0KSGFzIGJlZW4gZml4ZWQuDQoNCj4gIGRpYWxvZywgdGhlIFVBIG5l ZWRzIHRvIGluY2x1ZGUgYSAncG4tcHVycicgcGFyYW1ldGVyIGluIHRoZSBDb250YWN0DQo+ICBo ZWFkZXIgb2YgdGhlIHJlcXVlc3Qgb3IgcmVzcG9uc2UgZm9yIGVhY2ggZGlhbG9nIGluIHdoaWNo IHRoZSBVQSBpcw0KPg0KPk5pdDogIi4uLkNvbnRhY3QgaGVhZGVyIGZpZWxkLi4uIg0KDQpIYXMg YmVlbiBmaXhlZC4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCsKnNi4xLjE6DQoNCj4gIFRoZSBV QSBNVVNUIGluY2x1ZGUgYSBwYXJhbWV0ZXIgdmFsdWUgaWRlbnRpY2FsIHRvIHRoZSB0aGUNCj4g IGxhc3QgJ3NpcC5wbnNwdXJyJyBmZWF0dXJlLWNhcGFiaWxpdHkgaW5kaWNhdG9yIHRoYXQgaXQg cmVjZWl2ZWQgaW4gYQ0KPiAgUkVHSVNURVIgcmVzcG9uc2UuDQo+DQo+VGhpcyBpcyBpbmNyZWRp Ymx5IGNvbmZ1c2luZywgYXMgdGhlICJzaXAucG5zcHVyciIgaW5kaWNhdG9yIGhhcyBub3QgYmVl bg0KPm1lbnRpb25lZCBpbiB0aGUgZG9jdW1lbnQgc28gZmFyLiBQbGVhc2UgcmV2aXNlIGFzIHNv bWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2Y6DQo+DQo+ICBUaGUgVUEgTVVTVCBpbmNsdWRlIGEg cGFyYW1ldGVyIHZhbHVlIGlkZW50aWNhbCB0byB0aGUgdGhlIGxhc3QNCj4gICdzaXAucG5zcHVy cicgZmVhdHVyZS1jYXBhYmlsaXR5IGluZGljYXRvciAoc2VlIFNlY3Rpb24gNi4yLjEpIHRoYXQg aXQNCj4gIHJlY2VpdmVkIGluIGEgUkVHSVNURVIgcmVzcG9uc2UuDQo+DQo+QWx0ZXJuYXRlbHks IHJldmVyc2UgdGhlIG9yZGVyIG9mIHNlY3Rpb25zIDYuMSBhbmQgNi4yIHNvIHRoYXQgdGhlIFBV UlINCj5jb25jZXB0IGlzIHByb3Blcmx5IGludHJvZHVjZWQgYmVmb3JlIHByb3RvY29sIHByb2Nl ZHVyZXMgYXJlIGRlZmluZWQgZm9yIGl0Lg0KDQpUaGlzIGhhcyBiZWVuIGFkZHJlc3NlZCwgYnkg YWRkaW5nIGEgcmVmZXJlbmNlIHRvIFNlY3Rpb24gNi4yLjEuDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KKg0Kwqc2LjEuMToNCg0KPiAgTk9URTogQXMgdGhlICdwbi1wdXJyJyBTSVAgVVJJIHBhcmFt ZXRlciBvbmx5IGFwcGxpZXMgdG8gYSBnaXZlDQo+ICBkaWFsb2csIHRoZSBVQSBuZWVkcyB0byBp bmNsdWRlIGEgJ3BuLXB1cnInIHBhcmFtZXRlciBpbiB0aGUgQ29udGFjdA0KPiAgaGVhZGVyIG9m IHRoZSByZXF1ZXN0IG9yIHJlc3BvbnNlIGZvciBlYWNoIGRpYWxvZyBpbiB3aGljaCB0aGUgVUEg aXMNCj4gIHdpbGxpbmcgdG8gcmVjZWl2ZSBwdXNoIG5vdGlmaWNhdGlvbnMgdHJpZ2dlcmVkIGJ5 IGluY29taW5nIG1pZC0NCj4gIGRpYWxvZyByZXF1ZXN0cy4NCj4NCj5TaW1pbGFyIHRvIHRoZSBh Ym92ZSwgdGhpcyBpcyBhIHZlcnkgY29uZnVzaW5nIGludHJvZHVjdGlvbiBvZiB0aGUgInBuLXB1 cnIiIFVSSQ0KPnBhcmFtZXRlci4NCg0KSSByZWFsaXplZCB0aGlzIGhhcyBiZWVuIGZpeGVkIGlu IHRoZSB3cm9uZyBzZWN0aW9uLiBJIHdpbGwgZml4IHRoYXQgYnkgYWRkaW5nIGEgcmVmZXJlbmNl IHRvIFNlY3Rpb24gNi4yLjEuDQoNCk5vdGUsIHRob3VnaCwgdGhhdCB0aGUgZmlyc3Qgb2NjdXJy ZW5jZSBvZiAncG4tcHVycicgU0lQIFVSSSBwYXJhbWV0ZXIgaXMgaW4gdGhlIGZpcnN0IHBhcmFn cmFwaCBvZiBzZWN0aW9uIDYuMS4xLCBzbyBJIHdpbGwgYWRkIHRoZSByZWZlcmVuY2UgdGhlcmUu DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQrCpzYuMi4yOg0KDQo+ICBDb250YWN0IGhlYWRlciBm aWVsZCB3aXRoIGEgUFVSUiB2YWx1ZSB0aGF0IHRoZSBwcm94eSBoYXMgZ2VuZXJhdGVkDQo+ICBT ZWN0aW9uIDYuMi4yLCB0aGUgcHJveHkgTVVTVCBhZGQgYSBSZWNvcmQtUm91dGUgaGVhZGVyIHRv IHRoZQ0KPiAgcmVxdWVzdCwgdG8gaW5zZXJ0IGl0c2VsZiBpbiB0aGUgZGlhbG9nIHJvdXRlIFtS RkMzMjYxXS4NCj4NCj5UaGlzICJTZWN0aW9uIDYuMi4yIiBtYWtlcyB0aGUgc2VudGVuY2UgaW1w b3NzaWJsZSB0byByZWFkLiBJcyBpdCBpbnRlbmRlZCB0byBiZQ0KPmluIHBhcmVudGhlc2VzPw0K DQpIYXMgYmVlbiBmaXhlZC4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCsKnNi4yLjM6DQoNCj4g IEFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMy4yLCB3aGlsZSB3YWl0aW5nIGZvciB0aGUgcHVz aA0KPiAgbm90aWZpY2F0aW9uIHJlcXVlc3QgdG8gc3VjY2VlZCwgYW5kIHRoZSBhc3NvY2lhdGVk IFJFR0lTVEVSIHJlcXVlc3QNCj4gIHRvIGFycml2ZSBmcm9tIHRoZSBTSVAgVUEsIHRoZSBwcm94 eSBuZWVkcyB0byB0YWtlIGludG8gY29uc2lkZXJhdGlvbg0KPiAgdGhhdCB0aGUgdHJhbnNhY3Rp b24gYXNzb2NpYXRlZCB3aXRoIHRoZSBOT1RJRlkgcmVxdWVzdCB3aWxsDQo+ICBldmVudHVhbGx5 IHRpbWUgb3V0IGF0IHRoZSBzZW5kZXIgb2YgdGhlIHJlcXVlc3QgKFVBQyksIGFuZCB0aGUNCj4g IHNlbmRlciB3aWxsIGNvbnNpZGVyIHRoZSB0cmFuc2FjdGlvbiBhIGZhaWx1cmUuDQo+DQo+SSB0 aGluayB0aGlzIG5lZWRzIHNvbWUgZGlzY3Vzc2lvbiBhYm91dCB0aGUgaW1wYWN0IG9mIHRoZSBl cnJvciBjb2RlcyBzZWxlY3RlZA0KPmJ5IHRoZSBwcm94eSBvbiB0aGUgZGlhbG9nIGFuZCBpdHMg dXNhZ2VzLiBGb3IgZXhhbXBsZToNCj4NCj4qIElmIHRoZSBwcm94eSBzZW5kcyBhIDQwNCB0byBw cmV2ZW50IGEgdHJhbnNhY3Rpb24gdGltZW91dCwgaXQgd2lsbCBkZXN0cm95IHRoZQ0KPiAgZGlh bG9nIGFuZCBhbGwgb2YgaXRzIHVzYWdlcw0KPg0KPiogSWYgdGhlIHByb3h5IHNlbmRzIGEgNDgw IHRvIHByZXZlbnQgYSB0cmFuc2FjdGlvbiB0aW1lb3V0LCBpdCB3aWxsIGRlc3Ryb3kgdGhlDQo+ ICB1c2FnZSwgYnV0IG5vdCBvdGhlciB1c2FnZXMgaW4gdGhlIGRpYWxvZyAoaWYgYW55KQ0KPg0K PiogSWYgdGhlIHByb3h5IHNlbmRzIGEgNTA0IHRvIHByZXZlbnQgYSB0cmFuc2FjdGlvbiB0aW1l b3V0LCBpdCB3aWxsIGtlZXAgdGhlDQo+ICBkaWFsb2cgYW5kIHRoZSB1c2FnZSBhbGl2ZSwgYW5k IGFsbG93IHRoZSBjbGllbnQgdG8gcmUtdHJ5IGF0IGEgbGF0ZXIgdGltZS4NCj4gIFNpbXBseSBh bGxvd2luZyB0aGUgdHJhbnNhY3Rpb24gdG8gdGltZSBvdXQgd2lsbCBoYXZlIHRoZSBzYW1lIGVm ZmVjdCwgYWxiZWl0DQo+IHdpdGggbW9yZSBtZXNzYWdlIHJldHJhbnNtaXNzaW9ucy4NCj4NCj4g UG9pbnRpbmcgdG8gUkZDIDUwNTcgbWlnaHQgYmUgdXNlZnVsIGhlcmUuDQoNClRoaXMgaGFzIGJl ZW4gYWRkcmVzc2VkLiBUaGUgdGV4dCBpbiBTZWN0aW9uIDYuMi4zIG5vdyBzYXlzOg0KDQogICAi V2hlbiBhIHByb3h5IHNlbmRzIGFuIGVycm9yIHJlc3BvbnNlIHRvIGEgbWlkLWRpYWxvZyByZXF1 ZXN0IChlLmcuLCAgICBkdWUgdG8gYSB0cmFuc2FjdGlvbiB0aW1lIG91dCksIHRoZSBwcm94eSBT SE9VTEQgc2VsZWN0IGEgcmVzcG9uc2UgICAgY29kZSB0aGF0IG9ubHkgaW1wYWN0cyB0aGUgdHJh bnNhY3Rpb24gYXNzb2NpYXRlZCB3aXRoIHRoZSByZXF1ZXN0ICAgIChbUkZDNTA3OV0pLiINCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCsKnOC43Og0KDQo+ICAgIFBhcmFtZXRlciB2YWx1ZSBjaGFy YWN0ZXJzIHRoYXQgYXJlIG5vdCBwYXJ0IG9mIHB2YWx1ZSBuZWVkcyB0byBiZQ0KPiAgICBlc2Nh cGVkLCBhcyBkZWZpbmVkIGluIFJGQyAzMjYxLg0KPg0KPk5pdDogIi4uLm5lZWQgdG8gYmUgZXNj YXBlZC4uLiINCg0KSGFzIGJlZW4gZml4ZWQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQrCpzk6 DQoNCj4gIFdoZW4gYSBuZXcgdmFsdWUgaXMgcmVnaXN0ZXJlZCB0byB0aGUgUE5TIFN1Yi1yZWdp c3RyeSwgYSByZWZlcmVuY2UNCj4gIHRvIGEgc3BlY2lmaWNhdGlvbiB3aGljaCBkZXNjcmliZXMg dGhlIHVzYWdlIG9mIHRoZSBQTlMgYXNzb2NpYXRlZA0KPg0KPk5pdDogIi4uLnNwZWNpZmljYXRp b24gdGhhdCBkZXNjcmliZXMuLi4iDQoNCkhhcyBiZWVuIGZpeGVkLg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KwqfCpzEwLTEyOg0KDQo+Tml0OiBJdCBzZWVtcyBsaWtlIHRoZXNlIHNob3VsZCBh bGwgYmUgc3Vic2VjdGlvbnMgb2Ygc2VjdGlvbiA5Lg0KDQpJbiBteSBwcmV2aW91cyByZXBseSBJ IHNhaWQ6DQoNCiJUaGUgaWRlYSB3YXMgdGhhdCB0aGUgUE5TIHJlZ2lzdHJhdGlvbnMgYXJlIGlu IHNlcGFyYXRlIG1haW4gc2VjdGlvbnMsIGFzIHRoZXkgY291bGQgZXZlbiBiZSBpbiBhIHNlcGFy YXRlIGRvY3VtZW50LiINCg0KTm8gY2hhbmdlcyB3ZXJlIGRvbmUgYmFzZWQgb24gdGhpcyBjb21t ZW50Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KwqcxMDoNCg0KPiAgVGhlIFRvcGljIGNvbnNp c3RzIG9mIHRoZSBCdW5kbGUgSUQsIHdoaWNoIHVuaXF1ZWxseSBpZGVudGlmaWVzIGFuDQo+ICBh cHBsaWNpYXRpb24sIGFuZCBhIHNlcnZpY2UgdmFsdWUgdGhhdCBpZGVudGlmaWVzIGEgc2Vydmlj ZQ0KPg0KPk5pdDogInVuaXF1ZWx5Ig0KPk5pdDogImFwcGxpY2F0aW9uIg0KDQpUaGlzIGhhcyBi ZWVuIGZpeGVkLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KwqcxMDoNCg0KPiAgRXhhbXBsZTog cG4tcGFyYW0gPSBERUYxMjNHSElKLmNvbS55b3VyY29tcGFueS55b3VyZXhhbXBsZWFwcC52b2lw DQo+DQo+UGxlYXNlIHVzZSBhbiBSRkMgMjAyNiBkb21haW4gZm9yIHRoaXMgZXhhbXBsZTsgZS5n LjoNCj4NCj4gIEV4YW1wbGU6IHBuLXBhcmFtID0gREVGMTIzR0hJSi5jb20uZXhhbXBsZS55b3Vy ZXhhbXBsZWFwcC52b2lwDQoNCkhhcyBiZWVuIGZpeGVkLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KwqcxMToNCg0KPiAgW1JGQzgyOTJdIGRlZmluZXMgYSBtZWNoYW5pc20gd2hpY2ggYWxsb3dz IGEgcHJveHkgdG8gaWRlbnRpdHkgaXRzZWxmDQo+DQo+IE5pdDogIi4uLm1lY2hhbmlzbSB0aGF0 IGFsbG93cy4uLiINCg0KSGFzIGJlZW4gZml4ZWQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg== --_000_HE1PR07MB3161189E5C9F82A14BBC873F93760HE1PR07MB3161eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPjwhLS0gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDt9IC0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZh dWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1p bHk6Q2FsaWJyaSxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsiIGRpcj0ibHRyIj4NCjxkaXYgaWQ9ImRp dnRhZ2RlZmF1bHR3cmFwcGVyIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IENhbGlicmksSGVsdmV0aWNhLHNhbnMtc2VyaWYsJnF1b3Q7RW1vamlGb250JnF1b3Q7LCZx dW90O0FwcGxlIENvbG9yIEVtb2ppJnF1b3Q7LCZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LE5v dG9Db2xvckVtb2ppLCZxdW90O1NlZ29lIFVJIFN5bWJvbCZxdW90OywmcXVvdDtBbmRyb2lkIEVt b2ppJnF1b3Q7LEVtb2ppU3ltYm9sczsgZm9udC1zaXplOiAxMnB0OyIgZGlyPSJsdHIiPg0KPHAg c3R5bGU9Im1hcmdpbi10b3A6MDsgbWFyZ2luLWJvdHRvbTowIj48YnI+DQo8L3A+DQpIaSw8L2Rp dj4NCjxkaXYgaWQ9ImRpdnRhZ2RlZmF1bHR3cmFwcGVyIiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksSGVsdmV0aWNhLHNhbnMtc2VyaWYsJnF1b3Q7RW1v amlGb250JnF1b3Q7LCZxdW90O0FwcGxlIENvbG9yIEVtb2ppJnF1b3Q7LCZxdW90O1NlZ29lIFVJ IEVtb2ppJnF1b3Q7LE5vdG9Db2xvckVtb2ppLCZxdW90O1NlZ29lIFVJIFN5bWJvbCZxdW90Oywm cXVvdDtBbmRyb2lkIEVtb2ppJnF1b3Q7LEVtb2ppU3ltYm9sczsgZm9udC1zaXplOiAxMnB0OyIg ZGlyPSJsdHIiPg0KPGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKSI+DQo8ZGl2IGlkPSJkaXZS cGx5RndkTXNnIiBkaXI9Imx0ciI+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiNGRkZGRkYiPg0KPGRpdiBjbGFzcz0ieF9tb3otY2l0ZS1w cmVmaXgiPiZndDtISSEgSSBhcG9sb2dpemUgaWYgaXQgd2FzIHVuY2xlYXIgZnJvbSBteSBwcmVh bWJsZSwgYnV0IHRoZSBvcmlnaW5hbCBjb21tZW50cyB3ZXJlIG9ubHkmbmJzcDs8L2Rpdj4NCjxk aXYgY2xhc3M9InhfbW96LWNpdGUtcHJlZml4Ij4mZ3Q7aW5jbHVkZWQgYmVjYXVzZSBJIHdhbnRl ZCB0aGUgZG9jdW1lbnQgYmFsbG90IHRvIHJldGFpbiB0aGVtIGZvciBoaXN0b3JpY2FsIHB1cnBv c2VzLiBObyZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9tb3otY2l0ZS1wcmVmaXgiPiZndDty ZXBseSB3YXMgbmVjZXNzYXJ5LjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9tb3otY2l0ZS1wcmVmaXgi Pjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9tb3otY2l0ZS1wcmVmaXgiPldlbGwsIHdoZW4g SSB3ZW50IHRocm91Z2ggdmVyc2lvbiAtMjYgdG8gbWFrZSBzdXJlIHlvdXIgaXNzdWVzIGhhZCBi ZWVuIGFkZHJlc3NlZCBJIGRpZCBmaW5kIGEgY291cGxlIG9mIG1pbm9yIG5pdHMgdGhhdCBJIHN0 aWxsIG5lZWQgdG8gZml4LCBzbyBpdCB3YXMgbm90IHdhc3RlZCB0aW1lDQo8c3Bhbj7wn5iKPC9z cGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9tb3otY2l0ZS1wcmVmaXgiPjxicj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0ieF9tb3otY2l0ZS1wcmVmaXgiPlJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNz PSJ4X21vei1jaXRlLXByZWZpeCI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X21vei1jaXRl LXByZWZpeCI+Q2hyaXN0ZXI8L2Rpdj4NCjxkaXYgY2xhc3M9InhfbW96LWNpdGUtcHJlZml4Ij4m bmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9InhfbW96LWNpdGUtcHJlZml4Ij48YnI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9InhfbW96LWNpdGUtcHJlZml4Ij48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 InhfbW96LWNpdGUtcHJlZml4Ij48L2Rpdj4NCjxkaXYgY2xhc3M9InhfbW96LWNpdGUtcHJlZml4 Ij5PbiAzLzEvMTkgMTU6MzEsIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOjxicj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGlkPSJ4X2RpdnRhZ2RlZmF1bHR3cmFwcGVy IiBzdHlsZT0iIiBkaXI9Imx0ciI+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowOyBtYXJnaW4tYm90 dG9tOjAiPkhpIEFkYW0sPC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDsgbWFyZ2luLWJvdHRv bTowIj48YnI+DQo8L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowOyBtYXJnaW4tYm90dG9tOjAi PlRoYW5rIFlvdSE8L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowOyBtYXJnaW4tYm90dG9tOjAi Pjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7IG1hcmdpbi1ib3R0b206MCI+WW91 ciBpc3N1ZXMgaGF2ZSBiZWVuIGFkZHJlc3NlZC4gSW4gdGhpcyByZXBseSBJIG1vcmUgb3IgbGVz cyBjb3B5L3Bhc3RlIHdoYXQgSSBzYWlkIGluIG15IHByZXZpb3VzIHJlcGx5IHRvIHlvdXIgcmV2 aWV3LCBhbmQgZ2l2ZSBzb21lIGV4dHJhIGRldGFpbHMgb24gaG93IGlzc3VlcyB3ZXJlIHNvbHZl ZC48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowOyBtYXJnaW4tYm90dG9tOjAiPjxicj4NCjwv cD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7IG1hcmdpbi1ib3R0b206MCI+PGZvbnQgc2l6ZT0i MiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPC9zcGFu PjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApIj4NCjxkaXYgY2xhc3M9 InhfQm9keUZyYWdtZW50Ij48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx cHQiPg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPkNPTU1FTlQ6PGJyPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPiZndDtJdCdzIG5p Y2UgdGhhdCB0aGlzIGRvY3VtZW50IGhhcyBjb25zaWRlcmVkIHRoZSBpbXBhY3Qgb2YgaW5ib3Vu ZCBtaWQtZGlhbG9nPGJyPg0KJmd0O21lc3NhZ2VzIGluIGxvbmctbGl2ZWQgZGlhbG9ncy4gSG93 ZXZlciwgaXQgYXBwZWFycyB0byBoYXZlIGEgbWFqb3IgaG9sZSBpbiBpdDo8YnI+DQomZ3Q7aGFu ZGluZyBvZiBvdXRib3VuZCBtZXNzYWdlcyBmb3IgdGhlIHB1cnBvc2Ugb2YgbWFpbnRhaW5pbmcg c29mdC1zdGF0ZSBpbiB0aG9zZTxicj4NCiZndDtkaWFsb2dzIGlzbid0IGhhbmRsZWQgY29ycmVj dGx5Ljxicj4NCiZndDs8YnI+DQomZ3Q7SW4gcGFydGljdWxhcjogbmV0d29ya3MgdGhhdCBkZXBs b3kgdGhpcyBtZWNoYW5pc20gd2lsbCBjYXVzZSBTVUJTQ1JJQkU8YnI+DQomZ3Q7ZGlhbG9ncyB0 byB0aW1lIG91dCBhbmQgYmUgZGVzdHJveWVkIHdoaWxlIHRoZXkgYXJlIHN0aWxsIGluIHVzZS48 YnI+DQomZ3Q7QWRkaXRpb25hbGx5LCBpZiBSRkMgNDAyOCAoc2Vzc2lvbiB0aW1lcnMpIGlzIG5l Z290aWF0ZWQsIHRoZW4gSU5WSVRFIGRpYWxvZ3M8YnI+DQomZ3Q7d2lsbCBzdWZmZXIgdGhlIHNh bWUgZmF0ZS48YnI+DQomZ3Q7PGJyPg0KJmd0O0kgY2FuIHRoaW5rIG9mIGEgY291cGxlIG9mIHdh eXMgZm9yIHRoZXNlIHNpdHVhdGlvbnMgdG8gYmUgaGFuZGxlZCwgYnV0IHRoZXk8YnI+DQomZ3Q7 bmVlZCBleHBsaWNpdCB0ZXh0IGluIHRoZSBkb2N1bWVudC48YnI+DQomZ3Q7PGJyPg0KJmd0O09u ZSBhcHByb2FjaCB3b3VsZCBiZSB0byBzcGVjaWZ5IHRoYXQgdGhlIFVzZXIgQWdlbnQgc2VsZWN0 cyBpdHMgcmVxdWVzdGVkPGJyPg0KJmd0OyZxdW90O0V4cGlyZXMmcXVvdDsgdmFsdWUgaW4gaXRz IHJlZ2lzdHJhdGlvbiB0byBiZSB0aGUgc21hbGxlc3QgdmFsdWUgYmVmb3JlIGl0cyBzZXQgb2Y8 YnI+DQomZ3Q7c3Vic2NyaXB0aW9ucyBhbmQgc2Vzc2lvbiB0aW1lcnMgbmVlZHMgdG8gYmUgcmVm cmVzaGVkLiBUaGlzIHdvdWxkIGNhdXNlIGEgcHVzaDxicj4NCiZndDtub3RpZmljYXRpb24gdG8g aGFwcGVuIHRvIHByZXZlbnQgcmVnaXN0cmF0aW9uIHRpbWVvdXQsIGFuZCB0aGUgY2xpZW50IGNv dWxkPGJyPg0KJmd0O3JlZnJlc2ggdGhlIG90aGVyIHNvZnQgc3RhdGUgYXQgdGhhdCB0aW1lLiBD b21wbGljYXRpb25zIGFyaXNlIGlmIHRoZSByZWdpc3RyYXI8YnI+DQomZ3Q7cmVzcG9uZHMgd2l0 aCBhIDQ4MyAoSW50ZXJ2YWwgdG9vIEJyaWVmKSwgYW5kIHdlJ2QgbmVlZCB0byBmaW5kIGEgc29s dXRpb24gZm9yPGJyPg0KJmd0O3RoYXQuPGJyPg0KJmd0Ozxicj4NCiZndDtBbm90aGVyIGFwcHJv YWNoIHdvdWxkIGJlIGZvciB0aGUgY2xpZW50cyB0byByZWZyZXNoIGFsbCBzb2Z0IHN0YXRlIHdo ZW5ldmVyPGJyPg0KJmd0O3RoZXkgc2VuZCBhIHJlZ2lzdHJhdGlvbiwgYW5kIHNldCB0aGUgdGlt ZW91dCBmb3IgdGhhdCBzb2Z0IHN0YXRlIHRvIGJlIGVxdWFsIHRvPGJyPg0KJmd0O29yIGdyZWF0 ZXIgdGhhbiB0aGUgcmVnaXN0cmF0aW9uIHRpbWVvdXQuIEEgY29tcGxpY2F0aW9uIGNvdWxkIGFy aXNlIGlmIHRoZTxicj4NCiZndDtub3RpZmllciBvciB0aGUgcGVlciBpbiBhbiBpbnZpdGUgZGlh bG9nIHNob3J0ZW5zIHRoZSByZXF1ZXN0ZWQgdGltZSwgYW5kIHdlJ2Q8YnI+DQomZ3Q7bmVlZCB0 byBmaW5kIGEgc29sdXRpb24gZm9yIHRoYXQuPGJyPg0KJmd0Ozxicj4NCiZndDtBIHRoaXJkIGFw cHJvYWNoIHdvdWxkIGJlIGdldHRpbmcgdGhlIHByb3h5IGludm9sdmVkIGluIHNvbWUgd2F5IC0t IGVpdGhlciBieTxicj4NCiZndDtyZXF1aXJpbmcgaXQgdG8gb2JzZXJ2ZSBzdWJzY3JpcHRpb24g YW5kIHNlc3Npb24gdGltZXIgdGltZW91dHMgYW5kIHJlcXVpcmluZyBpdDxicj4NCiZndDt0byBz ZW5kIHB1c2ggbm90aWZpY2F0aW9ucyBwcmlvciB0byB0aGVpciBleHBpcmF0aW9uLCBvciBieSBh biBleHBsaWNpdDxicj4NCiZndDtjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIFVBIGFuZCB0aGUg cHJveHkgdGhhdCBpbmRpY2F0ZXMgd2hlbiB0aGUgbmV4dCBwdXNoPGJyPg0KJmd0O25vdGlmaWNh dGlvbiBzaG91bGQgYmUgc2NoZWR1bGVkLiBJZiB0aGUgbGF0dGVyIGFwcHJvYWNoIGlzIHRha2Vu LCBJIHdvdWxkPGJyPg0KJmd0O3N1Z2dlc3QgdGhhdCBpdCBuZWVkcyB0byBiZSB0YWtlbiBmb3Ig UkVHSVNURVIgbWVzc2FnZXMgYXMgd2VsbC48YnI+DQomZ3Q7PGJyPg0KJmd0O0kgcmVhbGx5IGRv bid0IHRoaW5rIHRoaXMgbWVjaGFuaXNtIGlzIGZlYXNpYmx5IGRlcGxveWFibGUgd2l0aG91dCBh IHNvbHV0aW9uIHRvPGJyPg0KJmd0O3RoaXMgcHJvYmxlbS48L2Rpdj4NCjxkaXYgY2xhc3M9Inhf UGxhaW5UZXh0Ij48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij5UaGlzIGhh cyBiZWVuIGFkZHJlc3NlZCwgYW5kIHRoZSB0ZXh0IGluIHNlY3Rpb24gNC4xLjEgbm93IHNheXM6 PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImRpc3Bs YXk6aW5saW5lIWltcG9ydGFudDsgZmxvYXQ6bm9uZTsgYmFja2dyb3VuZC1jb2xvcjp0cmFuc3Bh cmVudDsgY29sb3I6cmdiKDAsMCwwKTsgZm9udC1mYW1pbHk6Q29uc29sYXM7IGZvbnQtc2l6ZTox My4zM3B4OyBmb250LXN0eWxlOm5vcm1hbDsgZm9udC12YXJpYW50Om5vcm1hbDsgZm9udC13ZWln aHQ6NDAwOyBsZXR0ZXItc3BhY2luZzpub3JtYWw7IG9ycGhhbnM6MjsgdGV4dC1hbGlnbjpsZWZ0 OyB0ZXh0LWRlY29yYXRpb246bm9uZTsgdGV4dC1pbmRlbnQ6MHB4OyB0ZXh0LXRyYW5zZm9ybTpu b25lOyB3aGl0ZS1zcGFjZTpwcmUtd3JhcDsgd29yZC1zcGFjaW5nOjBweDsgd29yZC13cmFwOmJy ZWFrLXdvcmQiPg0KPGRpdj4mbmJzcDsmcXVvdDtUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3Qg ZGVmaW5lIGEgbWVjaGFuaXNtIHRvIGV4cGxpY2l0bHkgcmVxdWVzdCAmbmJzcDsmbmJzcDsgcHVz aCBub3RpZmljYXRpb25zIGZyb20gdGhlIFNJUCBuZXR3b3JrIGZvciB1c2FnZXMgb3RoZXIgdGhh biAmbmJzcDsmbmJzcDsgdHJpZ2dlcmluZyBiaW5kaW5nLXJlZnJlc2ggUkVHSVNURVIgcmVxdWVz dHMgKGUuZy4sIGZvciBzZW5kaW5nICZuYnNwOyZuYnNwOyBwZXJpb2RpYyBzdWJzY3JpcHRpb24t cmVmcmVzaCBTVUJTQ1JJQkUgcmVxdWVzdHMNCiBbUkZDNjY2NV0pLCBub3IgZG9lcyAmbmJzcDsm bmJzcDsgaXQgZGVzY3JpYmUgaG93IHRvIGRpc3Rpbmd1aXNoIHB1c2ggbm90aWZpY2F0aW9ucyBh c3NvY2lhdGVkIHdpdGggJm5ic3A7Jm5ic3A7IHN1Y2ggdXNhZ2VzIGZyb20gdGhlIHB1c2ggbm90 aWZpY2F0aW9ucyB1c2VkIHRvIHRyaWdnZXIgYmluZGluZy0gJm5ic3A7Jm5ic3A7IHJlZnJlc2gg UkVHSVNURVIgcmVxdWVzdHMuJm5ic3A7IElmIGEgU0lQIFVBIHdhbnRzIHRvIHVzZSBwdXNoICZu YnNwOyZuYnNwOyBub3RpZmljYXRpb25zIGZvciBvdGhlciB1c2FnZXMsIHRoZQ0KIFVBIGNhbiBw ZXJmb3JtIGFjdGlvbnMgYXNzb2NpYXRlZCAmbmJzcDsmbmJzcDsgd2l0aCBzdWNoIHVzYWdlcyAo aW4gYWRkaXRpb24gdG8gc2VuZGluZyBhIGJpbmRpbmctcmVmcmVzaCBSRUdJU1RFUiAmbmJzcDsm bmJzcDsgcmVxdWVzdCkgd2hlbmV2ZXIgaXQgcmVjZWl2ZXMgYSBwdXNoIG5vdGlmaWNhdGlvbiBi eSB1c2luZyB0aGUgc2FtZSAmbmJzcDsmbmJzcDsgcmVmcmVzaCBpbnRlcnZhbCB0aGF0IGlzIHVz ZWQgZm9yIHRoZSBiaW5kaW5nLXJlZnJlc2hlcy4mcXVvdDs8L2Rpdj4NCjwvc3Bhbj48YnI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 YnI+DQo8YnI+DQrCpzQuMTo8YnI+DQo8YnI+DQomZ3Q7Jm5ic3A7IEZvciBwcml2YWN5IGFuZCBz ZWN1cml0eSByZWFzb25zLCB0aGUgVUEgTVVTVCBOT1QgaW5jbHVkZSB0aGUgU0lQIFVSSTxicj4N CiZndDsmbmJzcDsgcGFyYW1ldGVycyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgaW4gbm9uLVJF R0lTVEVSIHJlcXVlc3QsIHRvPGJyPg0KJmd0OyZuYnNwOyBwcmV2ZW50IHRoZSBQTlMgaW5mb3Jt YXRpb24gYXNzb2NpYXRlZCB3aXRoIHRoZSBVQSBmcm9tIHJlYWNoaW5nIHRoZTxicj4NCiZndDsm bmJzcDsgcmVtb3RlIHBlZXIuPGJyPg0KJmd0Ozxicj4NCiZndDtUaGlzIHNlZW1zIHRvIGlnbm9y ZSB0aGUgYXZhaWxhYmlsaXR5IG9mIENvbnRhY3QgVVJJIHBhcmFtZXRlcnMgdmlhIFJGQyAzNjgw PGJyPg0KJmd0O3N1YnNjcmlwdGlvbnMuIFRoaXMgd291bGQgc2VlbSB0byBpbXBvc2UgYSByZXF1 aXJlbWVudCBvbiBSZWdpc3RyYXJzIHRvIHN0cmlwPGJyPg0KJmd0O3RoaXMgaW5mb3JtYXRpb24g YmVmb3JlIG1ha2luZyBpdCBhdmFpbGFibGUgdG8gYW55IG90aGVyIHBhcnR5ICh3aGljaCwgaW48 YnI+DQomZ3Q7dHVybiwgcmVxdWlyZXMgdGhhdCB0aGUgc3lzdGVtIGhhdmUgZXhwbGljaXQgUmVn aXN0cmFyICphbmQqIFByb3h5IHN1cHBvcnQpLjxicj4NCiZndDtBcyBmYXIgYXMgSSBjYW4gdGVs bCwgdGhlIHN5c3RlbSBzbyBmYXIgaGFzIG5vdCByZXF1aXJlZCBleHBsaWNpdCBwcm94eSBzdXBw b3J0PGJyPg0KJmd0OyhhbmQgdGhlcmUncyBjZXJ0YWlubHkgbm8gbWVjaGFuaXNtIGJ1aWx0LWlu IHRoYXQgZW5zdXJlcyB0aGF0IGEgcHJveHkgaGFzIGFueTxicj4NCiZndDtzcGVjaWFsIGhhbmRs aW5nIHJlZ2FyZGluZyB0aGlzIG1lY2hhbmlzbSkuPGJyPg0KJmd0Ozxicj4NCiZndDtJZiB0aGUg UE5TIGluZm9ybWF0aW9uIGlzIHNlbnNpdGl2ZSwgYW5kIGNhbm5vdCBiZSBhbGxvd2VkIHRvIGxl YWsgb3V0IHRvPGJyPg0KJmd0O290aGVyIHVzZXJzLCB0aGVuIHdlIG5lZWQgc29tZSB3YXkgdG8g ZW5zdXJlIHRoZSByZWdpc3RyYXIgaGFzIHByb3ZpZGVkPGJyPg0KJmd0O3Bvc2l0aXZlIGNvbmZp cm1hdGlvbiB0aGF0IGl0IHdpbGwgbm90IGRvIHNvIGJlZm9yZSBhbGxvd2luZyBpdCB0byBjb21l IGludG88YnI+DQomZ3Q7cG9zc2Vzc2lvbiBvZiB0aGVtLjxicj4NCjxicj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0ieF9QbGFpblRleHQiPg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiIHN0eWxlPSIi PlRoaXMgaGFzIGJlZW4gYWRkcmVzc2VkLCBhbmQgdGhlIHRleHQgbm93IHNheXM6PGJyPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImRpc3Bs YXk6aW5saW5lIWltcG9ydGFudDsgZmxvYXQ6bm9uZTsgYmFja2dyb3VuZC1jb2xvcjp0cmFuc3Bh cmVudDsgY29sb3I6cmdiKDAsMCwwKTsgZm9udC1mYW1pbHk6Q29uc29sYXM7IGZvbnQtc2l6ZTox My4zM3B4OyBmb250LXN0eWxlOm5vcm1hbDsgZm9udC12YXJpYW50Om5vcm1hbDsgZm9udC13ZWln aHQ6NDAwOyBsZXR0ZXItc3BhY2luZzpub3JtYWw7IG9ycGhhbnM6MjsgdGV4dC1hbGlnbjpsZWZ0 OyB0ZXh0LWRlY29yYXRpb246bm9uZTsgdGV4dC1pbmRlbnQ6MHB4OyB0ZXh0LXRyYW5zZm9ybTpu b25lOyB3aGl0ZS1zcGFjZTpwcmUtd3JhcDsgd29yZC1zcGFjaW5nOjBweDsgd29yZC13cmFwOmJy ZWFrLXdvcmQiPg0KPGRpdj4mbmJzcDsmcXVvdDtGb3IgcHJpdmFjeSBhbmQgc2VjdXJpdHkgcmVh c29ucywgYSBVQSBNVVNUIE5PVCBpbnNlcnQgdGhlIFNJUCBVUkkgJm5ic3A7Jm5ic3A7IHBhcmFt ZXRlcnMgKGV4Y2VwdCBmb3IgdGhlIHBuLXB1cnIgcGFyYW1ldGVyKSBkZWZpbmVkIGluIHRoaXMg Jm5ic3A7Jm5ic3A7IHNwZWNpZmljYXRpb24gaW4gbm9uLVJFR0lTVEVSIHJlcXVlc3QgaW4gb3Jk ZXIgdG8gcHJldmVudCB0aGUgUE5TICZuYnNwOyZuYnNwOyBpbmZvcm1hdGlvbiBhc3NvY2lhdGVk IHdpdGggdGhlIFVBIGZyb20gcmVhY2hpbmcNCiB0aGUgcmVtb3RlIHBlZXIuICZuYnNwOyZuYnNw OyBGb3IgZXhhbXBsZSwgdGhlIFVBIE1VU1QgTk9UIGluc2VydCB0aGUgcG4tcHJpZCBTSVAgVVJJ IHBhcmFtZXRlciBpbiAmbmJzcDsmbmJzcDsgdGhlIENvbnRhY3QgaGVhZGVyIGZpZWxkIFVSSSBv ZiBhbiBJTlZJVEUgcmVxdWVzdC4mbmJzcDsgUkVHSVNURVIgcmVxdWVzdHMgJm5ic3A7Jm5ic3A7 IHdpbGwgbm90IHJlYWNoIHRoZSByZW1vdGUgcGVlciwgYXMgdGhleSB3aWxsIGJlIHRlcm1pbmF0 ZWQgYnkgdGhlICZuYnNwOyZuYnNwOyByZWdpc3RyYXIgb2YgdGhlIFVBLiZuYnNwOw0KIEhvd2V2 ZXIsIHRoZSByZWdpc3RyYXIgTVVTVCBzdGlsbCBlbnN1cmUgdGhhdCAmbmJzcDsmbmJzcDsgdGhl IHBhcmFtZXRlcnMgYXJlIG5vdCBzZW50IHRvIG90aGVyIHVzZXJzLCBlLmcuLCB1c2luZyB0aGUg U0lQIGV2ZW50ICZuYnNwOyZuYnNwOyBwYWNrYWdlIGZvciByZWdpc3RyYXRpb25zIG1lY2hhbmlz bSBbUkZDMzY4MF0uJm5ic3A7IFNlZSBTZWN0aW9uIDEzIGZvciAmbmJzcDsmbmJzcDsgbW9yZSBp bmZvcm1hdGlvbi4mcXVvdDs8L2Rpdj4NClNlY3Rpb24gMTMgKFNlY3VyaXR5IENvbnNpZGVyYXRp b25zKSBjb250YWlucyB0aGUgZm9sbG93aW5nIHRleHQ6IDxzcGFuIHN0eWxlPSJkaXNwbGF5Omlu bGluZSFpbXBvcnRhbnQ7IGZsb2F0Om5vbmU7IGJhY2tncm91bmQtY29sb3I6dHJhbnNwYXJlbnQ7 IGNvbG9yOnJnYigwLDAsMCk7IGZvbnQtZmFtaWx5OkNvbnNvbGFzOyBmb250LXNpemU6MTMuMzNw eDsgZm9udC1zdHlsZTpub3JtYWw7IGZvbnQtdmFyaWFudDpub3JtYWw7IGZvbnQtd2VpZ2h0OjQw MDsgbGV0dGVyLXNwYWNpbmc6bm9ybWFsOyBvcnBoYW5zOjI7IHRleHQtYWxpZ246bGVmdDsgdGV4 dC1kZWNvcmF0aW9uOm5vbmU7IHRleHQtaW5kZW50OjBweDsgdGV4dC10cmFuc2Zvcm06bm9uZTsg d2hpdGUtc3BhY2U6cHJlLXdyYXA7IHdvcmQtc3BhY2luZzowcHg7IHdvcmQtd3JhcDpicmVhay13 b3JkIj4NCjxkaXY+JnF1b3Q7T3BlcmF0b3JzIE1VU1QgZW5zdXJlIHRoYXQgdGhlIFBOUy1yZWxh dGVkIFNJUCBVUkkgcGFyYW1ldGVycyAmbmJzcDsmbmJzcDsgY29udmV5ZWQgYnkgYSB1c2VyIGlu IHRoZSBDb250YWN0IFVSSSBvZiBhIFJFR0lTVEVSIHJlcXVlc3QgYXJlIG5vdCAmbmJzcDsmbmJz cDsgc2VudCB0byBvdGhlciB1c2Vycywgb3IgdG8gbm9uLXRydXN0ZWQgbmV0d29yayBlbnRpdGll cy4mbmJzcDsgT25lIHdheSB0byAmbmJzcDsmbmJzcDsgY29udmV5IGNvbnRhY3QgaW5mb3JtYXRp b24gaXMgYnkgdXNpbmcgdGhlDQogdGhlIFNJUCBldmVudCBwYWNrYWdlIGZvciAmbmJzcDsmbmJz cDsgcmVnaXN0cmF0aW9ucyBtZWNoYW5pc20gW1JGQzM2ODBdLiZuYnNwOyBbUkZDMzY4MF0gZGVm aW5lcyBnZW5lcmljICZuYnNwOyZuYnNwOyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgdGhl IFNJUCBldmVudCBwYWNrYWdlIGZvciByZWdpc3RyYXRpb25zLiAmbmJzcDsmbmJzcDsgQXMgdGhl IFBOUy1yZWxhdGVkIFNJUCBVUkkgcGFyYW1ldGVycyBjb252ZXllZCBpbiB0aGUgUkVHSVNURVIg Jm5ic3A7Jm5ic3A7IHJlcXVlc3QgY29udGFpbiBzZW5zaXRpdmUNCiBpbmZvcm1hdGlvbiwgb3Bl cmF0b3JzIHRoYXQgc3VwcG9ydCB0aGUgJm5ic3A7Jm5ic3A7IGV2ZW50IHBhY2thZ2UgTVVTVCBl bnN1cmUgdGhhdCBldmVudCBwYWNrYWdlIHN1YnNjcmlwdGlvbnMgYXJlICZuYnNwOyZuYnNwOyBw cm9wZXJseSBhdXRoZW50aWNhdGVkIGFuZCBhdXRob3JpemVkLCBhbmQgdGhhdCB0aGUgU0lQIFVS SSAmbmJzcDsmbmJzcDsgcGFyYW1ldGVycyBhcmUgbm90IGluc2VydGVkIGluIGV2ZW50IG5vdGlm aWNhdGlvbnMgc2VudCB0byBvdGhlciAmbmJzcDsmbmJzcDsgdXNlcnMsIG9yIHRvIG5vbi10cnVz dGVkDQogbmV0d29yayBlbnRpdGllcy4mcXVvdDs8L2Rpdj4NCjwvc3Bhbj48L3NwYW4+PGJyPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08YnI+DQo8YnI+DQrCpzQuMjo8YnI+DQo8YnI+DQomZ3Q7Jm5ic3A7IFRoZSBVQSBjYW4gZG8g c28gYnkgb25seSBpbmNsdWRpbmcgdGhlIHBuLXByb3ZpZGVyPGJyPg0KJmd0OyZuYnNwOyBTSVAg VVJJIHBhcmFtZXRlciBpbiB0aGUgU0lQIENvbnRhY3QgaGVhZGVyIGZpZWxkIFVSSSBvZiB0aGUg UkVHSVNURVI8YnI+DQomZ3Q7Jm5ic3A7IHJlcXVlc3QsIGJ1dCB3aXRob3V0IGluY2x1ZGluZyB0 aGUgcG4tcHJpZCBTSVAgVVJJIHBhcmFtZXRlci48YnI+DQomZ3Q7PGJyPg0KJmd0O1VubGVzcyBJ J20gbWlzdGFrZW4sIHRoaXMgaXMgYSBiYXJyaWVyIHRvIGludGVyb3BlcmF0aW9uLjxicj4NCiZn dDs8YnI+DQomZ3Q7SXQncyBub3QgMTAwJSBjbGVhciwgYnV0IEkgc3VzcGVjdCB0aGUgaW50ZW5k ZWQgaW1wbGljYXRpb24gaXMgdGhhdCB0aGU8YnI+DQomZ3Q7cG4tcHJvdmlkZXIgcGFyYW1ldGVy IGhlcmUgd2lsbCBjb250YWluIGEgc2luZ2xlIHZhbHVlPyBUaGUgc3ludGF4IG9mIHRoZTxicj4N CiZndDtwYXJhbWV0ZXIgY2VydGFpbmx5IHNlZW1zIHRvIGltcGx5IHRoYXQuIFRoaXMgc2VlbXMg dG8gYmUgYSBwcmV0dHkgYmlnPGJyPg0KJmd0O3Byb2JsZW0sIHNpbmNlIGl0IHByZXN1cHBvc2Vz IHRoYXQgdGhlIGNsaWVudCB3aWxsIGtub3cgd2hpY2ggUE5TZXMgdGhlIFByb3h5PGJyPg0KJmd0 O3N1cHBvcnRzLiZuYnNwOyBDb25zaWRlciwgZm9yIGV4YW1wbGUsIGFuIGlPUyBjbGllbnQgdGhh dCBjYW4gdXNlIGFueSBvZiBSRkMgODAzMCw8YnI+DQomZ3Q7RkNNLCBhbmQgQVBOIChjZiA8YSBj bGFzcz0ieF9PV0FBdXRvTGluayIgaWQ9IkxQbG5rOTgxMCIgaHJlZj0iaHR0cHM6Ly9maXJlYmFz ZS5nb29nbGUuY29tL2RvY3MvY2xvdWQtbWVzc2FnaW5nL2lvcy9jbGllbnQiIHByZXZpZXdyZW1v dmVkPSJ0cnVlIj4NCmh0dHBzOi8vZmlyZWJhc2UuZ29vZ2xlLmNvbS9kb2NzL2Nsb3VkLW1lc3Nh Z2luZy9pb3MvY2xpZW50PC9hPikuPGJyPg0KJmd0O0lmIHRoZSBjbGllbnQgZG9lc24ndCBrbm93 IGEgcHJpb3JpIHdoYXQgdGhlIHByb3h5IHN1cHBvcnRzIChhbmQgdGhpcyBlbnRpcmU8YnI+DQom Z3Q7c2VjdGlvbiBvbmx5IG1ha2VzIHNlbnNlIGlmIHRoYXQncyB0cnVlKSwgdGhlbiBpdCB3b24n dCBrbm93IHdoaWNoIG9mIHRob3NlPGJyPg0KJmd0O3RocmVlIHNlcnZpY2VzIHRvIGluZGljYXRl IGluIGl0cyBSRUdJU1RFUiByZXF1ZXN0LiBJZiBpdCBndWVzc2VzIHdyb25nLCB0aGlzPGJyPg0K Jmd0O21lY2hhbmlzbSBzaW1wbHkgZmFpbHMuPGJyPg0KJmd0Ozxicj4NCiZndDtJIHRoaW5rIHlv dSBuZWVkIGEgZGlmZmVyZW50IGRpc2NvdmVyeSBtZWNoYW5pc20gaGVyZSAtLSBlaXRoZXIgaGF2 ZSBvbmUgdGhhdDxicj4NCiZndDtoYXMgdGhlIGNsaWVudCBvZmZlcmluZyBtdWx0aXBsZSBQTlMg cHJvdG9jb2xzIGFuZCB0aGUgcHJveHkgcmVzcG9uZGluZyB3aXRoPGJyPg0KJmd0O29uZSwgb3Ig aGF2ZSBvbmUgaW4gd2hpY2ggdGhlIHByb3h5IGluZGljYXRlcyBhbGwgb2YgaXRzIHN1cHBvcnRl ZCBzZXJ2aWNlcyBpbjxicj4NCiZndDthIHJlc3BvbnNlLCBhbmQgdGhlIGNsaWVudCBjaG9vc2Vz IG9uZSB0byB1c2UgaW4gaXRzIG5leHQgUkVHSVNURVIgbWVzc2FnZS48YnI+DQo8YnI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij5UaGlzIGhhcyBiZWVuIGFkZHJlc3NlZCBpbiBz ZWN0aW9uIDQuMS41ICg8c3Bhbj5RdWVyeSBOZXR3b3JrIFBOUyBDYXBhYmlsaXRpZXM8L3NwYW4+ KS4gVGhlIFVBIGNhbiBub3cmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij5j aG9vc2UgdG8gbm90IGluY2x1ZGUgdGhlIHBuLXByb3ZpZGVyIHBhcmFtZXRlciwgaW4gd2hpY2gg Y2FzZSB0aGUgbmV0d29yayB3aWxsIHJldHVybiBhbGwmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9 InhfUGxhaW5UZXh0Ij5QTlMgcHJvdG9jb2xzIHN1cHBvcnRlZC48L2Rpdj4NCjxkaXYgY2xhc3M9 InhfUGxhaW5UZXh0Ij48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQomZ3Q7Rmln dXJlIDE6PGJyPg0KJmd0Ozxicj4NCiZndDtUaGlzIGRpYWdyYW0gaW5jbHVkZXMgYm90aCBhIGxh ZGRlciBkaWFncmFtIGFuZCBhbiBleGFtcGxlIFJFR0lTVEVSIG1lc3NhZ2UuPGJyPg0KJmd0O1do aWxlIGJvdGggb2YgdGhlc2UgYXJlIHVzZWZ1bCBhdCB0aGlzIHBvaW50IGluIHRoZSBkb2N1bWVu dCwgbmVpdGhlciBvZiB0aGVtIGlzPGJyPg0KJmd0O2FuICZxdW90O0FyY2hpdGVjdHVyZSwmcXVv dDsgYW5kIHRoZXkncmUgcmVhbGx5IHR3byBkaWZmZXJlbnQgdGhpbmdzLiBJIHN1Z2dlc3QgYnJl YWtpbmc8YnI+DQomZ3Q7dGhpcyBpbnRvIHR3byBGaWd1cmVzLCBlbnRpdGxlZCAmcXVvdDtUeXBp Y2FsIEluZm9ybWF0aW9uIEZsb3cmcXVvdDsgYW5kICZxdW90O0V4YW1wbGUgUkVHSVNURVI8YnI+ DQomZ3Q7TWVzc2FnZSZxdW90OyAob3Igc2ltaWxhciksIHJlc3BlY3RpdmVseS48YnI+DQo8YnI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij5UaGlzIGhhcyBiZWVuIGFkZHJlc3Nl ZCBhcyBzdWdnZXN0ZWQgaW4gU2VjdGlvbiAxIChJbnRyb2R1Y3Rpb24pLjwvZGl2Pg0KPGRpdiBj bGFzcz0ieF9QbGFpblRleHQiPjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCio8YnI+DQrC pzQuMTo8YnI+DQo8YnI+DQomZ3Q7Jm5ic3A7IEFzIGxvbmcgYXMgdGhlIFVBIHdhbnRzIHRvIHJl Y2VpdmUgcHVzaCBub3RpZmljYXRpb25zIChyZXF1ZXN0ZWQgYnk8YnI+DQomZ3Q7Jm5ic3A7IHRo ZSBwcm94eSksIHRoZSBVQSBNVVNUIGluY2x1ZGUgYSBwbi1wcm92aWRlciwgcG4tcHJpZCBhbmQg YSBwbi1wYXJhbTxicj4NCiZndDsmbmJzcDsgKGlmIHJlcXVpcmVkIGZvciB0aGUgc3BlY2lmaWMg UE5TIHByb3ZpZGVyKSBTSVAgVVJJIHBhcmFtZXRlciBpbiBlYWNoPGJyPg0KJmd0OyZuYnNwOyBi aW5kaW5nLXJlZnJlc2ggUkVHSVNURVIgcmVxdWVzdC48YnI+DQomZ3Q7PGJyPg0KJmd0O1BsZWFz ZSBiZSBjbGVhciB0aGF0IHRoZXNlIHBhcmFtZXRlcnMgYXBwZWFyIGluIHRoZSBDb250YWN0IFVS SS48YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij5FdmVudGhvdWdo IHRoZSB0ZXh0IGFib3ZlIGRvZXMgbm8gbG9uZ2VyIGV4aXN0LCBpdCBoYXMgbm93IGJlZW4gZ2Vu ZXJhbGx5IGNsYXJpZmllZCB0aGF0IHRoZSBwYXJhbWV0ZXJzIGFwcGVhciBpbiB0aGUgQ29udGFj dCBVUkkuPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+PGJyPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSJ4X1BsYWluVGV4dCI+KEkgZGlkIG5vdGUgYSBidWcgaW4gc2VjdGlvbiA0LjEuMi4g SSBzYXlzICZxdW90O1VBIE1VU1QgaW5jbHVkZSZxdW90OywgYnV0IGl0IHNoYWxsIGJlICZxdW90 O1VBIE1VU1QgTk9UIGluY2x1ZGUmcXVvdDspPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4 dCI+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0Kwqc1LjI6PGJyPg0KPGJyPg0K Jmd0OyZuYnNwOyBJbiBvcmRlciB0byByZXF1ZXN0IHB1c2ggbm90aWZpY2F0aW9ucyB0b3dhcmRz IGEgU0lQIFVBIHRoYXQgd2lsbDxicj4NCiZndDsmbmJzcDsgdHJpZ2dlciB0aGUgVUEgdG8gc2Vu ZCBiaW5kaW5nLXJlZnJlc2ggU0lQIFJFR0lTVEVSIHJlcXVlc3RzLCB0aGUgU0lQPGJyPg0KJmd0 OyZuYnNwOyBwcm94eSBuZWVkcyB0byBoYXZlIGluZm9ybWF0aW9uIGFib3V0IHdoZW4gYSByZWdp c3RyYXRpb24gd2lsbDxicj4NCiZndDsmbmJzcDsgZXhwaXJlLiZuYnNwOyBUaGUgcHJveHkgbmVl ZHMgdG8gYmUgYWJsZSB0byByZXRyaWV2ZSB0aGUgaW5mb3JtYXRpb24gZnJvbTxicj4NCiZndDsm bmJzcDsgdGhlIHJlZ2lzdHJhciB1c2luZyBzb21lIG1lY2hhbmlzbS4mbmJzcDsgU3VjaCBtZWNo YW5pc21zIGFyZSBvdXRzaWRlIHRoZTxicj4NCiZndDsmbmJzcDsgc2NvcGUgb2YgdGhpcyBkb2N1 bWVudCwgYnV0IGNvdWxkIGJlIGltcGxlbWVudGVkIGUuZy4sIHVzaW5nIHRoZTxicj4NCiZndDsm bmJzcDsgU0lQcmVnaXN0cmF0aW9uIGV2ZW50IHBhY2thZ2UgbWVjaGFuaXNtIFtSRkMzNjgwXS48 YnI+DQomZ3Q7PGJyPg0KJmd0O05pdDogJnF1b3Q7U0lQIHJlZ2lzdHJhdGlvbiZxdW90OzwvZGl2 Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9Q bGFpblRleHQiPkhhcyBiZWVuIGZpeGVkLjxicj4NCjxicj4NCiZndDtUaGlzIG1lY2hhbmlzbSBz ZWVtcyB0byBiZSBwcmVkaWNhdGVkIG9uIGFuIGFyY2hpdGVjdHVyZSBpbiB3aGljaCB0aGUgcHJv eHkgbXVzdDxicj4NCiZndDtiZSBvbiB0aGUgdHJhZmZpYyBwYXRoLiBBbHRob3VnaCBpdCdzIHBy b2JsZW1hdGljIGZyb20gYSAmcXVvdDt3aGF0IHByb3hpZXMgYXJlPGJyPg0KJmd0O2V4cGVjdGVk IHRvIGRvJnF1b3Q7IHBlcnNwZWN0aXZlLCBpdCBzZWVtcyBsaWtlIHRoZSBwcm94eSBjb3VsZCBn bGVhbiB0aGlzPGJyPg0KJmd0O2luZm9ybWF0aW9uIGZyb20gdGhlIDIwMCByZXNwb25zZSB0byB0 aGUgUkVHSVNURVIgcmVxdWVzdC4gKEkgbWVhbiwgdGhlIHByb3h5IGlzPGJyPg0KJmd0O2FscmVh ZHkgcmVhZGluZyBwYXJhbWV0ZXJzIG91dCBvZiB0aGUgY29udGFjdCBoZWFkZXIgZmllbGQsIHNv IHRoZSBiZWhhdmlvciBvZjxicj4NCiZndDthY3Rpbmcgb24gcmVnaXN0cmF0aW9uIGluZm9ybWF0 aW9uIGlzIGFscmVhZHkgYXNzdW1lZCkuIFRoZSBwcm94eSB3b3VsZCwgb2Y8YnI+DQomZ3Q7Y291 cnNlLCBuZWVkIHRvIHJ1biBpdHMgb3duIHRpbWVycywgYnV0IHRoYXQgc2VlbXMgdG8gYmUgYSBw cmV0dHkgbWlub3I8YnI+DQomZ3Q7cmVxdWlyZW1lbnQsIGdpdmVuIGV2ZXJ5dGhpbmcgZWxzZSBp bnZvbHZlZCBoZXJlLjxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQi PldoZW4gSSBwcmV2aW91c2x5IHJlcGxpZWQgdG8geW91ciBDT01NRU5ULCBJIHNhaWQgdGhlIGZv bGxvd2luZzo8L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij48YnI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9InhfUGxhaW5UZXh0Ij4NCjxkaXY+JnF1b3Q7T25lIHdheSB0byBpbXBsZW1lbnQg dGhlICZxdW90O3JldHJpZXZlIHRoZSBpbmZvcm1hdGlvbiBmcm9tIHRoZSByZWdpc3RyYXImcXVv dDsgY291bGQgb2YgY291cnNlIGJlIHVzaW5nIG93biB0aW1lcnMuJm5ic3A7PC9kaXY+DQo8ZGl2 PkJ1dCwgSSBkb24ndCB0aGluayB3ZSBzaG91bGQgc3BlY2lmeSBzdWNoIGJlaGF2aW9yLjxicj4N Cjxicj4NCkFsc28sIGluIHNvbWUgY2FzZXMgdGhlIHByb3h5IG1pZ2h0IGJlIGNvLWxvY2F0ZWQg d2l0aCB0aGUgJnF1b3Q7aG9tZSBwcm94eSZxdW90Oywgb3Igc29tZSBvdGhlciBuZXR3b3JrIG5v ZGUsJm5ic3A7PC9kaXY+DQo8ZGl2PndoZXJlIHRoZSBpbnRlcmZhY2Ugd2l0aCB0aGUgcmVnaXN0 cmFyIGFscmVhZHkgZXhpc3RzLiZxdW90OzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ Tm8gY2hhbmdlcyB3ZXJlIGRvbmUgYmFzZWQgb24gdGhlIGNvbW1lbnQuPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPg0KPGJyPg0Kwqc1LjMuMTo8YnI+DQo8YnI+DQomZ3Q7VGhpcyBpcyBhIG1ham9y IGNvbW1lbnQsIGFuZCBvbmUgdGhhdCBoYXMgYSBzdWZmaWNpZW50IGltcGFjdCBvbiBpbnRlcm9w IHRoYXQgSTxicj4NCiZndDtoYWQgYSBsb25nIGRlYmF0ZSB3aXRoIG15c2VsZiBhYm91dCB3aGV0 aGVyIGl0IHNob3VsZCBiZSBhIERJU0NVU1MuIFBsZWFzZSB0YWtlPGJyPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSJ4X1BsYWluVGV4dCI+Jmd0O2l0IHZlcnkgc2VyaW91c2x5Ljxicj4NCiZndDs8YnI+ DQomZ3Q7Jm5ic3A7IE90aGVyd2lzZSwgaWYgdGhlIHBuLXByb3ZpZGVyIFNJUCBVUkkgcGFyYW1l dGVyIGlkZW50aWZpZXMgYSB0eXBlIG9mPGJyPg0KJmd0OyZuYnNwOyBQTlMgdGhhdCB0aGUgcHJv eHkgZG9lcyBub3Qgc3VwcG9ydCwgb3IgaWYgdGhlIFJFR0lTVEVSIHJlcXVlc3QgZG9lczxicj4N CiZndDsmbmJzcDsgbm90IGNvbnRhaW4gYWxsIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gcmVxdWly ZWQgZm9yIHRoZSBzcGVjaWZpYyB0eXBlPGJyPg0KJmd0OyZuYnNwOyBvZiBQTlMsIHRoZSBwcm94 eSBNVVNUIGVpdGhlciBmb3J3YXJkIHRoZSByZXF1ZXN0IChlLmcuLCBpZiB0aGUgcHJveHk8YnI+ DQomZ3Q7Jm5ic3A7IGtub3dzIHRoYXQgYW5vdGhlciBwcm94eSB0aGF0IHdpbGwgcmVjZWl2ZSB0 aGUgUkVHSVNURVIgcmVxdWVzdDxicj4NCiZndDsmbmJzcDsgc3VwcG9ydHMgdGhlIHR5cGUgb2Yg UE5TKS4uLjxicj4NCiZndDs8YnI+DQomZ3Q7SG93IHdvdWxkIHRoZSBwcm94eSBrbm93IHRoaXM/ PC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSJ4X1BsYWluVGV4dCI+SW4gdGhlIHByZXZpb3VzIHJlcGx5LCBJIHNhaWQgJnF1b3Q7bG9jYWwg Y29uZmlndXJhdGlvbiZxdW90Oy48L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij48YnI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij5JdCBoYXMgYmVlbiBjbGFyaWZpZWQg aW4gdGhlIHRleHQsIGFuZCB0aGUgdGV4dCBpbiBzZWN0aW9uIDUuNi4xLjEgbm93IHNheXM6PC9k aXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4 X1BsYWluVGV4dCI+JnF1b3Q7PHNwYW4gc3R5bGU9ImRpc3BsYXk6aW5saW5lIWltcG9ydGFudDsg ZmxvYXQ6bm9uZTsgYmFja2dyb3VuZC1jb2xvcjp0cmFuc3BhcmVudDsgY29sb3I6cmdiKDAsMCww KTsgZm9udC1mYW1pbHk6Q29uc29sYXM7IGZvbnQtc2l6ZToxMy4zM3B4OyBmb250LXN0eWxlOm5v cm1hbDsgZm9udC12YXJpYW50Om5vcm1hbDsgZm9udC13ZWlnaHQ6NDAwOyBsZXR0ZXItc3BhY2lu Zzpub3JtYWw7IG9ycGhhbnM6MjsgdGV4dC1hbGlnbjpsZWZ0OyB0ZXh0LWRlY29yYXRpb246bm9u ZTsgdGV4dC1pbmRlbnQ6MHB4OyB0ZXh0LXRyYW5zZm9ybTpub25lOyB3aGl0ZS1zcGFjZTpwcmUt d3JhcDsgd29yZC1zcGFjaW5nOjBweDsgd29yZC13cmFwOmJyZWFrLXdvcmQiPklmDQogdGhlIHBy b3h5IGtub3dzIChieSBtZWFucyBvZiBsb2NhbCBjb25maWd1cmF0aW9uKSZxdW90OyA8L3NwYW4+ PGJyPg0KJmd0O0ZlYXR1cmVzIGxpa2Ugc3VwcHJlc3NpbmcgUE5TIGJlaGF2aW9yIHdoZW4gYSAm cXVvdDtzaXAucG5zJnF1b3Q7IGZlYXR1cmUgY2FwYWJpbGl0eSBpczxicj4NCiZndDtwcmVzZW50 IGluIHRoZSBSRUdJU1RFUiBpbXBseSB0aGF0IHRoZSB2YXJpb3VzIG5vZGVzIGluIHRoZSBuZXR3 b3JrIGRpc2NvdmVyPGJyPg0KJmd0O2NhcGFiaWxpdGllcyBvZiB0aGVpciBuZWlnaGJvcnMgYXV0 b21hdGljYWxseSAod2hpY2ggaXMgY29uc2lzdGVudCB3aXRoIHRoZSB3YXk8YnI+DQomZ3Q7U0lQ IGRvZXMgZmVhdHVyZXMpLCB3aGlsZSB0aGlzIHByb3Zpc2lvbiBzZWVtcyB0byByZXF1aXJlIHBy b3Zpc2lvbmVkIGtub3dsZWRnZS48YnI+DQomZ3Q7VGhpcyBpcyBnb2luZyB0byBiZSBvcGVyYXRp b25hbGx5IHZlcnkgY29uZnVzaW5nLjxicj4NCiZndDs8YnI+DQomZ3Q7QXQgdGhlIHZlcnkgbGVh c3QsIHRoZSBkb2N1bWVudCBuZWVkcyB0byBjYWxsIG91dCBob3cgdGhpcyAmcXVvdDtrbm93bGVk Z2UmcXVvdDsgaXM8YnI+DQomZ3Q7b2J0YWluZWQuIEluIHRoZSBtb3JlIGdlbmVyYWwgc2Vuc2Us IHNpbmNlIGEgY2xpZW50IGNhbm5vdCByZWx5IG9uIHRoZSBwcm94eTxicj4NCiZndDtzdXBwb3J0 aW5nICphbnkqIGtpbmQgb2YgUE5TLCB0aGUgdXNlIG9mIDU1NSBpbiB0aGUgd2F5IHNwZWNpZmll ZCBoZXJlIGlzIGF0PGJyPg0KJmd0O2Jlc3QgYW4gb3B0aW1pemF0aW9uIC0tIGFuZCwgc2luY2Ug dGhlIGNvbmZpZ3VyZWQgaW5mb3JtYXRpb24gY2FuIGNvbmZsaWN0IHdpdGg8YnI+DQomZ3Q7YWN0 dWFsIHJlYWxpdHksIGl0J3MgYW4gb3B0aW1pemF0aW9uIHRoYXQgY2FuIGFjdHVhbGx5IGJyZWFr IHRoaW5ncyB1bmxlc3M8YnI+DQomZ3Q7ZXh0cmVtZSBjYXJlIGlzIGV4ZXJjaXNlZC4gKGUuZy4s IGlmIHRoZSBwcm94eSBpcyBjb25maWd1cmVkIHRvICZxdW90O2tub3cmcXVvdDsgdGhhdCB0aGU8 YnI+DQomZ3Q7bmV4dCBwcm94eSBjYW5ub3QgcHJvdmlkZSBwdXNoIHNlcnZpY2UsIGJ1dCB0aGlz IGtub3dsZWRnZSBpcyB3cm9uZywgdGhlbiB0aGU8YnI+DQomZ3Q7bmV0d29yayBpcyB1bm5lY2Vz c2FyaWx5IGJyb2tlbi4pPGJyPg0KJmd0Ozxicj4NCiZndDtNeSByYXRoZXIgc3Ryb25nIHJlY29t bWVuZGF0aW9uIGlzIHRvIHJlbW92ZSB0aGlzIGNvZGUsIGFuZCBsZXQgdGhlIGNsaWVudCByZWx5 PGJyPg0KJmd0O29uIHRoZSBsYWNrIG9mIGluZGljYXRpb24gb2Ygc3VwcG9ydCBpbiB0aGUgcmVz cG9uc2UgaW5kaWNhdGUgdGhhdCB0aGUgZmVhdHVyZTxicj4NCiZndDtpcyBub3Qgc3VwcG9ydGVk LjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0ieF9QbGFpblRleHQiPkluIG15IHByZXZpb3VzIHJlcGx5IEkgc2FpZDo8L2Rpdj4NCjxkaXYg Y2xhc3M9InhfUGxhaW5UZXh0Ij48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0 Ij4NCjxkaXY+JnF1b3Q7SSB3b3VsZCBsaWtlIHRvIGtlZXAgdGhlIGNvZGUsIGJlY2F1c2UgdGhl cmUgYXJlIGNhc2VzIHdoZXJlIG9uZSB3YW50cyB0aGUgcmVnaXN0ZXIgdG8gYmUgcmVqZWN0ZWQm bmJzcDs8L2Rpdj4NCjxkaXY+KHJhdGhlciB0aGFuIGFjY2VwdGVkLCBidXQgd2l0aG91dCBpbmRp Y2F0aW9uIG9mIHN1cHBvcnRlZCBQTlMpIGlmIHRoZSBQTlMgaXMgbm90IHN1cHBvcnRlZC48YnI+ DQo8YnI+DQpBbHNvLCB0aGVyZSBhcmUgYWxyZWFkeSBkZXBsb3ltZW50cyBvZiA1NTUsIHNvIEkn ZCBwcmVmZXIgdG8ga2VlcCBpdCwgYXMgaXQgZG9lc24ndCBicmVhayBhbnl0aGluZy4mcXVvdDs8 YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIDU1NSByZXNwb25zZSBjb2RlIGhhcyBiZWVuIGtl cHQsIGFuZCByZWdhcmRpbmcgdGhlIHByb3h5IGtub3dpbmcgaXQgd2FzIGNsYXJpZmllZCB0aGF0 IGl0IGlzIGJhc2VkIG9uIGxvY2FsIGNvbmZpZ3VyYXRpb24gKHNlZSBhYm92ZSkuPC9kaXY+DQo8 YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQrCpzUuMy4xOjxicj4NCjxicj4NCiZn dDsmbmJzcDsgbyZuYnNwOyBpZiB0aGUgcHJveHkgcmVjZWl2ZWQgYSAnc2lwLnBuc3JlZycgbWVk aWEgZmVhdHVyZSB0YWcgaW4gdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBS RUdJU1RFUiByZXF1ZXN0LCB0aGUgcHJveHkgU0hPVUxEIGluY2x1ZGUgYSAnc2lwLnBuc3JlZycg ZmVhdHVyZS08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNhcGFiaWxpdHkgaW5k aWNhdG9yIHdpdGggYW4gaW5kaWNhdG9yIHZhbHVlIGJpZ2dlciB0aGFuIDEyMCBpbjxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIHJlc3BvbnNlLCB1bmxlc3MgdGhlIHByb3h5 IGFsd2F5cyB3YW50IHRvIHJlcXVlc3QgcHVzaDxicj4NCiZndDs8YnI+DQomZ3Q7Tml0OiAmcXVv dDsuLi53YW50cy4uLiZxdW90Ozxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFp blRleHQiPkhhcyBiZWVuIGZpeGVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxi cj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCsKnNS4zLjI6PGJyPg0KPGJyPg0KJmd0 OyZuYnNwOyBJZiB0aGUgY29udGFjdCBvZiB0aGUgUkVHSVNURVIgcmVxdWVzdCBkb2VzIG5vdCBt YXRjaDxicj4NCiZndDsmbmJzcDsgdGhlIFJlcXVlc3QtVVJJIG9mIHRoZSBTSVAgcmVxdWVzdCB0 byBiZSBmb3J3YXJkZWQsIG9yIGlmIHRoZSBjb250YWN0PGJyPg0KJmd0OyZuYnNwOyB3YXMgbm90 IHByZXNlbnQgaW4gdGhlIFJFR0lTVEVSIHJlc3BvbnNlLCB0aGUgcHJveHkgTVVTVCByZWplY3Qg dGhlPGJyPg0KJmd0OyZuYnNwOyBTSVAgcmVxdWVzdCB3aXRoIGEgNDA0IChOb3QgRm91bmQpIHJl c3BvbnNlLjxicj4NCiZndDs8YnI+DQomZ3Q7VGhpcyBzZWVtcyB0byBiZSBhIHZlcnkgc3Ryb25n IHJlcXVpcmVtZW50ICgmcXVvdDtNVVNUJnF1b3Q7KSB3aGVuLCBlLmcuLCBtYW55IG9yIG1vc3Q8 YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij4mZ3Q7bmV0d29ya3MgbWF5IHdh bnQgdG8gcmV0dXJuIGEgNDgwIGluc3RlYWQgb2YgYSA0MDQuIEkgdGhpbmsgd2hhdCB5b3Ugd2Fu dCB0byBzYXk8YnI+DQomZ3Q7aXMgc29tZXRoaW5nIGxpa2UgJnF1b3Q7Li4uTVVTVCByZWplY3Qg dGhlIFNJUCByZXF1ZXN0LiBSZXNwb25zZSBjb2RlcyBvZiBlaXRoZXI8YnI+DQomZ3Q7NDA0IChO b3QgRm91bmQpIG9yIDQ4MCAoVGVtcG9yYXJpbHkgVW5hdmFpbGFibGUpIGFyZSBSRUNPTU1FTkRF RCwgYnV0IG90aGVyPGJyPg0KJmd0O2FwcHJvcHJpYXRlIGNvZGVzIG1heSBiZSB1c2VkIGFzIHdl bGwuJnF1b3Q7PGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+VGhp cyBoYXMgYmVlbiBhZGRyZXNzZWQgd2l0aCB0aGUgZm9sbG93aW5nIHRleHQ6PC9kaXY+DQo8ZGl2 IGNsYXNzPSJ4X1BsYWluVGV4dCI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4 dCI+DQo8ZGl2PiZxdW90O0l0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIHByb3h5IHNlbmRzIGVp dGhlciBhIDQwNCAoTm90PGJyPg0KJm5ic3A7Rm91bmQpIHJlc3BvbnNlIG9yIGEgNDgwIChUZW1w b3JhcmlseSBVbmF2YWlsYWJsZSkgcmVzcG9uc2UgdG8gdGhlPGJyPg0KJm5ic3A7U0lQIHJlcXVl c3QsIGJ1dCBvdGhlciByZXNwb25zZSBjb2RlcyBjYW4gYmUgdXNlZCBhcyB3ZWxsLiZxdW90Ozxi cj4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0Kwqc1LjMuMjo8YnI+DQo8YnI+DQomZ3Q7Jm5ic3A7IFRo ZSByZWFzb24gdGhlIHByb3h5IG5lZWRzIHRvIHdhaXQgZm9yIHRoZSBSRUdJU1RFUiByZXNwb25z ZSBiZWZvcmU8YnI+DQomZ3Q7Jm5ic3A7IGZvcndhcmRpbmcgdGhlIFNJUCByZXF1ZXN0IGlzIHRv IG1ha2Ugc3VyZSB0aGF0IHRoZSBSRUdJU1RFUiByZXF1ZXN0PGJyPg0KJmd0OyZuYnNwOyBoYXMg YmVlbiBhY2NlcHRlZCBieSB0aGUgcmVnaXN0cmFyLCBhbmQgdGhhdCB0aGUgVUEgd2hpY2ggaW5p dGlhdGVkPGJyPg0KJmd0Ozxicj4NCiZndDtOaXQ6ICZxdW90Oy4uLnRoZSBVQSB0aGF0IGluaXRp YXRlZC4uLiZxdW90Ozxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQi PkhhcyBiZWVuIGZpeGVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxicj4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCsKnNS4zLjI6PGJyPg0KPGJyPg0KJmd0OyZuYnNw OyBJbiBjYXNlIG9mIG5vbi0yeHggcmVzcG9uc2UgdG8gdGhlIFJFR0lTVEVSIHJlcXVlc3QsIHRo ZSBwcm94eSBNVVNUPGJyPg0KJmd0OyZuYnNwOyByZWplY3QgdGhlIFNJUCByZXF1ZXN0IHdpdGgg YSA0MDQgKE5vdCBGb3VuZCkgcmVzcG9uc2UuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgSWYg dGhlIHB1c2ggbm90aWZpY2F0aW9uIHJlcXVlc3QgZmFpbHMgKHNlZSBQTlMtc3BlY2lmaWM8YnI+ DQomZ3Q7Jm5ic3A7IGRvY3VtZW50YXRpb24gZm9yIGRldGFpbHMpLCB0aGUgcHJveHkgTVVTVCBy ZWplY3QgdGhlIFNJUCByZXF1ZXN0PGJyPg0KJmd0OyZuYnNwOyB3aXRoIGEgNDgwIChUZW1wb3Jh cmlseSBVbmF2YWlsYWJsZSkgcmVzcG9uc2UuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgSWYg dGhlIHByb3h5IGRvZXMgbm90IHJlY2VpdmUgdGhlIFJFR0lTVEVSIHJlcXVlc3QgZnJvbSB0aGUg VUEgd2l0aGluPGJyPg0KJmd0OyZuYnNwOyBhIGdpdmVuIHRpbWUgYWZ0ZXIgdGhlIHByb3h5IGhh cyByZXF1ZXN0ZWQgdGhlIHB1c2ggbm90aWZpY2F0aW9uLCB0aGU8YnI+DQomZ3Q7Jm5ic3A7IHBy b3h5IE1VU1QgcmVqZWN0IHRoZSByZXF1ZXN0IHdpdGggYSA0ODAgKFRlbXBvcmFyaWx5IFVuYXZh aWxhYmxlKTxicj4NCiZndDsmbmJzcDsgcmVzcG9uc2UuJm5ic3A7IFRoZSB0aW1lIHZhbHVlIGlz IHNldCBiYXNlZCBvbiBsb2NhbCBwb2xpY3kuPGJyPg0KJmd0Ozxicj4NCiZndDtBcyBhYm92ZSwg dGhpcyBzZWVtcyB3YXkgdG9vIHJlc3RyaWN0aXZlIGluIHRlcm1zIG9mIG1hbmRhdGluZyBzcGVj aWZpYyBlcnJvcjxicj4NCiZndDtjb2Rlcy4gSXQgbWF5IHdlbGwgYmUgdGhlIGNhc2UgdGhhdCBh IG5ldHdvcmsgd291bGQgd2FudCB0byB0cmVhdCB0aGVzZTxicj4NCiZndDtzaXR1YXRpb25zIGlk ZW50aWNhbGx5IGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBjYWxsaW5nIHBhcnR5LjwvZGl2 Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9Q bGFpblRleHQiPkhhcyBiZWVuIGFkZHJlc3NlZCAoc2VlIGFib3ZlKS48L2Rpdj4NCjxkaXYgY2xh c3M9InhfUGxhaW5UZXh0Ij48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQrCpzUu My4yOjxicj4NCjxicj4NCiZndDsmbmJzcDsgT3RoZXJ3aXNlIHRoZTxicj4NCiZndDsmbmJzcDsg cHJveHkgTVVTVCByZWplY3QgdGhlIFNJUCByZXF1ZXN0IHdpdGggYSA0ODAgKFRlbXBvcmFyaWx5 PGJyPg0KJmd0OyZuYnNwOyBVbmF2YWlsYWJsZSkgcmVzcG9uc2UuPGJyPg0KJmd0Ozxicj4NCiZn dDtTYW1lIGNvbW1lbnQgYXMgYWJvdmUuPGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4 X1BsYWluVGV4dCI+SGFzIGJlZW4gYWRkcmVzc2VkIChzZWUgYWJvdmUpLjwvZGl2Pg0KPGRpdiBj bGFzcz0ieF9QbGFpblRleHQiPjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCsKn Ni4xLjE6PGJyPg0KPGJyPg0KJmd0OyZuYnNwOyBXaGVuIHRoZSBVQSBzZW5kcyBpbiBpbml0aWFs IHJlcXVlc3QgZm9yIGEgZGlhbG9nLCBvciBhIDJ4eCByZXNwb25zZTxicj4NCiZndDs8YnI+DQom Z3Q7Tml0OiAmcXVvdDsuLi5zZW5kcyBhbiBpbml0aWFsIHJlcXVlc3QuLi4mcXVvdDs8YnI+DQo8 YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij5IYXMgYmVlbiBmaXhlZC48L2Rp dj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij48YnI+DQomZ3Q7Jm5ic3A7IHB1cnInIFNJUCBV UkkgcGFyYW1ldGVyIGluIHRoZSBDb250YWN0IGhlYWRlciBvZiB0aGUgcmVxdWVzdCBvcjxicj4N CiZndDs8YnI+DQomZ3Q7Tml0OiAmcXVvdDsuLi5Db250YWN0IGhlYWRlciBmaWVsZC4uLiZxdW90 Ozxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPkhhcyBiZWVuIGZp eGVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxicj4NCiZndDsmbmJzcDsgTk9U RTogQXMgdGhlICdwbi1wdXJyJyBTSVAgVVJJIHBhcmFtZXRlciBvbmx5IGFwcGxpZXMgdG8gYSBn aXZlPGJyPg0KJmd0OyZuYnNwOyBkaWFsb2csIHRoZSBVQSBuZWVkcyB0byBpbmNsdWRlIGEgJ3Bu LXB1cnInIHBhcmFtZXRlciBpbiB0aGUgQ29udGFjdDxicj4NCiZndDs8YnI+DQomZ3Q7Tml0OiAm cXVvdDsuLi5naXZlbiBkaWFsb2cuLi4mcXVvdDs8YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9InhfUGxhaW5UZXh0Ij5IYXMgYmVlbiBmaXhlZC48L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxh aW5UZXh0Ij48YnI+DQomZ3Q7Jm5ic3A7IGRpYWxvZywgdGhlIFVBIG5lZWRzIHRvIGluY2x1ZGUg YSAncG4tcHVycicgcGFyYW1ldGVyIGluIHRoZSBDb250YWN0PGJyPg0KJmd0OyZuYnNwOyBoZWFk ZXIgb2YgdGhlIHJlcXVlc3Qgb3IgcmVzcG9uc2UgZm9yIGVhY2ggZGlhbG9nIGluIHdoaWNoIHRo ZSBVQSBpczxicj4NCiZndDs8YnI+DQomZ3Q7Tml0OiAmcXVvdDsuLi5Db250YWN0IGhlYWRlciBm aWVsZC4uLiZxdW90Ozxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQi PkhhcyBiZWVuIGZpeGVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxicj4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCsKnNi4xLjE6PGJyPg0KPGJyPg0KJmd0OyZuYnNw OyBUaGUgVUEgTVVTVCBpbmNsdWRlIGEgcGFyYW1ldGVyIHZhbHVlIGlkZW50aWNhbCB0byB0aGUg dGhlPGJyPg0KJmd0OyZuYnNwOyBsYXN0ICdzaXAucG5zcHVycicgZmVhdHVyZS1jYXBhYmlsaXR5 IGluZGljYXRvciB0aGF0IGl0IHJlY2VpdmVkIGluIGE8YnI+DQomZ3Q7Jm5ic3A7IFJFR0lTVEVS IHJlc3BvbnNlLjxicj4NCiZndDs8YnI+DQomZ3Q7VGhpcyBpcyBpbmNyZWRpYmx5IGNvbmZ1c2lu ZywgYXMgdGhlICZxdW90O3NpcC5wbnNwdXJyJnF1b3Q7IGluZGljYXRvciBoYXMgbm90IGJlZW48 YnI+DQomZ3Q7bWVudGlvbmVkIGluIHRoZSBkb2N1bWVudCBzbyBmYXIuIFBsZWFzZSByZXZpc2Ug YXMgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZjo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNw OyBUaGUgVUEgTVVTVCBpbmNsdWRlIGEgcGFyYW1ldGVyIHZhbHVlIGlkZW50aWNhbCB0byB0aGUg dGhlIGxhc3Q8YnI+DQomZ3Q7Jm5ic3A7ICdzaXAucG5zcHVycicgZmVhdHVyZS1jYXBhYmlsaXR5 IGluZGljYXRvciAoc2VlIFNlY3Rpb24gNi4yLjEpIHRoYXQgaXQ8YnI+DQomZ3Q7Jm5ic3A7IHJl Y2VpdmVkIGluIGEgUkVHSVNURVIgcmVzcG9uc2UuPGJyPg0KJmd0Ozxicj4NCiZndDtBbHRlcm5h dGVseSwgcmV2ZXJzZSB0aGUgb3JkZXIgb2Ygc2VjdGlvbnMgNi4xIGFuZCA2LjIgc28gdGhhdCB0 aGUgUFVSUjxicj4NCiZndDtjb25jZXB0IGlzIHByb3Blcmx5IGludHJvZHVjZWQgYmVmb3JlIHBy b3RvY29sIHByb2NlZHVyZXMgYXJlIGRlZmluZWQgZm9yIGl0Ljxicj4NCjxicj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPlRoaXMgaGFzIGJlZW4gYWRkcmVzc2VkLCBieSBhZGRp bmcgYSByZWZlcmVuY2UgdG8gU2VjdGlvbiA2LjIuMS48L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxh aW5UZXh0Ij48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQoqPGJyPg0Kwqc2LjEuMTo8YnI+ DQo8YnI+DQomZ3Q7Jm5ic3A7IE5PVEU6IEFzIHRoZSAncG4tcHVycicgU0lQIFVSSSBwYXJhbWV0 ZXIgb25seSBhcHBsaWVzIHRvIGEgZ2l2ZTxicj4NCiZndDsmbmJzcDsgZGlhbG9nLCB0aGUgVUEg bmVlZHMgdG8gaW5jbHVkZSBhICdwbi1wdXJyJyBwYXJhbWV0ZXIgaW4gdGhlIENvbnRhY3Q8YnI+ DQomZ3Q7Jm5ic3A7IGhlYWRlciBvZiB0aGUgcmVxdWVzdCBvciByZXNwb25zZSBmb3IgZWFjaCBk aWFsb2cgaW4gd2hpY2ggdGhlIFVBIGlzPGJyPg0KJmd0OyZuYnNwOyB3aWxsaW5nIHRvIHJlY2Vp dmUgcHVzaCBub3RpZmljYXRpb25zIHRyaWdnZXJlZCBieSBpbmNvbWluZyBtaWQtPGJyPg0KJmd0 OyZuYnNwOyBkaWFsb2cgcmVxdWVzdHMuPGJyPg0KJmd0Ozxicj4NCiZndDtTaW1pbGFyIHRvIHRo ZSBhYm92ZSwgdGhpcyBpcyBhIHZlcnkgY29uZnVzaW5nIGludHJvZHVjdGlvbiBvZiB0aGUgJnF1 b3Q7cG4tcHVyciZxdW90OyBVUkk8YnI+DQomZ3Q7cGFyYW1ldGVyLjxicj4NCjxicj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPkkgcmVhbGl6ZWQgdGhpcyBoYXMgYmVlbiBmaXhl ZCBpbiB0aGUgd3Jvbmcgc2VjdGlvbi4gSSB3aWxsIGZpeCB0aGF0IGJ5IGFkZGluZyBhIHJlZmVy ZW5jZSB0byBTZWN0aW9uIDYuMi4xLjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxz cGFuIHN0eWxlPSIiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iIj5Ob3RlLCB0aG91Z2gsIHRoYXQgdGhlIGZpcnN0IG9jY3VycmVuY2Ug b2YgJ3BuLXB1cnInIFNJUCBVUkkgcGFyYW1ldGVyIGlzIGluIHRoZSBmaXJzdCBwYXJhZ3JhcGgg b2Ygc2VjdGlvbiA2LjEuMSwgc28gSSB3aWxsIGFkZCB0aGUgcmVmZXJlbmNlIHRoZXJlLjwvc3Bh bj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij48YnI+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQo8YnI+DQrCpzYuMi4yOjxicj4NCjxicj4NCiZndDsmbmJzcDsgQ29udGFj dCBoZWFkZXIgZmllbGQgd2l0aCBhIFBVUlIgdmFsdWUgdGhhdCB0aGUgcHJveHkgaGFzIGdlbmVy YXRlZDxicj4NCiZndDsmbmJzcDsgU2VjdGlvbiA2LjIuMiwgdGhlIHByb3h5IE1VU1QgYWRkIGEg UmVjb3JkLVJvdXRlIGhlYWRlciB0byB0aGU8YnI+DQomZ3Q7Jm5ic3A7IHJlcXVlc3QsIHRvIGlu c2VydCBpdHNlbGYgaW4gdGhlIGRpYWxvZyByb3V0ZSBbUkZDMzI2MV0uPGJyPg0KJmd0Ozxicj4N CiZndDtUaGlzICZxdW90O1NlY3Rpb24gNi4yLjImcXVvdDsgbWFrZXMgdGhlIHNlbnRlbmNlIGlt cG9zc2libGUgdG8gcmVhZC4gSXMgaXQgaW50ZW5kZWQgdG8gYmU8YnI+DQomZ3Q7aW4gcGFyZW50 aGVzZXM/PGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+SGFzIGJl ZW4gZml4ZWQuPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+PGJyPg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KPGJyPg0Kwqc2LjIuMzo8YnI+DQo8YnI+DQomZ3Q7Jm5ic3A7IEFzIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDUuMy4yLCB3aGlsZSB3YWl0aW5nIGZvciB0aGUgcHVzaDxicj4N CiZndDsmbmJzcDsgbm90aWZpY2F0aW9uIHJlcXVlc3QgdG8gc3VjY2VlZCwgYW5kIHRoZSBhc3Nv Y2lhdGVkIFJFR0lTVEVSIHJlcXVlc3Q8YnI+DQomZ3Q7Jm5ic3A7IHRvIGFycml2ZSBmcm9tIHRo ZSBTSVAgVUEsIHRoZSBwcm94eSBuZWVkcyB0byB0YWtlIGludG8gY29uc2lkZXJhdGlvbjxicj4N CiZndDsmbmJzcDsgdGhhdCB0aGUgdHJhbnNhY3Rpb24gYXNzb2NpYXRlZCB3aXRoIHRoZSBOT1RJ RlkgcmVxdWVzdCB3aWxsPGJyPg0KJmd0OyZuYnNwOyBldmVudHVhbGx5IHRpbWUgb3V0IGF0IHRo ZSBzZW5kZXIgb2YgdGhlIHJlcXVlc3QgKFVBQyksIGFuZCB0aGU8YnI+DQomZ3Q7Jm5ic3A7IHNl bmRlciB3aWxsIGNvbnNpZGVyIHRoZSB0cmFuc2FjdGlvbiBhIGZhaWx1cmUuPGJyPg0KJmd0Ozxi cj4NCiZndDtJIHRoaW5rIHRoaXMgbmVlZHMgc29tZSBkaXNjdXNzaW9uIGFib3V0IHRoZSBpbXBh Y3Qgb2YgdGhlIGVycm9yIGNvZGVzIHNlbGVjdGVkPGJyPg0KJmd0O2J5IHRoZSBwcm94eSBvbiB0 aGUgZGlhbG9nIGFuZCBpdHMgdXNhZ2VzLiBGb3IgZXhhbXBsZTo8YnI+DQomZ3Q7PGJyPg0KJmd0 OyogSWYgdGhlIHByb3h5IHNlbmRzIGEgNDA0IHRvIHByZXZlbnQgYSB0cmFuc2FjdGlvbiB0aW1l b3V0LCBpdCB3aWxsIGRlc3Ryb3kgdGhlPGJyPg0KJmd0OyZuYnNwOyBkaWFsb2cgYW5kIGFsbCBv ZiBpdHMgdXNhZ2VzPGJyPg0KJmd0Ozxicj4NCiZndDsqIElmIHRoZSBwcm94eSBzZW5kcyBhIDQ4 MCB0byBwcmV2ZW50IGEgdHJhbnNhY3Rpb24gdGltZW91dCwgaXQgd2lsbCBkZXN0cm95IHRoZTxi cj4NCiZndDsmbmJzcDsgdXNhZ2UsIGJ1dCBub3Qgb3RoZXIgdXNhZ2VzIGluIHRoZSBkaWFsb2cg KGlmIGFueSk8YnI+DQomZ3Q7PGJyPg0KJmd0OyogSWYgdGhlIHByb3h5IHNlbmRzIGEgNTA0IHRv IHByZXZlbnQgYSB0cmFuc2FjdGlvbiB0aW1lb3V0LCBpdCB3aWxsIGtlZXAgdGhlPGJyPg0KJmd0 OyZuYnNwOyBkaWFsb2cgYW5kIHRoZSB1c2FnZSBhbGl2ZSwgYW5kIGFsbG93IHRoZSBjbGllbnQg dG8gcmUtdHJ5IGF0IGEgbGF0ZXIgdGltZS48YnI+DQomZ3Q7Jm5ic3A7IFNpbXBseSBhbGxvd2lu ZyB0aGUgdHJhbnNhY3Rpb24gdG8gdGltZSBvdXQgd2lsbCBoYXZlIHRoZSBzYW1lIGVmZmVjdCwg YWxiZWl0PGJyPg0KJmd0OyB3aXRoIG1vcmUgbWVzc2FnZSByZXRyYW5zbWlzc2lvbnMuPGJyPg0K Jmd0Ozxicj4NCiZndDsgUG9pbnRpbmcgdG8gUkZDIDUwNTcgbWlnaHQgYmUgdXNlZnVsIGhlcmUu PGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+VGhpcyBoYXMgYmVl biBhZGRyZXNzZWQuIFRoZSB0ZXh0IGluIFNlY3Rpb24gNi4yLjMgbm93IHNheXM6PC9kaXY+DQo8 ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImRpc3BsYXk6aW5saW5lIWltcG9ydGFudDsgZmxvYXQ6bm9uZTsg YmFja2dyb3VuZC1jb2xvcjp0cmFuc3BhcmVudDsgY29sb3I6cmdiKDAsMCwwKTsgZm9udC1mYW1p bHk6Q29uc29sYXM7IGZvbnQtc2l6ZToxMy4zM3B4OyBmb250LXN0eWxlOm5vcm1hbDsgZm9udC12 YXJpYW50Om5vcm1hbDsgZm9udC13ZWlnaHQ6NDAwOyBsZXR0ZXItc3BhY2luZzpub3JtYWw7IG9y cGhhbnM6MjsgdGV4dC1hbGlnbjpsZWZ0OyB0ZXh0LWRlY29yYXRpb246bm9uZTsgdGV4dC1pbmRl bnQ6MHB4OyB0ZXh0LXRyYW5zZm9ybTpub25lOyB3aGl0ZS1zcGFjZTpwcmUtd3JhcDsgd29yZC1z cGFjaW5nOjBweDsgd29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdj4mbmJzcDsmbmJzcDsgJnF1 b3Q7V2hlbiBhIHByb3h5IHNlbmRzIGFuIGVycm9yIHJlc3BvbnNlIHRvIGEgbWlkLWRpYWxvZyBy ZXF1ZXN0IChlLmcuLCAmbmJzcDsmbmJzcDsgZHVlIHRvIGEgdHJhbnNhY3Rpb24gdGltZSBvdXQp LCB0aGUgcHJveHkgU0hPVUxEIHNlbGVjdCBhIHJlc3BvbnNlICZuYnNwOyZuYnNwOyBjb2RlIHRo YXQgb25seSBpbXBhY3RzIHRoZSB0cmFuc2FjdGlvbiBhc3NvY2lhdGVkIHdpdGggdGhlIHJlcXVl c3QgJm5ic3A7Jm5ic3A7IChbUkZDNTA3OV0pLiZxdW90Ow0KPC9kaXY+DQo8L3NwYW4+PGJyPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0K PGJyPg0Kwqc4Ljc6PGJyPg0KPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBQYXJhbWV0ZXIg dmFsdWUgY2hhcmFjdGVycyB0aGF0IGFyZSBub3QgcGFydCBvZiBwdmFsdWUgbmVlZHMgdG8gYmU8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVzY2FwZWQsIGFzIGRlZmluZWQgaW4gUkZDIDMy NjEuPGJyPg0KJmd0Ozxicj4NCiZndDtOaXQ6ICZxdW90Oy4uLm5lZWQgdG8gYmUgZXNjYXBlZC4u LiZxdW90OzwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxicj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0ieF9QbGFpblRleHQiPkhhcyBiZWVuIGZpeGVkLjxicj4NCjxicj4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxicj4NCjxicj4NCsKnOTo8YnI+DQo8YnI+DQomZ3Q7Jm5ic3A7IFdoZW4gYSBu ZXcgdmFsdWUgaXMgcmVnaXN0ZXJlZCB0byB0aGUgUE5TIFN1Yi1yZWdpc3RyeSwgYSByZWZlcmVu Y2U8YnI+DQomZ3Q7Jm5ic3A7IHRvIGEgc3BlY2lmaWNhdGlvbiB3aGljaCBkZXNjcmliZXMgdGhl IHVzYWdlIG9mIHRoZSBQTlMgYXNzb2NpYXRlZDxicj4NCiZndDs8YnI+DQomZ3Q7Tml0OiAmcXVv dDsuLi5zcGVjaWZpY2F0aW9uIHRoYXQgZGVzY3JpYmVzLi4uJnF1b3Q7PGJyPg0KPGJyPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+SGFzIGJlZW4gZml4ZWQuPC9kaXY+DQo8ZGl2 IGNsYXNzPSJ4X1BsYWluVGV4dCI+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0K wqfCpzEwLTEyOjxicj4NCjxicj4NCiZndDtOaXQ6IEl0IHNlZW1zIGxpa2UgdGhlc2Ugc2hvdWxk IGFsbCBiZSBzdWJzZWN0aW9ucyBvZiBzZWN0aW9uIDkuPGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSJ4X1BsYWluVGV4dCI+SW4gbXkgcHJldmlvdXMgcmVwbHkgSSBzYWlkOjwvZGl2Pg0K PGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFp blRleHQiPjxzcGFuPiZxdW90O1RoZSBpZGVhIHdhcyB0aGF0IHRoZSBQTlMgcmVnaXN0cmF0aW9u cyBhcmUgaW4gc2VwYXJhdGUgbWFpbiBzZWN0aW9ucywgYXMgdGhleSBjb3VsZCBldmVuIGJlIGlu IGEgc2VwYXJhdGUgZG9jdW1lbnQuJnF1b3Q7PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9Q bGFpblRleHQiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5U ZXh0Ij5ObyBjaGFuZ2VzIHdlcmUgZG9uZSBiYXNlZCBvbiB0aGlzIGNvbW1lbnQuPC9kaXY+DQo8 ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJy Pg0KwqcxMDo8YnI+DQo8YnI+DQomZ3Q7Jm5ic3A7IFRoZSBUb3BpYyBjb25zaXN0cyBvZiB0aGUg QnVuZGxlIElELCB3aGljaCB1bmlxdWVsbHkgaWRlbnRpZmllcyBhbjxicj4NCiZndDsmbmJzcDsg YXBwbGljaWF0aW9uLCBhbmQgYSBzZXJ2aWNlIHZhbHVlIHRoYXQgaWRlbnRpZmllcyBhIHNlcnZp Y2U8YnI+DQomZ3Q7PGJyPg0KJmd0O05pdDogJnF1b3Q7dW5pcXVlbHkmcXVvdDs8YnI+DQomZ3Q7 Tml0OiAmcXVvdDthcHBsaWNhdGlvbiZxdW90Ozxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0ieF9QbGFpblRleHQiPlRoaXMgaGFzIGJlZW4gZml4ZWQuPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4 X1BsYWluVGV4dCI+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KwqcxMDo8YnI+ DQo8YnI+DQomZ3Q7Jm5ic3A7IEV4YW1wbGU6IHBuLXBhcmFtID0gREVGMTIzR0hJSi5jb20ueW91 cmNvbXBhbnkueW91cmV4YW1wbGVhcHAudm9pcDxicj4NCiZndDs8YnI+DQomZ3Q7UGxlYXNlIHVz ZSBhbiBSRkMgMjAyNiBkb21haW4gZm9yIHRoaXMgZXhhbXBsZTsgZS5nLjo8YnI+DQomZ3Q7PGJy Pg0KJmd0OyZuYnNwOyBFeGFtcGxlOiBwbi1wYXJhbSA9IERFRjEyM0dISUouY29tLmV4YW1wbGUu eW91cmV4YW1wbGVhcHAudm9pcDxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFp blRleHQiPkhhcyBiZWVuIGZpeGVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxi cj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCsKnMTE6PGJyPg0KPGJyPg0KJmd0OyZu YnNwOyBbUkZDODI5Ml0gZGVmaW5lcyBhIG1lY2hhbmlzbSB3aGljaCBhbGxvd3MgYSBwcm94eSB0 byBpZGVudGl0eSBpdHNlbGY8YnI+DQomZ3Q7PGJyPg0KJmd0OyBOaXQ6ICZxdW90Oy4uLm1lY2hh bmlzbSB0aGF0IGFsbG93cy4uLiZxdW90OzwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQi Pjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPkhhcyBiZWVuIGZpeGVkLjwv ZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i eF9QbGFpblRleHQiPjxzcGFuPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48YnI+DQo8YnI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij5SZWdhcmRzLDwvZGl2Pg0KPGRpdiBjbGFz cz0ieF9QbGFpblRleHQiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPkNo cmlzdGVyPGJyPg0KPGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwPjxicj4NCjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_HE1PR07MB3161189E5C9F82A14BBC873F93760HE1PR07MB3161eurp_-- From nobody Mon Mar 4 13:48:12 2019 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 D2B6F13110E; Mon, 4 Mar 2019 13:48:03 -0800 (PST) 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.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <155173608381.5281.17205147252514395276@ietfa.amsl.com> Date: Mon, 04 Mar 2019 13:48:03 -0800 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-27.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 21:48:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Push Notification with the Session Initiation Protocol (SIP) Authors : Christer Holmberg Michael Arnold Filename : draft-ietf-sipcore-sip-push-27.txt Pages : 40 Date : 2019-03-04 Abstract: This document describes how a Push Notification Service (PNS) can be used to wake a suspended Session Initiation Protocol (SIP) User Agent (UA) with push notifications, and also describes how the UA can send binding-refresh REGISTER requests and receive incoming SIP requests in an environment in which the UA may be suspended. The document defines new SIP URI parameters to exchange PNS information between the UA and the SIP entity that will then request that push notifications be sent to the UA, and to trigger such push notification requests. The document also defines new feature- capability indicators that can be used to indicate support of this mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-27 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-push-27 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 Mon Mar 4 13:50:01 2019 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 1148B1311F5 for ; Mon, 4 Mar 2019 13:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=eAS0rFPl; dkim=pass (1024-bit key) header.d=ericsson.com header.b=NRFkzLNZ 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 47A1UJEBnigk for ; Mon, 4 Mar 2019 13:49:50 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25371311FA for ; Mon, 4 Mar 2019 13:49:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551736186; x=1554328186; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lQ3ekmLEKX7oeIR6cQqebJrexjR6moGv6rIuGPwZrwU=; b=eAS0rFPlhrwlFaagw0z4TuEwxx7ifwIVMk9T71p9jOSmaa4Y8rILyaBFNuJ7qUKS CgTdkj0fBQOKsqsW28wTTUjByMzdGm/KUu+gLmYKWEqU7glYCEoqv6s0lcnMTfzW UjKRUfnRy2bP/2i3Gso/8fe5UWD6pa8iUxG0LdtBDdc=; X-AuditID: c1b4fb30-f93ff7000000355c-e7-5c7d9d7a3e9b Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 87.51.13660.A7D9D7C5; Mon, 4 Mar 2019 22:49:46 +0100 (CET) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 4 Mar 2019 22:49:46 +0100 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 4 Mar 2019 22:49:46 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lQ3ekmLEKX7oeIR6cQqebJrexjR6moGv6rIuGPwZrwU=; b=NRFkzLNZuDpPhd93ysoE6hObkcnXzL58a2MLg8m5TnJUIwMmMYL3MjFn6HeZTrHhFG/ox5eco4kbdTeyEGs2p2tGXuR0oDagoytNrSPr0DrkRFgmIOgErZOLle3SN/EDUHGdrZoaUbvHcB1hXntvCQGwn85XCBM2H/IJtCDdMIY= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4233.eurprd07.prod.outlook.com (20.176.166.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.14; Mon, 4 Mar 2019 21:49:45 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae%3]) with mapi id 15.20.1686.015; Mon, 4 Mar 2019 21:49:45 +0000 From: Christer Holmberg To: "sipcore@ietf.org" CC: "sipcore-chairs@ietf.org" , Ben Campbell Thread-Topic: Draft new version: SIP Push -27 Thread-Index: AQHU0tQupvwrEjlo+EqEK6+oQcuwiQ== Date: Mon, 4 Mar 2019 21:49:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 x-originating-ip: [37.33.16.2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bbf1effd-62eb-4803-9d03-08d6a0eb50b1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4233; x-ms-traffictypediagnostic: HE1PR07MB4233: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUI0MjMzOzIzOnZUenY0TWhIQzF4OWhEZ1FpTTY0bWVIYnYr?= =?utf-8?B?Z284U1lKTmZOWlVLZHRwb3hYK0tqNFlIN1dSUkRTRHJxOWFDME4wd0cyZnRz?= =?utf-8?B?V0twd2taTDVqVVJvTmpoVWh3SUtIZzVOQm5Ub29NeXhiSWlHSTBsWU9NN1Qy?= =?utf-8?B?ZEZSRTFITmRUWmpkelhmQkVHTlczdkZaNUlTYWIrbGh2V0J2TWVsaHdOcFpj?= =?utf-8?B?bnl3RmdpWEsya2JvTDdlYkdCenVkVkdRYkt2T2pJeWFJNkt0MmNDdmEzMFRX?= =?utf-8?B?anVhVml3aVpPRmo2YnJyckQ2VnVnQ1ZkellIYlZnUVVZbW5EZUc1VFBwTE5E?= =?utf-8?B?OWF3cTNaZE44K1VTSXFiMmVQVmx1WVNwUEF2S2FUNkgzVzBFZlFPM3hsZ0xj?= =?utf-8?B?WU1NakE3UHMzbU9TbkVJL2JlUVN1aGRwNk00TUI2bi8reHgwMlZ1NG9mUVRl?= =?utf-8?B?MFpSNkp1L3FadEFXMW1taWxGUlFBZmNZaEVhRmJKbzNRNVQzQjR5WG4zc0Nm?= =?utf-8?B?a29wQWlVN0N3ek90b2I3LzBkYndIaWFaV20ra0F2cHVZTitQcFFLby9xZUxz?= =?utf-8?B?emtqOWJoL3pnY3RzcVZONUdtRHBubzFIUFFNREo0TmdsZ240ajAxNnpZaWZD?= =?utf-8?B?ZDJvcTRDbzF6c2ErdFRSU2VWV3ByVXgxaXBWUU1EUUMwVzcwNDBkcjgyRjMx?= =?utf-8?B?OTJTbFArVzNHWDhGV3JLVFVGbnBRSEtLSkkxSDVRU2hvSnF6NmJtN0R2bmx0?= =?utf-8?B?bGFHWkVQTmxreEJYVitWZlZXemVmOFNCRW5LY0xTMFoxaVpvTXBTVHdUdDZW?= =?utf-8?B?YTJ6cEgvVk9IUEZiL1Mzd0lFa01oTnlvSnhiNTViTWlPM3J1Nnh0cDZGQmZ0?= =?utf-8?B?NFBRL29GdkUzUFlSdzJtakhqZTRKWk5iZ0tjZjhFYXZCTGEyOXpwMmxzQmo1?= =?utf-8?B?aDlWRThyYlFiVkNUTDZXUjY0SzRIRDN3VThoYWF2a1JMVlk3L2dMRHpUamh2?= =?utf-8?B?S2lDaFFNNUY0Nmg5TmFQQ3BYWTR3RE1PUmxLZUdOaGM2a3FXWTEycTNQMVpB?= =?utf-8?B?WUk5dDlESlFqQ3ZCVUlFalU3a25pWnRVa1JsZFh3bUV0RlovVEdKNTVWdXFN?= =?utf-8?B?d2thY1RYamwzZkRDU0pyYmpjZ2NTelhaVktqOVd3d3pQd0FPVHVSYVBINDdp?= =?utf-8?B?OFpqOFhyUllhSFgyOTdHUHFkZUw0bjFHcktra3E1azVQK21BMThWUkZ3TzBz?= =?utf-8?B?d2pTVG9EMkZjSGtLQXVJN3VGLzdLNk85MVdoY01tQWhRWGwrQ3AxdWowQ1l4?= =?utf-8?B?amtBbHBMTk1OSjFPQnFCRnluQWpOWEJoTStTeGRSOTgwS3l3TWZtSVJoMzg5?= =?utf-8?B?alBPTDNyYzR2aC9pcmFLWGxnQm1XSGNXc3ZHd0tEYnlpMDlPbU00ZUFSQzRm?= =?utf-8?B?ZmVZSmk4cW0rVW1oaWhHQmh3alJKK1NvVHlqbFoyZDgzQ3BVT1cvbVUxamJM?= =?utf-8?B?Y1BaMFpUY0NHQjdhOUJjbWw4VWFkckkvbHNNYkJ1VkNpb3lEZEtqRXdnZVF4?= =?utf-8?B?UkVIamhNbU9QQk56emo4aVYzWUppUDJpUEowdEdHQXFITzd3ZVVheHNoN21q?= =?utf-8?B?T0ZkU1ZodWpZWjZWOUlqbk53eUVuSnRMYzJJTmhZemZrSUFud3laOThZeTFy?= =?utf-8?B?MllsWTg0STRCWURMa0dycmZ4ZDJGOWIyOURpdDY3L1RoZk1IT280NTZzVGcz?= =?utf-8?B?QnN5TnNHOHlTT3dDcTlNWGtKUWo0Z1RTMnA0cUlVVmtiVUkxOHJCVTE5eVcy?= =?utf-8?Q?Xa50Wo9KaSAzz?= x-microsoft-antispam-prvs: x-forefront-prvs: 09669DB681 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(136003)(396003)(39860400002)(346002)(199004)(189003)(58126008)(81156014)(97736004)(54906003)(99286004)(476003)(1730700003)(5660300002)(106356001)(316002)(2351001)(6436002)(53936002)(4326008)(68736007)(86362001)(6916009)(6486002)(2501003)(3846002)(558084003)(82746002)(33656002)(256004)(25786009)(6116002)(81166006)(105586002)(36756003)(478600001)(102836004)(6506007)(6346003)(8936002)(44832011)(5640700003)(486006)(2906002)(26005)(186003)(71190400001)(8676002)(71200400001)(66066001)(2616005)(83716004)(14454004)(6512007)(7736002)(6306002)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4233; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: nsdKCvMZEKvANimhZd3J4K7s4RdjwsoYQ50AfOr8AYoV+Obp2pVsH1JX/hR1j2c7VtpIMRq3f8xqH7sUi7dcF5ENtthIwZMSkJNNItWzxHYxp6YLOxlZ0PdY/VJUPD6R5zFtrAUOV/LPFSxpafELAxY5qYEIQgsuANs2usAyBfLvXJbp/mRgGr+i77DvxDvHKo7hlDsPo1nt4tWMlCiIWqe5ullkk75wTKn6ELSSJoWYM9EAkLBViNOQGYueVwdtZWVXYS5IKCRDpAUeR0PhxPG9mRdqNnFRqIwkh/sDk5aZbYW4JJXPsncxDVq/gnhA/XhFWthtBEE4h1CjnRyX6ZtrHYFTBECMR3iKH8ojhofA/R0o7lTUv1E0H+B8QkYE2gz/PRQ90D92so9hLfvknmz9GnVA+Xm0RNTf81TG/rE= Content-Type: multipart/alternative; boundary="_000_AAA0624FD9FA45299AA12A81FC3ECB14ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bbf1effd-62eb-4803-9d03-08d6a0eb50b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2019 21:49:44.9368 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4233 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85246zwbvl5cHU3OiDF7wkEhqRGn0wqAzyQ9YglzupuE3b zBuNZiSpB8UwApcyZZa0MvN+waETP6QWlSR087LSVCiUvJRYK49ngt9+z//5v+/z/F9empT1 CfzoLF0eo9epNAqhmKq90FMQXlxvVEa1sfJYS/m4KLZytZGMXf/dLkwgk5qaNokkc98cdY64 KD6mZjRZ+Yw+8niaOLPb2k/k3g4sXGmbEJkQG1CBPGjAMVDVOS6oQGJahkcQsI5Vgi/WEXyc +4v4wkoAe+chyRUUriZh6l+l21ZDwPPFFbfNiWBxfk1YgWhaiGOBdYVxQ7xwCDRvdIk4mcSp 8Kn7Jifvx8HQPbFF8ZZweFA16OYI6G1jRRxT+BB01rCIYwmOhxG2TMAxwj7wa+wpwTGJfbc3 tRB8HgxNA69Jnr1h6atrx++NI6Gzapbi9UCoc3SJeA6ACQt/P+AzYH/hEHJRAH9AYJkuE/KN UKge6CX5RqkMHCaT+0Q2TJVPuqf5w+bbabe+IoDmUh3HMsxAc0sp4rdWwaBtltzdwlbppKpR mHlPCJ7ToaOxBJl3QkthtHaOMu+8XQi09kfyFjncY50inoOhtK7ezUlg/zIk2OtpQLQNeRsY wxVtRnR0BKPPSjcYcnQROiavHW1/KEfnVlQvWlpIHEaYRop9EnmhUSkTqPINRdphBDSp8JIc SdiWJGpVUTGjz7msv65hDMPoAE0pfCV/ZFKlDGeo8phshsll9LtdgvbwM6GDelUcdcpZOCNN ncnxHNhUtLxzBT222k8W2HyWpyKXldN98UFG7dAl6tF3zyclKZOm5AVj8vvPL4dm5edvxLz6 meKiFhLjla1CddhMw9nKnO6W9R/R93O13yjJ6Z75N3H+cqu245l5dC3t6sayNHWs9m7YmPqW ffHaCftRjQ+loAyZqsOhpN6g+g8a9di7TAMAAA== Archived-At: Subject: [sipcore] Draft new version: SIP Push -27 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 21:50:00 -0000 --_000_AAA0624FD9FA45299AA12A81FC3ECB14ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkJhc2VkIG9uIEJlbuKAmXMgYW5kIFllaG9zaHVh4oCZcyBjb21tZW50cywgSSBoYXZl IHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uICgtMjcpIG9mIFNJUCBQdXNoLg0KDQpUaGUgY2hhbmdl cyBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGFyZSBtYWlubHkgZWRpdG9yaWFsLg0KDQpSZWdh cmRzLA0KDQpDaHJpc3Rlcg0K --_000_AAA0624FD9FA45299AA12A81FC3ECB14ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <117EC4395802BD42B51A19756B0DE8D4@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRkkiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+QmFzZWQgb24gQmVu4oCZcyBhbmQgWWVob3NodWHigJlzIGNvbW1l bnRzLCBJIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gKC0yNykgb2YgU0lQIFB1c2guPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPlRoZSBjaGFuZ2VzIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gYXJlIG1haW5s eSBlZGl0b3JpYWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkNocmlzdGVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AAA0624FD9FA45299AA12A81FC3ECB14ericssoncom_-- From nobody Mon Mar 4 21:15:36 2019 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 34CBC1200D7; Mon, 4 Mar 2019 21:15:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org, Brian Rosen , sipcore-chairs@ietf.org, br@brianrosen.net, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155176292818.5224.17119790703710957363.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2019 21:15:28 -0800 Archived-At: Subject: [sipcore] Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 05:15:28 -0000 Adam Roach has entered the following ballot position for draft-ietf-sipcore-reason-q850-loc-06: 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-reason-q850-loc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for taking on the task of adding this value. I have a handful of comments, one of which really needs clarification prior to publication. --------------------------------------------------------------------------- This issue is a discuss because the lack of formal language for values and the lack of clarity around case sensitivity has interoperabilty implications. §4: > The Augmented > BNF (ABNF) [RFC5234] for this parameter is shown in Figure 1. Figure 1 is not valid ABNF. It contains ABNF, and then has a whole bunch of other stuff. I suspect you wanted to have something more like this, using RFC 7405 extensions: reason-extension =/ isup-cause-location isup-cause-location = "location" EQUAL isup-location-value isup-location-value = %s"U" / ; for 0 0 0 0 user %s"LPN" / ; for 0 0 0 1 private network serving the local user %s"LN" / ; for 0 0 1 0 public network serving the local user %s"TN" / ; for 0 0 1 1 transit network %s"RLN" / ; for 0 1 0 0 public network serving the remote user %s"RPN" / ; for 0 1 0 1 private network serving the remote user %s"LOC-6" / ; for 0 1 1 0 spare %s"INTL" / ; for 0 1 1 1 international network %s"LOC-8" / ; for 1 0 0 0 spare %s"LOC-9" / ; for 1 0 0 1 spare %s"BI" / ; for 1 0 1 0 network beyond interworking point %s"LOC-11" / ; for 1 0 1 1 spare %s"LOC-12" / ; for 1 1 0 0 reserved for national use %s"LOC-13" / ; for 1 1 0 1 reserved for national use %s"LOC-14" / ; for 1 1 1 0 reserved for national use %s"LOC-15" ; for 1 1 1 1 reserved for national use If you choose to instead keep the current formulation, please: - Move the list of valid values out of the figure, and - Add text clarifying whether the values are case-sensitive. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ID Nits reports: == Unused Reference: 'RFC3261' is defined on line 245, but no explicit reference was found in the text == Unused Reference: 'RFC3323' is defined on line 251, but no explicit reference was found in the text --------------------------------------------------------------------------- §1: > [RFC3326] specifies that a ISUP [Q.850] > cause code can be carried within a SIP response This isn't quite right -- interpreted carefully, RFC 3326 specifically does *not* allow this: it envisions specific future response codes (in theory used to help with HERFP) that opt-in to allowing the Reason header field. When speaking of the general use case of sending Q.850 codes in arbitrary SIP response messages, you need to cite RFC 6432 instead of RFC 3326. --------------------------------------------------------------------------- §4: > As defined by [RFC3326] a Reason header field MAY appear in any > request in a dialog, in any CANCEL request and in any response whose > status code explicitly allows the presence of this header field. As above, I think we're talking about the more general case (rather than the "explicitly allows" case); if so, this text should cite RFC 6432 and clarify that "Any SIP Response message, with the exception of a 100 (Trying), MAY contain a Reason header field with a Q.850 [Q.850] cause code." --------------------------------------------------------------------------- §5: > SIP/2.0 404 Not Found > > From: Alice ;tag=1234567 Please remove the blank line between the response line and the first header field. Please add at least one "Via" header field, or add text indicating that Via header fields have been removed for concision. From nobody Tue Mar 5 02:57:01 2019 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 7CCED131059 for ; Tue, 5 Mar 2019 02:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=OUL0y/YL; dkim=pass (1024-bit key) header.d=ericsson.com header.b=DzVlt//d 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 LupmdFVgCyMj for ; Tue, 5 Mar 2019 02:56:56 -0800 (PST) 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 6A18E13106E for ; Tue, 5 Mar 2019 02:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551783414; x=1554375414; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=txqF6QKxap4XXIw4E8+E8wPW8/IZOh0hhOzC8yCXpN0=; b=OUL0y/YL3l2fcWL9GYnwVcrA8QFKEVD8StKd8TF3M88dHr5jsKVQ7srdboMhSfMr 4pyLS0YuqJYBeK0g1MffokjmPwQbnPWvkyqJm1OPF4LBmo72XM61EfvfmKNBBq1I 1KI/N/AfwH5b6bNLKwz9mJN+H8bJ9cQPCAjPChNnWcg=; X-AuditID: c1b4fb3a-5c9c29e00000672c-42-5c7e55f6a7f9 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EF.1D.26412.6F55E7C5; Tue, 5 Mar 2019 11:56:54 +0100 (CET) Received: from ESESBMR501.ericsson.se (153.88.183.129) by ESESSMB501.ericsson.se (153.88.183.119) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 11:56:52 +0100 Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESBMR501.ericsson.se (153.88.183.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 11:56:52 +0100 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 5 Mar 2019 11:56:52 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=txqF6QKxap4XXIw4E8+E8wPW8/IZOh0hhOzC8yCXpN0=; b=DzVlt//dZUxrf9DTJ2ZK3Sc/wS1Cgy7JBnZKQAJInh+PltPChOmpqwurI163BUPwjz5rucFuR/l6kvtb/FirQ5JHe39zutu1cik74jTJmRnyuNSEshdkOHf2kxqGZmfQzP1GhxOJkU9En/2wq+USCiG8//m/+jppp7rXzuIwo30= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4380.eurprd07.prod.outlook.com (20.176.167.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.15; Tue, 5 Mar 2019 10:56:51 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae%3]) with mapi id 15.20.1686.016; Tue, 5 Mar 2019 10:56:51 +0000 From: Christer Holmberg To: "sipcore@ietf.org" , Ben Campbell CC: Yehoshua Gev Thread-Topic: SIP Push (-27): Minor syntax nit in REGISTER example Thread-Index: AQHU00IjXtJk+1ctcECmJNKUbS/4bw== Date: Tue, 5 Mar 2019 10:56:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 648ce74c-81bc-4f93-7672-08d6a15945e3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4380; x-ms-traffictypediagnostic: HE1PR07MB4380: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUI0MzgwOzIzOmtVeGQ4WUhEZ1lPZGt2a0VmMnd1VW9DdXVZ?= =?utf-8?B?UFM3aWFxSnlaMTR5ZEI0Y3AyYVBiYUJhSFR6K3Y3anJ0YnF6aWZ2S0drVDNW?= =?utf-8?B?MEUwSkV3ZWtjcDZsNW9mVkdDR0F5ZTBFalRRYzI2THB3MVpJaFY2NDBycGlW?= =?utf-8?B?bXVEeGdTYkV6WnEydTZKc2xvYTlOTGpSSlROSWFnNzVSMERsakVyTlo0b3Rk?= =?utf-8?B?NExJb2hIK0tSbTYrODNPUk45UitMR3cvck9UV1lHN1JuY0JNOTFGRjVFUjZS?= =?utf-8?B?bUdacGtVYnQwcW84amVSR2xzWk1TRkFpSTRsUVFsTzNtVHJlRlc4RkNJVWJW?= =?utf-8?B?QXIzcmJFKzBwRVJyVTFubFdaOXJVS21YbWl2Mkkwb3pTOS9lTVJRWlViYnA5?= =?utf-8?B?eUNSeFZYVHRFajBBd0h1a2YvblE4ek9OVVBLaW9aU2dUeFIxSGFCV2s4dXZl?= =?utf-8?B?c1lCYUVUem5JVkMrYWdLMXp0dEJPWlZHMDFKTUVaNEV5aW5rcUNZQ3pzS3FZ?= =?utf-8?B?UjVyRTBxcU5aNS8rbnJEVDJMcUpJQmZnTXJHZWtSN2N6WkhTU3Z2SDZJaUpQ?= =?utf-8?B?Zk1aS1hSR2pObHdLN0FUMmNscllyMWFPTDlzVjEwb1l6MlFrT0tMYUNVUk1s?= =?utf-8?B?ODZVQWhPZmVWZXIvVDNSenRvTndKMTlsMjRvQmpGZ2RFQWhyNXNCWEc5c21o?= =?utf-8?B?YjA0TXdKVjgrOVRLRzJBSzRLWFdnV3JGcmFsS0JZSFJISURlRUp5SXZrc0Z1?= =?utf-8?B?djdpZjB5RzI0dFBNTW5zQ0NFSU5CdlVGVFRTMnhlMUVaaVZQMndSVHRyMFoy?= =?utf-8?B?cFVLTVd3cGxSdGFEL3Z1RmJCcWJkMmw1a3JxajE2cTJ0MmdzZzhrY2F5Y2d5?= =?utf-8?B?VkhhUGdUWWRCL2F5dlRnU3FrWThCOXdDVXZ5Q1lHc2RaNVhjMVpheFdYRDZH?= =?utf-8?B?VW9QMG53MDhBbXd5SlU1L3h4UHBKa2xISi85ZjA4clB0Y01qa3pvamF5QXFu?= =?utf-8?B?eE1LTWtVNENoNFNLckM2Yng4RkRZYUFJcTBWTDlJVnBSMDM3Q1lHMUtsbzVp?= =?utf-8?B?M3BvWGpHMUdiSzhGeXdiR2w3K3orU0hBZGQvQWR1QXpCV1pNb211S3hIMjlG?= =?utf-8?B?NFZUVXI5Tm1neTRyQjdjRXU5T3dJcUJ3VVdVQUtHL0F4VHVaU3JPbUFtTmU5?= =?utf-8?B?ZnFQaXVQRXBKMmtSR2NRaEZWOTBWcG1wS2FwNEJYTndyRC9LS0wxWmVmQkt6?= =?utf-8?B?VkFhT3A0VGcxQllBVkxFeTBrRDRmbDJaemVLVisrMkJyYnFBY1NkZWJlUFQ4?= =?utf-8?B?U2Y4NmNGNEVTeUM0TEVFSTdRbWdKb0xJbEhNRUZVM24vdFNaNU04eXlsWWRm?= =?utf-8?B?TEp2TldtL2JmbjdxeWgxNEZrbTZHbUs5OWZ3a0FIVGZOdFliMzJJaHpZcjdh?= =?utf-8?B?RFoxNGxZRjcxVXcvMDdwUmpoQVAzUE4ybmpXZi9Oa2VBMjU3S3NhWXlSU1Y2?= =?utf-8?B?NUJDcmFHTWZXVzdDZlVYa0J3djZxeU9GV3FwdUxkUnpQbGJEb05yMkVsSWtX?= =?utf-8?B?cFJ0ZlZBTHVyakVpL2lLRjlNZnMzK0xSSFc1bHQvMlhFVTZkaHVOWVVsckxm?= =?utf-8?B?UXdBTExlb2YzQVpsQzkxRDVaeGtvZ2tqRUEyclJ3Qi8yMmZYZW5VS2xjUkhN?= =?utf-8?B?UmF5aHI1V3FBT2thNi9oRzZ0cGhLWW5qL2grOWI4ZlZ2NnlaRXRRS0hCeEhX?= =?utf-8?Q?0sC6sro+yL8qCPyexp9VsVg6h6XfgDRSXkbok=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(366004)(396003)(39860400002)(376002)(189003)(199004)(316002)(81156014)(71190400001)(6486002)(99286004)(86362001)(4326008)(66066001)(486006)(53936002)(606006)(3846002)(6116002)(6512007)(83716004)(25786009)(68736007)(6506007)(102836004)(26005)(71200400001)(256004)(476003)(6306002)(54896002)(2616005)(97736004)(2501003)(236005)(6436002)(44832011)(14444005)(966005)(186003)(36756003)(478600001)(5660300002)(33656002)(82746002)(14454004)(2906002)(8936002)(58126008)(105586002)(106356001)(110136005)(558084003)(7736002)(8676002)(81166006)(554374003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4380; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: LOzOGaJhUgQB0zA+kky94fKKvUO4ujvI+INybwFOaIKF00sqdESN8lcVRIcYw4gWY1cCCJaRufbkDfg1i/PD7RThd1mpADoonVsWdQk3ti95biOPHuYprPFJpsAI8V2xzCjg3f3DUnR7gdGHomgml9/nxzZduMr5xy6W5sNNIz8VoZ1F4DLCFWm//lNQMYm3P5NwfaBjP86jVu98c72MG31E3K++N9M/I0ypg9rUqbTo5zxVhyfjW5j4axuGLzg8/+joxBF6FJG/n9OATuZ1WtnMBHdV2JP10K6Mha6uUvuCE2afJpCslNahn3Tbl0r+QqANZ32Q6PO/RmzsOahlixOHxU7tP2KOXErO3s9mP7ZD1+Fhyc/+ckT0BMht0ocpaYAm3iPtni9yaJSSx4YqM87vCX5aPwebe4BVxbdN/7s= Content-Type: multipart/alternative; boundary="_000_E55DB41244C049BEB7C4E9B23F5198A7ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 648ce74c-81bc-4f93-7672-08d6a15945e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 10:56:51.4468 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4380 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfyyUcRzH932e+/G43Pre+fVJ2nLDpCFmTa1SpnZpbfyRXc3o4hm6c3SP FC0TqTnTRGu5/FquH2TCrFInY5hEougU5Vdr3Ia2JNyUx3M1/70+n+/r/fl+P9uXIqXNfGcq QZNCazVKtUwg4hUrnl3w/nUiI3JXbp9rYHnuG2Hgwu8GQeBK/Sh5kJQ36UeFcoNhiZDrm6Z4 YeQp0b5YWp2QSmt9D5wWxfeb/vCTTa4XX35RZ6L323XIhgIcAA+znvJ1SERJcTuC+g6DkCsW EJgNN9H/4sO9x1atkoD8EjPBFjxcQML08oxVKySgoKxGwBXjCJq/DaxlKEqAAyFvdSd7oz0+ CnV9dXyWSewO2a2rQpbt8H4oMpgIzgmGslwjYqP22Ae6jWfYNg+7gW62WsCyGAdBbad5fQzC jrDYXUNwI53g01Q5wS2HwWDsIzl2gOnJ1XXfAftC440xHpdVQkv1mNVxhd7ZcWt2GwyU5yGO j0PbZA7JrgV4GMHdHqM14AUz7b3WgDN09XfwOWlQAvMtwyS7AGAV1BoiOHSBuZ9CTjHzIfva R34B8tZveDfHMdA5MkHq1/eUwOviKZ5+LU7iHfDkhS+nuMKtvHEhx56QU1JqZTmUDlnQRqcC UdXIgaEZJjHO39+H1ibEMEySxkdDpzSgtU/V2riy9zlq/X6oDWEKyWzFj8IyIqV8ZSqTltiG gCJl9mKL01pLHKtMS6e1SdHa82qaaUNbKZ7MSWyRSiKlOE6ZQqtoOpnW/jslKBvnTKTI9tg8 UijLUkStSDwUGbZGXeiDqq8/0h0iC6+Ex2bdOSd7mxA8UfROrw87e1JhejW5JT8kvaVrU0Dh kQj31SGVxH6gwjd6UW53X06EeF4eWXJrTbseHiFzHFIGJYYGVDbOo2PLLovGqZTbl5qQarDq 6m56zmIOOvw5yiL369kj4zHxSj8vUsso/wLkvYluUAMAAA== Archived-At: Subject: [sipcore] SIP Push (-27): Minor syntax nit in REGISTER example X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 10:57:00 -0000 --_000_E55DB41244C049BEB7C4E9B23F5198A7ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgcmVhbGl6ZWQgdGhhdCBJIG1ha2UgYW4gZXJyb3Igd2hlbiBJIGFkZGVkIHRoZSBm ZWF0dXJlLWNhcGFiaWxpdHkgaW5kaWNhdG9yIGV4YW1wbGUgdG8gdGhlIFNJUCBQdXNoIGRyYWZ0 Lg0KDQpJIGhhdmUgY3JlYXRlZCBhIHB1bGwgcmVxdWVzdCB0byBmaXggdGhhdDoNCg0KaHR0cHM6 Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LXNpcC1wdXNoL3B1bGwvMzkNCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg== --_000_E55DB41244C049BEB7C4E9B23F5198A7ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <26074217D08F4740911EDC8402455AFA@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRkkiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+SSByZWFsaXplZCB0aGF0IEkgbWFrZSBhbiBlcnJvciB3aGVuIEkg YWRkZWQgdGhlIGZlYXR1cmUtY2FwYWJpbGl0eSBpbmRpY2F0b3IgZXhhbXBsZSB0byB0aGUgU0lQ IFB1c2ggZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgaGF2ZSBjcmVhdGVkIGEgcHVsbCByZXF1ZXN0IHRv IGZpeCB0aGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY2RoNHUv ZHJhZnQtc2lwLXB1c2gvcHVsbC8zOSI+aHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LXNp cC1wdXNoL3B1bGwvMzk8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkNocmlz dGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E55DB41244C049BEB7C4E9B23F5198A7ericssoncom_-- From nobody Tue Mar 5 08:17:58 2019 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 EB5341312D1; Tue, 5 Mar 2019 08:17:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org, Brian Rosen , sipcore-chairs@ietf.org, br@brianrosen.net, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155180267092.24542.9279801879471150412.idtracker@ietfa.amsl.com> Date: Tue, 05 Mar 2019 08:17:50 -0800 Archived-At: Subject: [sipcore] Suresh Krishnan's No Objection on draft-ietf-sipcore-reason-q850-loc-06: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 16:17:51 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-sipcore-reason-q850-loc-06: 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-reason-q850-loc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * I was trying to read up on the Q.850 spec and I found out there was a much newer version (20 years newer) that has superseded the referenced version. Is there a particular reason to refer to the 1998 spec instead of the 2018 spec? * I have a hard time seeing why this document needs to define names for the spare codepoints (LOC-6,8,9,11). Either they won't be used (in which case we do not need to define them) or they will be defined in a future revision of Q.850 (in which case they will most likely get a different name). From nobody Tue Mar 5 11:20:23 2019 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 A1B5E12D829 for ; Tue, 5 Mar 2019 11:20:21 -0800 (PST) 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, 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 EedZmvbVR7dH for ; Tue, 5 Mar 2019 11:20:19 -0800 (PST) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73E112D4F3 for ; Tue, 5 Mar 2019 11:20:19 -0800 (PST) Received: from PaulKyzivatsMBP.localdomain (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.14.7/8.12.4) with ESMTP id x25JKGfr018501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 5 Mar 2019 14:20:17 -0500 To: sipcore@ietf.org References: <155180267092.24542.9279801879471150412.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: Date: Tue, 5 Mar 2019 14:20:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <155180267092.24542.9279801879471150412.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Suresh Krishnan's No Objection on draft-ietf-sipcore-reason-q850-loc-06: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 19:20:22 -0000 Suresh, On 3/5/19 11:17 AM, Suresh Krishnan wrote: > * I have a hard time seeing why this document needs to define names for the > spare codepoints (LOC-6,8,9,11). Either they won't be used (in which case we do > not need to define them) or they will be defined in a future revision of Q.850 > (in which case they will most likely get a different name). I was the person who originally pushed for these to be included. You can find the discussion thread about it at: https://mailarchive.ietf.org/arch/msg/sipcore/-YTDdZW3uQRel8u6JOeRzkqCZ9M Thanks, Paul From nobody Tue Mar 5 12:02:14 2019 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 76B691312D7; Tue, 5 Mar 2019 12:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 wasDlAfE5Uoh; Tue, 5 Mar 2019 12:02:10 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230D0131398; Tue, 5 Mar 2019 12:01:23 -0800 (PST) Received: from mutabilis-2.local ([47.186.39.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x25K1L9F048976 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 5 Mar 2019 14:01:22 -0600 (CST) (envelope-from mahoney@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551816082; bh=au0d91XwD5Pg1jFRou8ujl9O/V7l4wicwjj/8xAHH/M=; h=From:Subject:To:Date; b=W2Trzym3SfZMhkOtw/Lf2A/o2EUD4QAQe0QvywpTZgSLW8SxtpYeM8IIO6H8zfeqM 3Qj5Ev3DcQExlhXR9sczFJLAEFD+XQV8uGHCg7a1iE089LNh7Z0zLDRP7/+v8+5UcX 99XN+Wi426xlGVBhGGJ3VsFF93BFF1q/HBqvskeg= X-Authentication-Warning: raven.nostrum.com: Host [47.186.39.7] claimed to be mutabilis-2.local From: "A. Jean Mahoney" To: draft-ietf-sipcore-rejected@ietf.org, SIPCORE Message-ID: <6fc6d835-a4c5-1fc1-677b-0ac14c241a6f@nostrum.com> Date: Tue, 5 Mar 2019 14:01:21 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] draft-ietf-sipcore-rejected Terminology X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 20:02:13 -0000 Hi Eric and Bhavik, I've been working on the Document Shepherd write-up for the sipcore-rejected draft. The draft's Terminology section and the normative text that uses the term "UNLESS" need updating: 2. Terminology This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. As a matter of principle, this document uses the term "UNLESS" to distinguish when a "SHOULD" means "MAY". Otherwise, the "SHOULD" means "MUST". Without UNLESS, SHOULD is meaningless. A.k.a. Burger's Law of Protocol Meaningless Terms. The following two statements are covered by the "UNLESS" addition: [1] If an intermediary issues a 608 code, the intermediary SHOULD include a Call-Info header in the response, UNLESS there are indicators the calling party will use the contents of the Call-Info header for malicious purposes (see Section 6). [2] As such, the intermediary SHOULD play the announcement, UNLESS the caveats described in Section 3.5 and Section 6 hold. Would you rewrite these statements so that they only use the key words described by [RFC2119][RFC8174]? As the statements are currently constructed, it would be somewhat difficult for an implementer to know what to do since both statements point to largish sections of descriptive text. Thanks! Jean From nobody Tue Mar 5 14:24:56 2019 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 EE0A312D7EA; Tue, 5 Mar 2019 14:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.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 82WLvl-aisKi; Tue, 5 Mar 2019 14:24:53 -0800 (PST) Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [198.46.93.79]) (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 2903112008A; Tue, 5 Mar 2019 14:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=References:To:Cc:In-Reply-To:Date:Subject: Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To: Content-Transfer-Encoding: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=AmY8Q8N9j1DeO8Q16p6GU+bFBXFHQ18AGW+NJwo1Tt8=; b=rvd+2O4c5+MXLyPPGe/2pOgzZ rzFtOWGeBKwWDaYE54XUjtoRIM+Akn1/E2aKxwMTGsRG/gL0S9Lmw8mzYWqxDk6bZp+mNVh+nvzdn B2wbnkAZivhIDjFB5WHalgjV5nAk8ORICqy5lyt0tKDkojhaCi3nrjpFYTUhf189bRaDc=; Received: from [184.81.92.57] (port=53071 helo=[172.31.99.170]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h1IUQ-009xX3-6m; Tue, 05 Mar 2019 14:24:51 -0800 From: Eric Burger Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_2B70F359-F0AE-4B67-93A9-7FEC654284A5"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 5 Mar 2019 16:24:45 -0600 In-Reply-To: <6fc6d835-a4c5-1fc1-677b-0ac14c241a6f@nostrum.com> Cc: draft-ietf-sipcore-rejected@ietf.org, SIPCORE To: "A. Jean Mahoney" References: <6fc6d835-a4c5-1fc1-677b-0ac14c241a6f@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-rejected Terminology X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 22:24:55 -0000 --Apple-Mail=_2B70F359-F0AE-4B67-93A9-7FEC654284A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Grumble, grumble. That=E2=80=99s my civil disobedience to (1) put the = 2119 language into active voice and (2) point out that SHOULD is useless = without UNLESS. The various levels of folding on my part would be: (1) leave it as is (2) cut the second Terminology paragraph and turn the =E2=80=98UNLESS' = instances into =E2=80=98unless' instances. (3) cut the second Terminology paragraph and remove the unless clause, = turning the SHOULD into the useless SHOULD. (4) cut the second Terminology paragraph and use the evil passive voice = version of the 2119 Terminology paragraph, written by non-writers How low shall I go? ;-) I=E2=80=99m willing to go all the way if = demanded, but my vote would be to keep the language as is. However, = it=E2=80=99s only one vote - I=E2=80=99m the editor not author and = it=E2=80=99s a work group document, so I will bend to the will of the = work group. > On Mar 5, 2019, at 2:01 PM, A. Jean Mahoney = wrote: >=20 > Hi Eric and Bhavik, >=20 > I've been working on the Document Shepherd write-up for the = sipcore-rejected draft. The draft's Terminology section and the = normative text that uses the term "UNLESS" need updating: >=20 > 2. Terminology >=20 > This document uses the terms "MUST", "MUST NOT", "REQUIRED", = "SHALL", > "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only > when, they appear in all capitals, as shown here. >=20 > As a matter of principle, this document uses the term "UNLESS" to > distinguish when a "SHOULD" means "MAY". Otherwise, the "SHOULD" > means "MUST". Without UNLESS, SHOULD is meaningless. A.k.a. > Burger's Law of Protocol Meaningless Terms. >=20 >=20 > The following two statements are covered by the "UNLESS" addition: >=20 > [1] > If an intermediary issues a 608 code, the intermediary SHOULD = include > a Call-Info header in the response, UNLESS there are indicators the > calling party will use the contents of the Call-Info header for > malicious purposes (see Section 6). >=20 > [2] > As such, the intermediary SHOULD play the announcement, > UNLESS the caveats described in Section 3.5 and Section 6 hold. >=20 >=20 > Would you rewrite these statements so that they only use the key words = described by [RFC2119][RFC8174]? As the statements are currently = constructed, it would be somewhat difficult for an implementer to know = what to do since both statements point to largish sections of = descriptive text. >=20 > Thanks! >=20 > Jean >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_2B70F359-F0AE-4B67-93A9-7FEC654284A5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEfEc/N7T7IfiAuDEHDDCGh758rskFAlx+9y0ACgkQDDCGh758 rskamw//RxHg6WfD9VixGhTW58o2MloFyICUcrOIUUpPWBVuxo+z+YAsXRRlbEYd 59psncsYZBJQi14rq90SM7O7B/z4oaa3kCFcDCeeMstMEcDSGCkOA39jtDtGOk4T cZFXRAv+trohTFjQHWF+fLk9OGNYsxnmWEFXFfZIkw6I0MHMNwm4PiSyt/wtOWQh HqFx/g++Dcwdb7hrRH9fkjEx7nG6NfnWnox9Tz1VWHmpmCkQtxu2N4ZWdPUNHrdO X06higQaT1oPxzLK9AoVzTK3hwrMePo9tzc8VcLiw0Zj6huqPcKU2jmkpLIIbDuK GTOV7gk8W6cEkPsTs5qyjgPfuphqF9eqKiArAnr1mL4khc0wunzSPM9ka3B5yS/V iy90m5+RouB0nTaNDitvreLO9WXhUlecRC/huAkdemZPSnElPho8uwUBpin69cUB ppBdYv9ZX35Rm+KLSbfDxZFLTk5JPHxSXklZDheGDqss7lkiSfZi1CKbq5Tqr7k/ cLtVgdBWgFadYw3mlAnmsFgIcHW4YB6izDQz7exh+0sIJvPgg6FnEwpsTnD6L/bm Y+SWGfHGh2pjtSn3nWjK1CKknruN6UULzyJtDzmLBDx4Y1XAqYhLOicbTzlvt9Hs M5Ilcm7oDjnBhSy/9CJ8RF4dTdgGcLf2Jhb6YeA4rop4L6IROjk= =qkdH -----END PGP SIGNATURE----- --Apple-Mail=_2B70F359-F0AE-4B67-93A9-7FEC654284A5-- From nobody Tue Mar 5 19:58:59 2019 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 B034E130E8A for ; Tue, 5 Mar 2019 19:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.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 jLAiobzIxNxS for ; Tue, 5 Mar 2019 19:58:49 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764F4130E8B for ; Tue, 5 Mar 2019 19:58:47 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-09v.sys.comcast.net with ESMTP id 1NeVhBLcsQNsN1NhehfW0a; Wed, 06 Mar 2019 03:58:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1551844726; bh=XB4RQgCAsrG32tnHFx403UQuzzCOWyJsGWvQ+iqHtd8=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=aI/hIRNhfYgUCwhuSQr4dMq0/ss6eCgc0ClkF9e3keIF6pLGrA484jsU3y80jyI5n 2xM3qoFW2vpnf/dYH3alkLFAOF6QBCvljE81KxlEMaWA3LzgI68HtZhwameT9qvtSI mvGZ8vlOLkMSe3jHeOx3Nkj1ek0vEuf43j+f8pHw2V8+4xlYefA8hw5TolQMWCnwNK ar4mgrcF0nE0g5Sb7wOC7/xcCM0YT2taUze1HXONKF9ZnjEiIk5cQeWIh0Bb5VHdyv KM7y0e6h7S6Y/rd9rpc5FGr6XybGb6WBni8VSM0gvAwF/9xwsSOJXU8Jvx3cEGM7FV rWvm7zO46rg+Q== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-07v.sys.comcast.net with ESMTPA id 1NhdhT3vk19IP1NhdhjtAY; Wed, 06 Mar 2019 03:58:46 +0000 X-Xfinity-VMeta: sc=-100;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id x263wifo001370; Tue, 5 Mar 2019 22:58:44 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id x263wiwS001367; Tue, 5 Mar 2019 22:58:44 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Suresh Krishnan Cc: iesg@ietf.org, draft-ietf-sipcore-reason-q850-loc@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org In-Reply-To: <155180267092.24542.9279801879471150412.idtracker@ietfa.amsl.com> (suresh@kaloom.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 05 Mar 2019 22:58:43 -0500 Message-ID: <87tvggd570.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [sipcore] Suresh Krishnan's No Objection on draft-ietf-sipcore-reason-q850-loc-06: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 03:58:51 -0000 Suresh Krishnan writes: > * I have a hard time seeing why this document needs to define names for the > spare codepoints (LOC-6,8,9,11). Either they won't be used (in which case we do > not need to define them) or they will be defined in a future revision of Q.850 > (in which case they will most likely get a different name). My memory is that the spares are used by some systems and/or there is a worry that the spares might be used by some systems in the future. Since the Q.850 value is fixed at 4 bits, by assigning SIP names to correspond to all 16 possible values, we don't need to define a procedure for creating new names for values that might be used in the future. Dale From nobody Wed Mar 6 06:28:30 2019 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 AD4911224E8 for ; Wed, 6 Mar 2019 06:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.01 X-Spam-Level: X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 j3sT4re36yLn for ; Wed, 6 Mar 2019 06:28:25 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 72902126DFA for ; Wed, 6 Mar 2019 06:28:25 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id z25so12958294qti.13 for ; Wed, 06 Mar 2019 06:28:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2r+8B3OEIOhqFdldfekecovdyY88L7NeHUgcM0Ze0RM=; b=uzRyD94qvPOPz5EYs8AtxXzT8ELBHClPedbd7sOvOB29/l2y51s3mqPykAEMNnxtXa ywh7T8e3DMQ+XemJpQ0rPZxV0c95DJwW8bipm4XcDNKnzmpMqmYB43Zg9JGJ5abZeGPG d6oPworLaY1cgXcjpHhcOoEd6tbujAMfajoxwq2VAHhWGjx9J4O0iHdNpmMSohlBifbD DUMLdhtvGg9iIaIyLzSC1/i/7ywMr4GAQnhIfsN9vb+S4FZdQPtkjcKqAS9zdESf7hOW Xug5DbkpTPaNG+k6ksUdgKSG99faK6S+UimXSYR47O26WYGFF3dhOdPZvc5IvP143hED WPPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2r+8B3OEIOhqFdldfekecovdyY88L7NeHUgcM0Ze0RM=; b=oRVQLhsf3RJbwbiFskveMQ+YaV4qwH6DY1JJpWz7Sc5dV3NHSAgBxK0sJKr1w/7ZZ3 QLTQ0dQc/OIs9cKLjOS/b5ZkX+1Zy+YOAQUBv8DEn6buUnQqXWo4Ib723RwRnXxg897J EszZeLnOZjdWFQ9XXNa6PXz5+JmmWh1K3oNYShDV7JhWtXg4d5kY03kxyVhKGu6Nw6xF LgSvd3L8jt+YIvsoZjWmbZI+IwfyBGSWrtz/PZWXHQyY1w9zOwQ9MAshwVNUHLAMS63m LrdWpYeCkRqtQQT+f3k3bHcsT3eSZhwEdxzJqjEL6CqZMaCVYywbVNn9fdcgwwbdRBuQ 1Nfw== X-Gm-Message-State: APjAAAU9j5Ig2xWGk8DsAG2RmtuLe7TduS8TeBnTrhQIpQwMalbmTwSv czS0cciPllGq5db5Bs+DmDEPdcgjgQo= X-Google-Smtp-Source: APXvYqwq1j5jpmUA89MQhCYxEVie2es9w8HRJWVaqvCa1/UP4VHdrYpnY4poXLSE8CsR8IG8vbq1AQ== X-Received: by 2002:ac8:23e5:: with SMTP id r34mr6021840qtr.351.1551882504302; Wed, 06 Mar 2019 06:28:24 -0800 (PST) Received: from brians-mbp.lan ([24.129.255.66]) by smtp.gmail.com with ESMTPSA id y11sm1374498qky.2.2019.03.06.06.28.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Mar 2019 06:28:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Brian Rosen In-Reply-To: Date: Wed, 6 Mar 2019 09:28:22 -0500 Cc: "A. Jean Mahoney" , draft-ietf-sipcore-rejected@ietf.org, SIPCORE Content-Transfer-Encoding: quoted-printable Message-Id: References: <6fc6d835-a4c5-1fc1-677b-0ac14c241a6f@nostrum.com> To: Eric Burger X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-rejected Terminology X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 14:28:29 -0000 5) Cut the second Terminology paragraph. Reword the instances into If = MUST else SHOULD, but be explicit about the condition. > On Mar 5, 2019, at 5:24 PM, Eric Burger = wrote: >=20 > Grumble, grumble. That=E2=80=99s my civil disobedience to (1) put the = 2119 language into active voice and (2) point out that SHOULD is useless = without UNLESS. The various levels of folding on my part would be: >=20 > (1) leave it as is >=20 > (2) cut the second Terminology paragraph and turn the =E2=80=98UNLESS' = instances into =E2=80=98unless' instances. >=20 > (3) cut the second Terminology paragraph and remove the unless clause, = turning the SHOULD into the useless SHOULD. >=20 > (4) cut the second Terminology paragraph and use the evil passive = voice version of the 2119 Terminology paragraph, written by non-writers >=20 > How low shall I go? ;-) I=E2=80=99m willing to go all the way if = demanded, but my vote would be to keep the language as is. However, = it=E2=80=99s only one vote - I=E2=80=99m the editor not author and = it=E2=80=99s a work group document, so I will bend to the will of the = work group. >=20 >> On Mar 5, 2019, at 2:01 PM, A. Jean Mahoney = wrote: >>=20 >> Hi Eric and Bhavik, >>=20 >> I've been working on the Document Shepherd write-up for the = sipcore-rejected draft. The draft's Terminology section and the = normative text that uses the term "UNLESS" need updating: >>=20 >> 2. Terminology >>=20 >> This document uses the terms "MUST", "MUST NOT", "REQUIRED", = "SHALL", >> "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >> "OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only >> when, they appear in all capitals, as shown here. >>=20 >> As a matter of principle, this document uses the term "UNLESS" to >> distinguish when a "SHOULD" means "MAY". Otherwise, the "SHOULD" >> means "MUST". Without UNLESS, SHOULD is meaningless. A.k.a. >> Burger's Law of Protocol Meaningless Terms. >>=20 >>=20 >> The following two statements are covered by the "UNLESS" addition: >>=20 >> [1] >> If an intermediary issues a 608 code, the intermediary SHOULD = include >> a Call-Info header in the response, UNLESS there are indicators the >> calling party will use the contents of the Call-Info header for >> malicious purposes (see Section 6). >>=20 >> [2] >> As such, the intermediary SHOULD play the announcement, >> UNLESS the caveats described in Section 3.5 and Section 6 hold. >>=20 >>=20 >> Would you rewrite these statements so that they only use the key = words described by [RFC2119][RFC8174]? As the statements are currently = constructed, it would be somewhat difficult for an implementer to know = what to do since both statements point to largish sections of = descriptive text. >>=20 >> Thanks! >>=20 >> Jean >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Mar 6 06:59:34 2019 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 6DCAF127287 for ; Wed, 6 Mar 2019 06:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y35hLaMFrSDH for ; Wed, 6 Mar 2019 06:59:30 -0800 (PST) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 06352124BA8 for ; Wed, 6 Mar 2019 06:59:30 -0800 (PST) Received: by mail-vs1-xe35.google.com with SMTP id m20so2386321vsq.8 for ; Wed, 06 Mar 2019 06:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n/GkQ4Jg/mOQg8DGrgQfmHo3HLAbMi2Vk+0uZJeraYk=; b=WNBNtYXSlSPK0thRyU0ILV/SrixXjxxMSjN2Xbyxig11uBx27NwAXo8Rqp1GaxDsHq Tysw2lJT5GPs4uM0Vfkm6bIkkhDi3SXP57JlnLMe64nQMaEH/IsadZWTR/fz56y+m9/6 Xh4ZWpgeEuhUdU7QJwHmVY3SpxFiQs67g5x03RD6ZedTO4gruZ8pztenGVTMw5OtgpEK GKoZTHjlIdjxSjW3ZbemScy7VHP5NF9+uTJ1Szmug8Apc+Pr33FM7f0PhIRRS6YkErvW kzpUWDvxyM8x1PQycwPo/JKTSdScBjBiOqiD1o1oK/xPxzgMQsMwCueMD8O6Lu0hMKM/ 9ioQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n/GkQ4Jg/mOQg8DGrgQfmHo3HLAbMi2Vk+0uZJeraYk=; b=QOQMf/knJOViB/ijCJuud1Dv9SmzCtsZ2QeBJ+GDz0HKu7DyLZ6sIPLd2+RgVIi8t8 HRpWGz166QEZXIGlbLXzgwjH+2dJ8icH+RkbzdTwzTR5/D5GB+AnuBdrc4WaIw6eO4XM RaEe6oaobFt0d7Auv2IMkcyf5JltTSqRAvM9qqs4qp3IL060KaBc+npvp6izxVIjaHk0 b9w0XO4txEoXfaO/vV6GxHMrr/msD3k9r5sulHBQeLcbjmGmHipbiIreP8hwh/B4JB5F GrJLIOrTI3Paw0SE53HaL9d1CYdNe5J7nCpiM3zi5Gjyhv0GwFfxO/Krd+fBoFKnUAwT jIew== X-Gm-Message-State: APjAAAXToxJ5BIc+Xf6FkNCL8p3KDjdy6IMiczdQ9JHO62TWHsmAP3JU GbKAN8nontRLBtYDas4UayNVyD4cRYeTGUi5de8= X-Google-Smtp-Source: APXvYqxS+Di068LSkxXTd0qwAiTxRubpXWe5FcO3xmaDzt+sFs+/brZmJQpdoGkzPBndSPiEsQmLcLOoML+wDmItZpM= X-Received: by 2002:a67:f0c6:: with SMTP id j6mr4246096vsl.0.1551884368669; Wed, 06 Mar 2019 06:59:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yehoshua Gev Date: Wed, 6 Mar 2019 16:59:16 +0200 Message-ID: To: Christer Holmberg Cc: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="00000000000086f09105836e3c7e" Archived-At: Subject: Re: [sipcore] Syntax of Feature-Caps header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 14:59:32 -0000 --00000000000086f09105836e3c7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Christer, Thanks for the additional examples. The last fix you made in the example made me re-read RFC 6809. I noticed that the RFC indicates that: The Feature-Caps header field can be used within a SIP REGISTER request and within the 200 (OK) response associated with such a request. Although not explicitly forbidden, a Feature-Caps header is not expected to be included in non-200 responses. In the draft, there are cases that do include Feature-Caps header in such responses (like 555). I believe that the draft makes a correct use of the header, but it might be worth thinking why RFC 6809 has not thought of this use case. Best, Yehoshua On Fri, Mar 1, 2019 at 1:22 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I also noted that adding the =E2=80=98+=E2=80=99 is not enough. Note that= the Feature-Caps > header field syntax also mandates the =E2=80=98*=E2=80=99. > > > > So, the correct way is: > > > > Feature-Caps: *;+sip.608 > > > > Regards, > > > > Christer > > > > > > *From: *sipcore on behalf of Christer Holmberg > > *Date: *Thursday, 28 February 2019 at 16.50 > *To: *Yehoshua Gev > *Cc: *"sipcore@ietf.org" > *Subject: *Re: [sipcore] Syntax of Feature-Caps header > > > > HI Yehoshua, > > > > Please see inline. > > > > >I have a question regarding the syntax of the Feature-Caps header since > I've not managed to find any real examples of its usage. > > > > > >The ABNF in RFC 6809 is defined as: > > > Feature-Caps =3D "Feature-Caps" HCOLON fc-value > > *(COMMA fc-value) > > fc-value =3D "*" *(SEMI feature-cap) > > > feature-cap =3D "+" fcap-name [EQUAL LDQUOT (fcap-value-list > > > / fcap-string-value ) RDQUOT] > > > > > > Following this syntax, I guess that for sip-push the header will look > like: > *> Feature-Caps: *;+sip.pns=3D"webpush"* > > > > > > > > >One example I could find is on > https://tools.ietf.org/html/draft-ietf-sipcore-rejected-03: > > *> Feature-Caps: sip.608* > > >Without the asterisk and the plus sign. > > > > > > Which one is correct? > > > > The sip.pns example is correct. The sip.608 example needs to be corrected= . > > > > (I THINK I had previously commented on this when reading sipcore-rejected= , > but I may be wrong=E2=80=A6) > > > > >Due to the lack of examples, would it be possible to add an example to > the sip-push draft that includes feature capabilities > > >and media tags (especially that sip.pnsreg is used for both)? > > > > I will look into it. I guess that could be done when addressing Ben=E2=80= =99s > comments. > > > > Regards, > > > > Christer > > > --00000000000086f09105836e3c7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Christer,

Thanks for the additional = examples.

The last fix you made in the example mad= e me re-read RFC 6809.
I noticed that the RFC indicates that:
   The Feature-C=
aps header field can be used within a SIP REGISTER
   request and within the 200 (OK) response associated with such a
   request.

Although not= explicitly forbidden, a Feature-Caps header is not expected to be included= in non-200 responses.
In the draft, there are cases that do incl= ude Feature-Caps header in such responses (like 555).

<= div>I believe that the draft makes a correct use of the header, but it migh= t be worth thinking why RFC 6809 has not
thought of this use case= .

Best,
Yehoshua


On = Fri, Mar 1, 2019 at 1:22 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
<= /div>

Hi,

=C2=A0

I also noted that adding the = =E2=80=98+=E2=80=99 is not enough. Note that the Feature-Caps header field = syntax also mandates the =E2=80=98*=E2=80=99.

=C2=A0

So, the correct way is:<= u>

=C2=A0

Feature-Caps: *;+sip.608=

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: = sipcore <sipcore-bounces@ietf= .org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com= >
Date: Thursday, 28 February 2019 at 16.50
To: Yehoshua Gev <yoshigev@gmail.com>
Cc: "sipc= ore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Syntax of Feature-Caps header

=C2=A0

HI Yehoshua,

=C2=A0

Please see inline.

=C2=A0

>I have a question regarding= the syntax of the Feature-Caps header since I've not managed to find a= ny real examples of its usage.

>=C2=A0=

>The ABNF in RFC=C2=A06809 i= s defined as:

>=C2=A0 =C2=A0Feature-Caps = =3D "Feature-Caps" HCOLON fc-value
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*(= COMMA fc-value)
>=C2=A0 =C2=A0fc-value =C2=A0 =C2=A0 =3D "*" *(SEMI feature-ca= p)

>=C2=A0 =C2=A0feature-cap=C2= =A0 =C2=A0 =C2=A0 =C2=A0=3D=C2=A0 "+" fcap-name [EQUAL LDQUOT (fc= ap-value-list

>=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 / fc= ap-string-value ) RDQUOT]

>=C2=A0=

> Following this syntax, I g= uess that for sip-push the header will look like:
>=C2=A0 =C2=A0Feature-Caps: *;+sip.pns=3D"webpush"

>=C2=A0=

>=C2=A0=

>One example I could find is= on=C2=A0https://tools.ietf.org/h= tml/draft-ietf-sipcore-rejected-03:<= u>

>=C2=A0 =C2=A0Feature-Cap= s: sip.608

>Without the asterisk and th= e plus sign.

>=C2=A0=

> Which one is correct?=C2= =A0

=C2=A0

The sip.pns example is correct.= The sip.608 example needs to be corrected.

=C2=A0

(I THINK I had previously comme= nted on this when reading sipcore-rejected, but I may be wrong=E2=80=A6)

=C2=A0

>Due to the lack of examples= , would it be possible to add an example to the sip-push draft that include= s feature capabilities

>and media tags (especially = that sip.pnsreg is used for both)?

=C2=A0

I will look into it. I guess th= at could be done when addressing Ben=E2=80=99s comments.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

--00000000000086f09105836e3c7e-- From nobody Wed Mar 6 07:20:24 2019 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 3B98012705F for ; Wed, 6 Mar 2019 07:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=IR8Ps3hE; dkim=pass (1024-bit key) header.d=ericsson.com header.b=auXyrcyI 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 bGG1hPUKPEWL for ; Wed, 6 Mar 2019 07:20:21 -0800 (PST) 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 BB2C61277C9 for ; Wed, 6 Mar 2019 07:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551885619; x=1554477619; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zsuRgDQ1gjB5ZvBB1l7LNskqhYWbKrxi9Ax2dFDoxmA=; b=IR8Ps3hEaorNduzeJs/TpxVDn4Cu+7TomPTtdQPRF+0UUdz1C28+ZPvAy9KyUcwR Bgw0zt+9doAVllYZj236zqeJpAMNwWgwgTO6Nkf3Ysg9gcfG7QulSBQRgzlvs1lu wFhTjScqEKgKpz0eWpCBimFXFUvO+KAUcc8WqVKkPAw=; X-AuditID: c1b4fb3a-5c9c29e00000672c-b9-5c7fe532c417 Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0A.C7.26412.235EF7C5; Wed, 6 Mar 2019 16:20:18 +0100 (CET) Received: from ESESSMR503.ericsson.se (153.88.183.112) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Mar 2019 16:20:14 +0100 Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESSMR503.ericsson.se (153.88.183.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Mar 2019 16:20:14 +0100 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 6 Mar 2019 16:20:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zsuRgDQ1gjB5ZvBB1l7LNskqhYWbKrxi9Ax2dFDoxmA=; b=auXyrcyImin4o3W7/l7Zh2rRuagpcFGRGjj+8Mr1CLv5reznX8Uwl5b/hybLQE36uVB6hyC+pYuZrfqwimixIjcm3n7yt39L45t6PUgtkUOWL4BlZkAl1/y5QnT3IHdDBmNoNerT8Y8wUwnvaoxMdVk5NAA4iwfWSj6KX5QKoUA= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4345.eurprd07.prod.outlook.com (20.176.167.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.8; Wed, 6 Mar 2019 15:20:12 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae%3]) with mapi id 15.20.1686.016; Wed, 6 Mar 2019 15:20:12 +0000 From: Christer Holmberg To: Yehoshua Gev CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Syntax of Feature-Caps header Thread-Index: AQHU0CEMPi1uLoVZd0+S4VzAw2AncaX+uhMAgAAnYQA= Date: Wed, 6 Mar 2019 15:20:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 49abbb89-2112-46ca-9fc5-08d6a2473a80 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4345; x-ms-traffictypediagnostic: HE1PR07MB4345: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(376002)(346002)(136003)(366004)(199004)(189003)(229853002)(6116002)(3846002)(25786009)(6512007)(6306002)(6436002)(6486002)(53936002)(7736002)(305945005)(4326008)(6916009)(33656002)(81166006)(81156014)(66066001)(8676002)(6246003)(97736004)(105586002)(106356001)(2906002)(966005)(14454004)(6506007)(53546011)(76176011)(44832011)(476003)(486006)(256004)(14444005)(6346003)(26005)(58126008)(446003)(11346002)(102836004)(99286004)(2616005)(36756003)(82746002)(68736007)(8936002)(478600001)(186003)(83716004)(1411001)(71200400001)(71190400001)(316002)(86362001)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4345; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: bwZsUslMcXWoTWSgzymzlbXTs5oBjF5JMDsczWeikhI2J6nb0fV0PTpAY9a+ftEQxGPCTMnkV0WZ1if07CrZZVkpOmSw6usoDg5wcGD9pm8rfUafpNuQYrIv0Ape2wpxjgxV3Pu7cE0dZcvQ382eA40pLou7hl5yRnNjJmhHDfMNLdkR0Y8cBB0vcWPAbr8k39ZF3AjNZSOiUAYoRzSnf9TNbnqnWH1jLYQT2+m2r45HDTZLkMSP3FEgzlmwEtY1zROun6M3G7P4KGFZqBDxRVqMxG9fC0bSZ+ebXS4o8jObvawdxid+wPKdq1pH1s9z0LLIswFKe3tllv7wA6xa2iCFG526kXSJzXi743wlxaB07uHvWXrEwSOcFH9dlBrV3hqep/peJlw2MPk4DxnAqUY/DE9e7Q5peu3E3DMJLz4= Content-Type: text/plain; charset="utf-8" Content-ID: <4BDA7FC414CF3E438E8973DA34C3E489@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 49abbb89-2112-46ca-9fc5-08d6a2473a80 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2019 15:20:12.6098 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4345 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUyM2J7ha7R0/oYg58rbSy+/tjEZvF7411m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvjxu8W1oIJKhUv9nxla2CcodzFyMkhIWAi sePLNqYuRi4OIYEjjBK3F91nhnC+MkrsOvqRCc75d/MIVGYxk0TvskfsIA6LwARmie+f97NB ZCYySfxfvwjKecgosfHOSsYuRg4ONgELie5/2iCmiICqxMvn+SDLmQU0JR7t3MsEYgsDHfL8 7T5WEFtEwFSi6dd9dgjbSqLx9gmwGhYBFYlpay+B2bwC9hK7l6+DOq+NUWJy42lmkASnQKDE ilX7wJoZBcQkvp9awwSxTFzi1pP5TBBfC0gs2XOeGcIWlXj5+B/YYlEBfYktfQ9YIOKKEmff PYSql5W4NL+bEcL2lZjyYCfY9xICNxkljsxdxwaR0JI49KcDqllK4sTFo6wQdrbEwtnL2UCe lxCQkVjbZAnR284m0TBjDeMERoNZSO6bBVQGCpj1u/Qhwh4ST7ZOZoKwFSWmdD9knwX2v6DE yZlPWBYwsq5iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECEwoB7f8ttrBePC54yFGAQ5GJR7e /t31MUKsiWXFlbmHGCU4mJVEeN3XAIV4UxIrq1KL8uOLSnNSiw8xSnOwKInz/hESjBESSE8s Sc1OTS1ILYLJMnFwSjUwiv+w26DrURcTPPFbWoXWL67qmPyAb+cuSZ78/P/cIfHoqodr5b7e ETIVmHoq+sD6EhcXrSeXCk+mmZ+dmDRr8YL/bzITzp07KT2J47T3htO2Mn+2v66Iveo5ecqz 7uN+zUqVW4Nlg15H/Ik2/eZV90pMeJ/AQcEe3YJqnUl3JPs18n0vpH7aqsRSnJFoqMVcVJwI AHJP5X4kAwAA Archived-At: Subject: Re: [sipcore] Syntax of Feature-Caps header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 15:20:23 -0000 SGkgWWVob3NodWEsDQoNCj5UaGUgbGFzdCBmaXggeW91IG1hZGUgaW4gdGhlIGV4YW1wbGUgbWFk ZSBtZSByZS1yZWFkIFJGQyA2ODA5Lg0KPkkgbm90aWNlZCB0aGF0IHRoZSBSRkMgaW5kaWNhdGVz IHRoYXQ6DQo+ICAgVGhlIEZlYXR1cmUtQ2FwcyBoZWFkZXIgZmllbGQgY2FuIGJlIHVzZWQgd2l0 aGluIGEgU0lQIFJFR0lTVEVSDQo+ICAgcmVxdWVzdCBhbmQgd2l0aGluIHRoZSAyMDAgKE9LKSBy ZXNwb25zZSBhc3NvY2lhdGVkIHdpdGggc3VjaCBhDQo+ICAgcmVxdWVzdC4NCj4NCj4gQWx0aG91 Z2ggbm90IGV4cGxpY2l0bHkgZm9yYmlkZGVuLCBhIEZlYXR1cmUtQ2FwcyBoZWFkZXIgaXMgbm90 IGV4cGVjdGVkIHRvIGJlIGluY2x1ZGVkIGluIG5vbi0yMDAgcmVzcG9uc2VzLg0KPiBJbiB0aGUg ZHJhZnQsIHRoZXJlIGFyZSBjYXNlcyB0aGF0IGRvIGluY2x1ZGUgRmVhdHVyZS1DYXBzIGhlYWRl ciBpbiBzdWNoIHJlc3BvbnNlcyAobGlrZSA1NTUpLg0KDQpDb3JyZWN0LiBHb29kIGNhdGNoLg0K DQo+SSBiZWxpZXZlIHRoYXQgdGhlIGRyYWZ0IG1ha2VzIGEgY29ycmVjdCB1c2Ugb2YgdGhlIGhl YWRlciwgYnV0IGl0IG1pZ2h0IGJlIHdvcnRoIHRoaW5raW5nIHdoeSBSRkMgNjgwOSBoYXMgbm90 DQo+dGhvdWdodCBvZiB0aGlzIHVzZSBjYXNlLg0KDQpJIGFzc3VtZSB0aGUgcmVhc29uIGlzIHRo YXQgdGhlIHNjb3BlIG9mIGEgZmVhdHVyZS1jYXBhYmlsaXR5IGluZGljYXRvciBpcyB0aGUgYmlu ZGluZyBjcmVhdGVkIGJ5IGEgUkVHSVNURVIvMjAwLg0KDQpPbmUgb3B0aW9uIHdvdWxkIGJlIHRv IHNheSB0aGF0IHNpcC1wdXNoIHVwZGF0ZXMgNjgwOSBieSBhbGxvd2luZyB0aGUgRmVhdHVyZS1D YXBzIGhlYWRlciBpbiA1NTUuDQoNCkFub3RoZXIgb3B0aW9uIHdvdWxkIGJlIHRvIHJlbW92ZSB0 aGUgRmVhdHVyZS1DYXBzIGhlYWRlciBmcm9tIDU1NSByZXNwb25zZXMuIEl0IHdvdWxkbid0IGFm ZmVjdCB0aGUgbWVjaGFuaXNtIGluIGdlbmVyYWwsIGFzIGl0IG9ubHkgcHJvdmlkZXMgYWRkaXRp b25hbCBpbmZvcm1hdGlvbiAoYW5kLCBpbmNsdWRpbmcgRi1DIGluIDU1NSBpcyBvbmx5IGEgU0hP VUxEKS4gSWYgYSBVQSBzdXBwb3J0cyBtdWx0aXBsZSBQTlNzIGl0IGNhbiBhbHdheXMgcGVyZm9y bSBhIHF1ZXJ5IHRvIGZpbmQgb3V0IHdoYXQgUE5TcyB0aGUgbmV0d29yayBzdXBwb3J0LiBJZiB0 aGUgVUEgb25seSBzdXBwb3J0cyBvbmUgUE5TLCBhbmQgdGhlIG5ldHdvcmsgZG9lc24ndCBzdXBw b3J0IGl0IGFuZCBzZW5kcyA1NTUsIGl0IGRvZXNuJ3QgcmVhbGx5IG1hdHRlciB0byB0aGUgVUEg d2hhdCBQTlMgdGhlIG5ldHdvcmsgc3VwcG9ydHMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg0KDQpPbiBGcmksIE1hciAxLCAyMDE5IGF0IDE6MjIgUE0gQ2hyaXN0ZXIgSG9sbWJlcmcgPG1h aWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KSGksDQrCoA0KSSBh bHNvIG5vdGVkIHRoYXQgYWRkaW5nIHRoZSDigJgr4oCZIGlzIG5vdCBlbm91Z2guIE5vdGUgdGhh dCB0aGUgRmVhdHVyZS1DYXBzIGhlYWRlciBmaWVsZCBzeW50YXggYWxzbyBtYW5kYXRlcyB0aGUg 4oCYKuKAmS4NCsKgDQpTbywgdGhlIGNvcnJlY3Qgd2F5IGlzOg0KwqANCkZlYXR1cmUtQ2Fwczog Kjsrc2lwLjYwOA0KwqANClJlZ2FyZHMsDQrCoA0KQ2hyaXN0ZXINCsKgDQrCoA0KRnJvbTogc2lw Y29yZSA8bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIENocmlz dGVyIEhvbG1iZXJnIDxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KRGF0 ZTogVGh1cnNkYXksIDI4IEZlYnJ1YXJ5IDIwMTkgYXQgMTYuNTANClRvOiBZZWhvc2h1YSBHZXYg PG1haWx0bzp5b3NoaWdldkBnbWFpbC5jb20+DQpDYzogIm1haWx0bzpzaXBjb3JlQGlldGYub3Jn IiA8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFN5bnRh eCBvZiBGZWF0dXJlLUNhcHMgaGVhZGVyDQrCoA0KSEkgWWVob3NodWEsDQrCoA0KUGxlYXNlIHNl ZSBpbmxpbmUuDQrCoA0KPkkgaGF2ZSBhIHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGUgc3ludGF4IG9m IHRoZSBGZWF0dXJlLUNhcHMgaGVhZGVyIHNpbmNlIEkndmUgbm90IG1hbmFnZWQgdG8gZmluZCBh bnkgcmVhbCBleGFtcGxlcyBvZiBpdHMgdXNhZ2UuDQo+wqANCj5UaGUgQUJORiBpbiBSRkPCoDY4 MDkgaXMgZGVmaW5lZCBhczoNCj7CoCDCoEZlYXR1cmUtQ2FwcyA9ICJGZWF0dXJlLUNhcHMiIEhD T0xPTiBmYy12YWx1ZQ0KPsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKihDT01NQSBmYy12 YWx1ZSkNCj7CoCDCoGZjLXZhbHVlIMKgIMKgID0gIioiICooU0VNSSBmZWF0dXJlLWNhcCkNCj7C oCDCoGZlYXR1cmUtY2FwwqAgwqAgwqAgwqA9wqAgIisiIGZjYXAtbmFtZSBbRVFVQUwgTERRVU9U IChmY2FwLXZhbHVlLWxpc3QNCj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCAvIGZjYXAtc3RyaW5nLXZhbHVlICkgUkRRVU9UXQ0KPsKgDQo+IEZvbGxvd2luZyB0aGlz IHN5bnRheCwgSSBndWVzcyB0aGF0IGZvciBzaXAtcHVzaCB0aGUgaGVhZGVyIHdpbGwgbG9vayBs aWtlOg0KPsKgIMKgRmVhdHVyZS1DYXBzOiAqOytzaXAucG5zPSJ3ZWJwdXNoIg0KPsKgDQo+wqAN Cj5PbmUgZXhhbXBsZSBJIGNvdWxkIGZpbmQgaXMgb27CoGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXNpcGNvcmUtcmVqZWN0ZWQtMDM6DQo+wqAgwqBGZWF0dXJlLUNhcHM6 IHNpcC42MDgNCj5XaXRob3V0IHRoZSBhc3RlcmlzayBhbmQgdGhlIHBsdXMgc2lnbi4NCj7CoA0K PiBXaGljaCBvbmUgaXMgY29ycmVjdD/CoA0KwqANClRoZSBzaXAucG5zIGV4YW1wbGUgaXMgY29y cmVjdC4gVGhlIHNpcC42MDggZXhhbXBsZSBuZWVkcyB0byBiZSBjb3JyZWN0ZWQuIA0KwqANCihJ IFRISU5LIEkgaGFkIHByZXZpb3VzbHkgY29tbWVudGVkIG9uIHRoaXMgd2hlbiByZWFkaW5nIHNp cGNvcmUtcmVqZWN0ZWQsIGJ1dCBJIG1heSBiZSB3cm9uZ+KApikNCsKgDQo+RHVlIHRvIHRoZSBs YWNrIG9mIGV4YW1wbGVzLCB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBhZGQgYW4gZXhhbXBsZSB0 byB0aGUgc2lwLXB1c2ggZHJhZnQgdGhhdCBpbmNsdWRlcyBmZWF0dXJlIGNhcGFiaWxpdGllcyAN Cj5hbmQgbWVkaWEgdGFncyAoZXNwZWNpYWxseSB0aGF0IHNpcC5wbnNyZWcgaXMgdXNlZCBmb3Ig Ym90aCk/DQrCoA0KSSB3aWxsIGxvb2sgaW50byBpdC4gSSBndWVzcyB0aGF0IGNvdWxkIGJlIGRv bmUgd2hlbiBhZGRyZXNzaW5nIEJlbuKAmXMgY29tbWVudHMuDQrCoA0KUmVnYXJkcywNCsKgDQpD aHJpc3Rlcg0KwqANCg0K From nobody Wed Mar 6 10:21:01 2019 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 EAF1513122F; Wed, 6 Mar 2019 10:20:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Eric Rescorla To: "The IESG" Cc: br@brianrosen.net, draft-ietf-sipcore-reason-q850-loc@ietf.org, sipcore@ietf.org, Brian Rosen , sipcore-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155189645890.320.5299888968884234926.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 10:20:58 -0800 Archived-At: Subject: [sipcore] Eric Rescorla's No Objection on draft-ietf-sipcore-reason-q850-loc-06: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 18:20:59 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-sipcore-reason-q850-loc-06: 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-reason-q850-loc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3825 COMMENTS > > The SIP Reason header field is defined for carrying ISDN User Part > (ISUP) cause values as well as SIP response codes. Some services in > SIP networks may need to know the ISUP location where the call was > released in the PSTN network to correctly interpret the reason of > release. This document will update RFC3326. "release" appears to be a technical PSTN term. Please provide a citation the way that 3226 does. From nobody Thu Mar 7 00:59:01 2019 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 3560D130EE4 for ; Thu, 7 Mar 2019 00:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=D1HwIKt7; dkim=pass (1024-bit key) header.d=ericsson.com header.b=O58ap2HU 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 ZDR3C_wHItS4 for ; Thu, 7 Mar 2019 00:58:56 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0EB130EBA for ; Thu, 7 Mar 2019 00:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551949134; x=1554541134; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mSedjp3710R6OZXMX/pWIdPn5ohcdFSsv+UXormhTtQ=; b=D1HwIKt7Fi61Y0KIbHvM3hjhMF6bW4iN/8wgpOkC4RfagjN7kwb5Z97LiYuuf3BE jvZa6BNF9vjd4kF9OieOT6Pwa1cXiGmflhHca/nMEtjFVH/GRPcKIo1D8yUZOc+j tp1MHLh1I6z3O+Ik51g3g8rQ6T0qGLmL/UmON7nfHlE=; X-AuditID: c1b4fb30-41b3a9e00000355c-6f-5c80dd4e4ee3 Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A1.77.13660.E4DD08C5; Thu, 7 Mar 2019 09:58:54 +0100 (CET) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 7 Mar 2019 09:58:41 +0100 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 7 Mar 2019 09:58:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mSedjp3710R6OZXMX/pWIdPn5ohcdFSsv+UXormhTtQ=; b=O58ap2HUJVqjaUhF4zGUrtZcIdzwUTy8yssik9pw9CHv8zrpcHLmHRhWq8se+PjYv08JDYzFmqMFJP4ItBI8HgSBDZAFuAwx2v7QJ0j+QrwuXZCedpU7aL0W68t+Cc9cs+FOpsDmGNKtd27tSbBHw4a0/REaWmw833mNQRq0fHQ= Received: from VI1PR07MB3167.eurprd07.prod.outlook.com (10.175.243.17) by VI1PR07MB5183.eurprd07.prod.outlook.com (20.178.9.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.8; Thu, 7 Mar 2019 08:58:40 +0000 Received: from VI1PR07MB3167.eurprd07.prod.outlook.com ([fe80::c1f5:59ba:ad1d:c36e]) by VI1PR07MB3167.eurprd07.prod.outlook.com ([fe80::c1f5:59ba:ad1d:c36e%3]) with mapi id 15.20.1709.009; Thu, 7 Mar 2019 08:58:40 +0000 From: Christer Holmberg To: Yehoshua Gev , "sipcore@ietf.org" , Ben Campbell Thread-Topic: [sipcore] Syntax of Feature-Caps header - suggestion to remove Feature-Caps header field in REGISTER 555 responses. Thread-Index: AQHU1MP1BX0cAPRfLEatOjGhVUUqDw== Date: Thu, 7 Mar 2019 08:58:40 +0000 Message-ID: <0A44F74A-6EBF-4317-8091-194D77AD9FED@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3238c1b2-8073-42a5-e949-08d6a2db17ea x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB5183; x-ms-traffictypediagnostic: VI1PR07MB5183: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(376002)(346002)(396003)(39860400002)(52024003)(189003)(199004)(486006)(26005)(6306002)(476003)(6512007)(44832011)(86362001)(6486002)(229853002)(6246003)(6436002)(2616005)(5660300002)(186003)(33656002)(83716004)(106356001)(66066001)(105586002)(82746002)(53936002)(110136005)(99286004)(478600001)(53546011)(6506007)(2501003)(14444005)(256004)(81166006)(36756003)(316002)(68736007)(58126008)(102836004)(8676002)(14454004)(97736004)(25786009)(966005)(8936002)(71190400001)(71200400001)(6116002)(305945005)(3846002)(7736002)(81156014)(2906002)(153083001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5183; H:VI1PR07MB3167.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: LZesupN/Y0BiUjDYxGNh0ALL0KGPJJN7JV58VJqebRcQA47iMwMzuMtB+wig+G5BGKTlZ47bH50FSCbu2flRuT+gWeZjWt2kAvMIphsPtxyDIo/JWij+x1cgp7hT3G2WEc6t/MKi+yIBjKmYYZMAQsmj6fKnT0+MqXjWyTaf59YGLrMWH+USwEllHWuHjVVsBl4ioNm5UAn9iNR4ey2W0k9ThvDNUKTlkKNqNJyMeGNQ4A/CJa1RbJlkncIxkvr9zU/A/jhB3i4v/DUExaXXymMlc8GONQU9q873Frt9xYEz7Q+2GKpUiXRja8jDZvBL6b84LO6FpfkW1Eh4phE8VxppOEXrv0Qo9d9qG7xcQzSXLoJ1HCKXUk4uavoDBj4T9+etjo9MR3IbuCC3CPsLrmSZmNXvtGjJgww7WPXlD2A= Content-Type: text/plain; charset="utf-8" Content-ID: <32D4FFC6DC55454DBC07C65F04807914@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3238c1b2-8073-42a5-e949-08d6a2db17ea X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2019 08:58:40.1091 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5183 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+XbO2Y6jwefa9GWZ5eyfvMxLEhZWdhEmXf+UFHTpQcW5yWZD E2IpCWblsKubODFTElMcki0Ca8rMLqyckYYrhyMzxFIU5yXL41nQf7/3fZ7ne3ngowlxIyWj CzWljE6jUsv5QrIho6889ozHmBU/OomTrTVvBMlLfhs/ea3HQ6QSSrvZI1C2tq7wlGa7jzxH nBem5DHqQgOjizucIyyYuNVClSwoyqqrY41oLPYaCqIBJ8Fd5wi6hoS0GA8imJgcpbhhCUG/ 6XtAecCDOlc7wQ4kNhHQ3dVIcoqJB1/q13nc4EUwsGjfzNA0HydD7UY0e0SCNdBU1cVnPdtx JYI/PXVbT0lwFYLpK4Mk51LArKOZzzKJ90B9f4+AfUiEj4DVv59dIxwCy687eSwTOBQ++6w8 rgWG1ucugmMpzExtUCxLcRz03pwkuawK+jsmA54IeDfnDWR3woi1FnF8GsY97q0ygMcRjHxb 5XNCFPQNfggEZLA8NS/guAi6BiwUx2HgbBtCXPgXBU8+zW8FxJiB9sdXAxfCoeOGl+RMLgLW Khd5JhRj/q+RebM0gfdC97M4bq0E/0wb4jgCbtd6BSyLcDAMN/jIZkR1IKme0V8ozk9MVDC6 wly9XqtRaJhSG9r8My971+Kfopnpow6EaSTfJgoeMmaJKZVBX17sQEATcono1djmSpSnKr/E 6LTZuotqRu9AO2hSHipaFwdniXG+qpQpYpgSRvdP5dFBMiNqO3V/xebPbf6d1J1kcB/IWQ05 tnFH7EyLKMkZqPCESBL60rNdaYcqnaZUd2ZJ2twug1TsOrsv8mRm/Pvjds2iLGyx05JXYVE/ +tkyXND0lXLWtpIxIkOG2uezNNjKLiOt9rowPJ2vFhxcePjxx6x7Pjpy7d7b3TWryy9OxKXI SX2BKiGK0OlVfwE0CEvKLwMAAA== Archived-At: Subject: Re: [sipcore] Syntax of Feature-Caps header - suggestion to remove Feature-Caps header field in REGISTER 555 responses. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 08:58:59 -0000 SGksDQoNCkkgd2lsbCBnbyBhaGVhZCBhbmQgc3VnZ2VzdCB0aGF0IHdlIFJFTU9WRSB0aGUgdXNh Z2Ugb2YgdGhlIEZlYXR1cmUtQ2FwcyBoZWFkZXIgZmllbGQgaW4gUkVHSVNURVIgNTU1IHJlc3Bv bnNlcy4gVGhpcyBtZWFucyB0aGF0IHRoZSBuZXR3b3JrIGNhbm5vdCBpbmZvcm0gdGhlIFVBIGFi b3V0IHN1cHBvcnRlZCBQTlNzIGluIGEgNTU1IFJFR0lTVEVSIHJlc3BvbnNlLCBidXQgdGhlIG5l dHdvcmsgY2FuIHN0aWxsIGRvIGl0IGluIGEgMjAwIFJFR0lTVEVSIHJlc3BvbnNlIChxdWVyeSBt b2RlKS4NCg0KUGxlYXNlIGxldCBtZSBrbm93IGFzYXAgaWYgeW91IGRpc2FncmVlIHdpdGggc3Vj aCBhcHByb2FjaC4gSSB3aWxsIHByZXBhcmUgYSBQUiBkdXJpbmcgdGhlIGRheS4NCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQoNCu+7v09uIDA2LzAzLzIwMTksIDE3LjIwLCAic2lw Y29yZSBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmciIDxzaXBjb3JlLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mIGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6 DQoNCiAgICBIaSBZZWhvc2h1YSwNCiAgICANCiAgICA+VGhlIGxhc3QgZml4IHlvdSBtYWRlIGlu IHRoZSBleGFtcGxlIG1hZGUgbWUgcmUtcmVhZCBSRkMgNjgwOS4NCiAgICA+SSBub3RpY2VkIHRo YXQgdGhlIFJGQyBpbmRpY2F0ZXMgdGhhdDoNCiAgICA+ICAgVGhlIEZlYXR1cmUtQ2FwcyBoZWFk ZXIgZmllbGQgY2FuIGJlIHVzZWQgd2l0aGluIGEgU0lQIFJFR0lTVEVSDQogICAgPiAgIHJlcXVl c3QgYW5kIHdpdGhpbiB0aGUgMjAwIChPSykgcmVzcG9uc2UgYXNzb2NpYXRlZCB3aXRoIHN1Y2gg YQ0KICAgID4gICByZXF1ZXN0Lg0KICAgID4NCiAgICA+IEFsdGhvdWdoIG5vdCBleHBsaWNpdGx5 IGZvcmJpZGRlbiwgYSBGZWF0dXJlLUNhcHMgaGVhZGVyIGlzIG5vdCBleHBlY3RlZCB0byBiZSBp bmNsdWRlZCBpbiBub24tMjAwIHJlc3BvbnNlcy4NCiAgICA+IEluIHRoZSBkcmFmdCwgdGhlcmUg YXJlIGNhc2VzIHRoYXQgZG8gaW5jbHVkZSBGZWF0dXJlLUNhcHMgaGVhZGVyIGluIHN1Y2ggcmVz cG9uc2VzIChsaWtlIDU1NSkuDQogICAgDQogICAgQ29ycmVjdC4gR29vZCBjYXRjaC4NCiAgICAN CiAgICA+SSBiZWxpZXZlIHRoYXQgdGhlIGRyYWZ0IG1ha2VzIGEgY29ycmVjdCB1c2Ugb2YgdGhl IGhlYWRlciwgYnV0IGl0IG1pZ2h0IGJlIHdvcnRoIHRoaW5raW5nIHdoeSBSRkMgNjgwOSBoYXMg bm90DQogICAgPnRob3VnaHQgb2YgdGhpcyB1c2UgY2FzZS4NCiAgICANCiAgICBJIGFzc3VtZSB0 aGUgcmVhc29uIGlzIHRoYXQgdGhlIHNjb3BlIG9mIGEgZmVhdHVyZS1jYXBhYmlsaXR5IGluZGlj YXRvciBpcyB0aGUgYmluZGluZyBjcmVhdGVkIGJ5IGEgUkVHSVNURVIvMjAwLg0KICAgIA0KICAg IE9uZSBvcHRpb24gd291bGQgYmUgdG8gc2F5IHRoYXQgc2lwLXB1c2ggdXBkYXRlcyA2ODA5IGJ5 IGFsbG93aW5nIHRoZSBGZWF0dXJlLUNhcHMgaGVhZGVyIGluIDU1NS4NCiAgICANCiAgICBBbm90 aGVyIG9wdGlvbiB3b3VsZCBiZSB0byByZW1vdmUgdGhlIEZlYXR1cmUtQ2FwcyBoZWFkZXIgZnJv bSA1NTUgcmVzcG9uc2VzLiBJdCB3b3VsZG4ndCBhZmZlY3QgdGhlIG1lY2hhbmlzbSBpbiBnZW5l cmFsLCBhcyBpdCBvbmx5IHByb3ZpZGVzIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gKGFuZCwgaW5j bHVkaW5nIEYtQyBpbiA1NTUgaXMgb25seSBhIFNIT1VMRCkuIElmIGEgVUEgc3VwcG9ydHMgbXVs dGlwbGUgUE5TcyBpdCBjYW4gYWx3YXlzIHBlcmZvcm0gYSBxdWVyeSB0byBmaW5kIG91dCB3aGF0 IFBOU3MgdGhlIG5ldHdvcmsgc3VwcG9ydC4gSWYgdGhlIFVBIG9ubHkgc3VwcG9ydHMgb25lIFBO UywgYW5kIHRoZSBuZXR3b3JrIGRvZXNuJ3Qgc3VwcG9ydCBpdCBhbmQgc2VuZHMgNTU1LCBpdCBk b2Vzbid0IHJlYWxseSBtYXR0ZXIgdG8gdGhlIFVBIHdoYXQgUE5TIHRoZSBuZXR3b3JrIHN1cHBv cnRzLg0KICAgIA0KICAgIFJlZ2FyZHMsDQogICAgDQogICAgQ2hyaXN0ZXINCiAgICANCiAgICAN CiAgICANCiAgICBPbiBGcmksIE1hciAxLCAyMDE5IGF0IDE6MjIgUE0gQ2hyaXN0ZXIgSG9sbWJl cmcgPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KICAgIEhp LA0KICAgICANCiAgICBJIGFsc28gbm90ZWQgdGhhdCBhZGRpbmcgdGhlIOKAmCvigJkgaXMgbm90 IGVub3VnaC4gTm90ZSB0aGF0IHRoZSBGZWF0dXJlLUNhcHMgaGVhZGVyIGZpZWxkIHN5bnRheCBh bHNvIG1hbmRhdGVzIHRoZSDigJgq4oCZLg0KICAgICANCiAgICBTbywgdGhlIGNvcnJlY3Qgd2F5 IGlzOg0KICAgICANCiAgICBGZWF0dXJlLUNhcHM6ICo7K3NpcC42MDgNCiAgICAgDQogICAgUmVn YXJkcywNCiAgICAgDQogICAgQ2hyaXN0ZXINCiAgICAgDQogICAgIA0KICAgIEZyb206IHNpcGNv cmUgPG1haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBDaHJpc3Rl ciBIb2xtYmVyZyA8bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCiAgICBE YXRlOiBUaHVyc2RheSwgMjggRmVicnVhcnkgMjAxOSBhdCAxNi41MA0KICAgIFRvOiBZZWhvc2h1 YSBHZXYgPG1haWx0bzp5b3NoaWdldkBnbWFpbC5jb20+DQogICAgQ2M6ICJtYWlsdG86c2lwY29y ZUBpZXRmLm9yZyIgPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KICAgIFN1YmplY3Q6IFJlOiBb c2lwY29yZV0gU3ludGF4IG9mIEZlYXR1cmUtQ2FwcyBoZWFkZXINCiAgICAgDQogICAgSEkgWWVo b3NodWEsDQogICAgIA0KICAgIFBsZWFzZSBzZWUgaW5saW5lLg0KICAgICANCiAgICA+SSBoYXZl IGEgcXVlc3Rpb24gcmVnYXJkaW5nIHRoZSBzeW50YXggb2YgdGhlIEZlYXR1cmUtQ2FwcyBoZWFk ZXIgc2luY2UgSSd2ZSBub3QgbWFuYWdlZCB0byBmaW5kIGFueSByZWFsIGV4YW1wbGVzIG9mIGl0 cyB1c2FnZS4NCiAgICA+IA0KICAgID5UaGUgQUJORiBpbiBSRkMgNjgwOSBpcyBkZWZpbmVkIGFz Og0KICAgID4gICBGZWF0dXJlLUNhcHMgPSAiRmVhdHVyZS1DYXBzIiBIQ09MT04gZmMtdmFsdWUN CiAgICA+ICAgICAgICAgICAgICAgICAgICooQ09NTUEgZmMtdmFsdWUpDQogICAgPiAgIGZjLXZh bHVlICAgICA9ICIqIiAqKFNFTUkgZmVhdHVyZS1jYXApDQogICAgPiAgIGZlYXR1cmUtY2FwICAg ICAgID0gICIrIiBmY2FwLW5hbWUgW0VRVUFMIExEUVVPVCAoZmNhcC12YWx1ZS1saXN0DQogICAg PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAvIGZjYXAtc3RyaW5nLXZhbHVlICkgUkRRVU9U XQ0KICAgID4gDQogICAgPiBGb2xsb3dpbmcgdGhpcyBzeW50YXgsIEkgZ3Vlc3MgdGhhdCBmb3Ig c2lwLXB1c2ggdGhlIGhlYWRlciB3aWxsIGxvb2sgbGlrZToNCiAgICA+ICAgRmVhdHVyZS1DYXBz OiAqOytzaXAucG5zPSJ3ZWJwdXNoIg0KICAgID4gDQogICAgPiANCiAgICA+T25lIGV4YW1wbGUg SSBjb3VsZCBmaW5kIGlzIG9uIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXNpcGNvcmUtcmVqZWN0ZWQtMDM6DQogICAgPiAgIEZlYXR1cmUtQ2Fwczogc2lwLjYwOA0KICAg ID5XaXRob3V0IHRoZSBhc3RlcmlzayBhbmQgdGhlIHBsdXMgc2lnbi4NCiAgICA+IA0KICAgID4g V2hpY2ggb25lIGlzIGNvcnJlY3Q/IA0KICAgICANCiAgICBUaGUgc2lwLnBucyBleGFtcGxlIGlz IGNvcnJlY3QuIFRoZSBzaXAuNjA4IGV4YW1wbGUgbmVlZHMgdG8gYmUgY29ycmVjdGVkLiANCiAg ICAgDQogICAgKEkgVEhJTksgSSBoYWQgcHJldmlvdXNseSBjb21tZW50ZWQgb24gdGhpcyB3aGVu IHJlYWRpbmcgc2lwY29yZS1yZWplY3RlZCwgYnV0IEkgbWF5IGJlIHdyb25n4oCmKQ0KICAgICAN CiAgICA+RHVlIHRvIHRoZSBsYWNrIG9mIGV4YW1wbGVzLCB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0 byBhZGQgYW4gZXhhbXBsZSB0byB0aGUgc2lwLXB1c2ggZHJhZnQgdGhhdCBpbmNsdWRlcyBmZWF0 dXJlIGNhcGFiaWxpdGllcyANCiAgICA+YW5kIG1lZGlhIHRhZ3MgKGVzcGVjaWFsbHkgdGhhdCBz aXAucG5zcmVnIGlzIHVzZWQgZm9yIGJvdGgpPw0KICAgICANCiAgICBJIHdpbGwgbG9vayBpbnRv IGl0LiBJIGd1ZXNzIHRoYXQgY291bGQgYmUgZG9uZSB3aGVuIGFkZHJlc3NpbmcgQmVu4oCZcyBj b21tZW50cy4NCiAgICAgDQogICAgUmVnYXJkcywNCiAgICAgDQogICAgQ2hyaXN0ZXINCiAgICAg DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICBzaXBjb3JlIG1haWxpbmcgbGlzdA0KICAgIHNpcGNvcmVAaWV0Zi5vcmcNCiAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCiAgICANCg0K From nobody Thu Mar 7 01:51:14 2019 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 C24B51313FB for ; Thu, 7 Mar 2019 01:49:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1551952150; bh=aIwC8kfn98CbMhFVhLctR3n8zKsn1qeNpWypK8755rU=; h=From:To:Cc:Subject:Date; b=bWXE375M6iKPfVLiczH6YbI3Wy6pfUrDB/zTA1DlCJjJ2IGs5yIUshrNdpAn3tyKF X6Gdnfv1ibN586/8l07gsyaUkihtGKKiAx/lUZIHvjqEhZrIJo+4isYnyaIycSnU8f lrKBfuTro3sNoJqBjO81YW2vozDLoYZ0kUsnbD4s= X-Original-To: sipcore@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Benjamin Kaduk To: "The IESG" Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org, Brian Rosen , sipcore-chairs@ietf.org, br@brianrosen.net, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155193609023.13714.4531517779875308584.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 21:21:30 -0800 Archived-At: Subject: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 09:49:16 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-sipcore-reason-q850-loc-06: 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-reason-q850-loc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Adam's Discuss. I also think that the Section 4 text: The use of the location parameter is restricted to Q850 cause values. Other values MUST be ignored if present. needs to be clear about whether it is intended to limit to the exact 16 strings listed above, or whether the intent is to update with Q850 if new values are allocated. Are string aliases allowed for the "national-use" codepoints if allocated within a given nation? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 the reason of release. The reason of release does indicate why a SIP Dialog or an PSTN call, in case where the call was interworked to the nits: s/does indicate/indicates/ ; s/an PSTN/a PSTN/ Section 3 The primary intent of the parameter defined in this specification is for use in IMS (IP Multimedia Subsystem) networks defined by 3GPP but also open to be used by any other network that includes ISUP nit: s/also/it is also/ Section 4 Depending on whether the message is a request or a response the UAC or UAS SHALL include the location parameter when setting up the Reason header field with a [Q.850] cause. This approach is only possible in cases when the ISUP [Q.850] location is available. I don't understand what depends on whether the message is a request or a response. From nobody Thu Mar 7 02:58:17 2019 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 BDF0C130F67 for ; Thu, 7 Mar 2019 02:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Ae81P2yS; dkim=pass (1024-bit key) header.d=ericsson.com header.b=T2wlhSpk 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 hG8AaPSAxRKu for ; Thu, 7 Mar 2019 02:58:11 -0800 (PST) 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 E12B0130F3C for ; Thu, 7 Mar 2019 02:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551956289; x=1554548289; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XeNjXMGIsWFMBWolzrq31NTYlO6FO8R0cauYOHPZ8jE=; b=Ae81P2ySr0Fa1hDq7wVyd+7Kdu7gj7/1YwbK9kxmKX4SPur92FGQdK+v9CBpKjEG 2TTbd5p+s9JbUifzp3fJFYrM4U+JlJ9qr9tZlC1KujTkJ3FuNFZHh2QuKqKkdnvi dhJo4X44XtOjz547WSxsCIdvxgeXUUo3vpIMVbLtxI0=; X-AuditID: c1b4fb3a-5c9c29e00000672c-ac-5c80f941676c Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A5.AC.26412.149F08C5; Thu, 7 Mar 2019 11:58:09 +0100 (CET) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 7 Mar 2019 11:58:08 +0100 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 7 Mar 2019 11:58:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XeNjXMGIsWFMBWolzrq31NTYlO6FO8R0cauYOHPZ8jE=; b=T2wlhSpkfpxtnZbgYZE/3C/R+cAw1WCKfRVjv9kUAluOYF900zp22Zf7/nr8O0l5zjYlam/2Pd4oCYys9hRerwxvB2ZsrzWpWbFi19sxsAK2YLDZ4e26XuPmZqcj7P5etHV1KEiIHgjhnEVoIxu4dgozn/nVZzIKwHX8/lWn0Go= Received: from VI1PR07MB3167.eurprd07.prod.outlook.com (10.175.243.17) by VI1PR07MB3949.eurprd07.prod.outlook.com (52.134.28.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.14; Thu, 7 Mar 2019 10:58:06 +0000 Received: from VI1PR07MB3167.eurprd07.prod.outlook.com ([fe80::c1f5:59ba:ad1d:c36e]) by VI1PR07MB3167.eurprd07.prod.outlook.com ([fe80::c1f5:59ba:ad1d:c36e%3]) with mapi id 15.20.1709.009; Thu, 7 Mar 2019 10:58:06 +0000 From: Christer Holmberg To: Yehoshua Gev , "sipcore@ietf.org" , Ben Campbell Thread-Topic: [sipcore] Syntax of Feature-Caps header - suggestion to remove Feature-Caps header field in REGISTER 555 responses - the pull request Thread-Index: AQHU1NSk8pGKS3LbGUe6Cll7rNPiZA== Date: Thu, 7 Mar 2019 10:58:06 +0000 Message-ID: <59D9D95B-6789-4F2B-AF54-313FC651EA63@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 62d78ae1-9ff3-4c0d-0f9d-08d6a2ebc77c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB3949; x-ms-traffictypediagnostic: VI1PR07MB3949: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIzOTQ5OzIzOitzamNBck5OZlcwMFZBcFZRY3NnOGd2WU1t?= =?utf-8?B?ZXdTRG51OUdCOFZTYityMTdRQkpLZDh5R0ZQTkpkYjY2OWNmNUFFZyt5NnlC?= =?utf-8?B?RzF1dGdrbkV4dUI2R01FV0VocjcwQm1mMURubE5nMkZOb0Fub3lLaG5NZ1JI?= =?utf-8?B?SFIxYnVQeUU5djBzRkhQa1hycXBZRDBwK09wL3pXU0cyWXJsZ2hhWi92b2NM?= =?utf-8?B?NDRwakJpRGpDeEF4clE5UU5EbVRyZHNUVWU1SCtHTGxiK1I4eGRQNWwxTUZx?= =?utf-8?B?SHc3aUJJK20vbXZxamZpTUhDK3FsSGxzWnhoTVBUT1MvRnVvL2trbHVBQzM4?= =?utf-8?B?WjdSbjhjcFRhSlBucHJpaVBnbFkxTW45NEUxTTFQa0pEK2NlQ3NxT3hlNHlT?= =?utf-8?B?RGRiREUrV3NHb29QdW1vU1N3azAwblBGWVNNRFFRMWJkaS95b3hmSmxIRXRI?= =?utf-8?B?K3FTZkkrSFZ1L3l4NGZad0RMa0hpczNuK0MrL1gvRUQvcjhzN3g3WjZhK29S?= =?utf-8?B?ZDQ0YitYY2QrVXhWZDdHTGMyUWNVdHBPSlVGSldpbnVHSURtT01pbVN0NU9I?= =?utf-8?B?OXJJbkM1ZnBmQldHdFJBZW1MWTF6bmp4VGszTTJ2RnFpYjEva2h1LzR5eVYv?= =?utf-8?B?MkUwWHR1dUtaeG00VFdpdVgwUHlNTGQrSEhyeDI3eHAxZTJRWlBVZkh2VGJv?= =?utf-8?B?emVjZE5xNlpVaVhjNWpyeDZlRWJCOTFDalhYQW8vZnFSU1U1MHhwY0dvMGFD?= =?utf-8?B?Ull2OTlKUy9wQTJqQTM0MUtiZUFLODhRUmQyNWVZc1FheWZZa1M5dkZEdXlN?= =?utf-8?B?U1hXQnl6U09yeTdWNXZXWjRDYmppY0NHS0R3SzNSVEJPcWlqS0pKekNxWUtL?= =?utf-8?B?RkpkNjBtQ1gyYnRpWVQ0RXlidGIxQjBHN2dMeWFoWmE5N3dIRFNHREttdnhW?= =?utf-8?B?eDNLY0gxanliVHNPMGpjaXMyUkUvNEx1c2xqVUdsU1hZSmp1RU9kSkcrL2pE?= =?utf-8?B?ZnNuekdCaVdrMVNERmxjWi9ZOEQ1L1BZV0F6bThTWG8wR3lpUHd5U2lXNzV0?= =?utf-8?B?YkRVM3RhN2hiZncrcFhQVFpoVXZ2dXBaeFgwbWFFaUpKZG15WGZEdkxYVFJD?= =?utf-8?B?VXVTWUsxNUVYa29uQytSYWNsV2NkTlp2S2ZIMXViUjMxUyt2MWNHVXhoNVdj?= =?utf-8?B?VFordkZCeUxKcy9Xa3ljL29CbVlXRW5tdXhURUFLODk0Rm1lNndkWlc3Y3NB?= =?utf-8?B?M0oxR05Mcms2cWxyMUlES0llRE5MSjFuODlIdk5XS3BlL1hFNE1zWUVzMC8x?= =?utf-8?B?S0FZSGxTVUZuSmtUSnQrNzU3N0Y4UjE4UExCVCtRTlFReG5Vd2NicnNZTWFq?= =?utf-8?B?QnUzTDJ1ckRZVkV6eVc2VDFFdmtwMGVPcHhVdnRjZjhqZVJxN252VDFwejgx?= =?utf-8?B?MytYbTJEREpGR3AySVdjT2N0YisxQkJKakRwMWNYTlNsMDBOWVhDUXA0bits?= =?utf-8?B?Qk5Qb2hxZ0JrVVdabXRwQml6YngydCtUT0JISmJWWkVXZ2RQSDBBa2xFZVJp?= =?utf-8?B?Q0VpbStTUHlzMkdJWm1GTVhDb2Q2Z0pSdXJkYUh4S1VyRitRaTFjSnIvN0FN?= =?utf-8?B?T0RYRk9iNDhnSzNrV1F5S3NiSk9Da0srQ2NtdEVBZ1JzVDJNcms2SDRwV285?= =?utf-8?B?cVpCZE1tZTgzdFhlRm9mQlNub2xETmF1bFFFUHRIVDlDRXhTOW96d1MzdE9T?= =?utf-8?Q?Lj2W+/lxS1wQ/ZKDw93Q8k+a6c29dEEAPgcl0=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(39860400002)(396003)(366004)(376002)(52024003)(199004)(189003)(478600001)(6512007)(6436002)(6116002)(3846002)(66066001)(6306002)(99286004)(8936002)(2616005)(81156014)(33656002)(81166006)(6246003)(8676002)(5660300002)(58126008)(36756003)(316002)(2906002)(186003)(7736002)(83716004)(71190400001)(44832011)(71200400001)(97736004)(86362001)(82746002)(110136005)(256004)(26005)(14444005)(486006)(476003)(6486002)(6506007)(229853002)(53546011)(25786009)(68736007)(106356001)(14454004)(102836004)(966005)(105586002)(305945005)(2501003)(53936002)(153083001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3949; H:VI1PR07MB3167.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: PNHRG3+/7DuaunaqCPNBKdKH+j920aYQotrLFebXFKcOrcK6wIRzONtNEPQtIxYTcQd8K42b6K+xigkcFXfWqL4xS2zpg+oWk+4o4FnD8ChPQyQPqObFG+5lzzjiQDLGIAv+OUQCMrdoyiyinvSgo+KpIBiMeZ+WpinbhZ3LHCpz2Og8mbm0erqGA/Zl2CvSfo7ENYO0qyGdJNeG3LFBsUMAAv3Q0jXAWQZ3GK38ZBVi6UXJSiSK3L4d/0C2mPDKXLSRwHoNlJI0nDRHUnUttxmj6pf/gQIYy2GwQrb5hETH2PN9sJtqKJs5Rf5Gu792efrUeWOXLTTllTerMNB8ZmAbZwPLSAPBxvk7EwApMmFtrC9wo7Ue8g0hClIMVSrVO2GahOwFBo7XQ/dPHS4GFekKUFSLDwqyIzqsky17cWk= Content-Type: text/plain; charset="utf-8" Content-ID: <78ECAB27E002CC409BE208809F275BE0@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 62d78ae1-9ff3-4c0d-0f9d-08d6a2ebc77c X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2019 10:58:06.5383 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3949 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe3fO2Y6z4et0+aAVuPqipqbdhpTlh8jEwEC6CrXyoOKctmNe P7SUIXMmippthhrOhJn3oRmCKKFZiXZRMjAcips4w8iVN6xtx6Bvv//zf573ufDShLie8qfT lNmMSilXSPlCUn+tLzc0ZkOddNT4UyRr0L4TyBzr3XzZVtcscY6I7TfMCmKNxg1erKF/gUwg bghPJzOKtBxGFR59W5i6M/6Nl2U7lVczoybUqPNkKfKgAR+HkjeTglIkpMX4NYK6VTXFCQeC 5j79rmjigW1xkO8SJK4gQGt9T3BOJQ9WrY8RJywIOiqLnK/RNB/LQLcT4mrii5VQX9zurvbB 1Qh6DW2kS/jiGgTFtZMklxUGttJWN5P4MJgHvghcLMJnoffzNuFihPfB77cveC4msB98XWjg cWtgMA5MEBxLYGl+h3KxBIeDuXyO5GrlMGia280JhPHvlt3aA/CxQYc4vgSOtR73cIBnnMOZ tQLOCIZ5/RLFsT88m1gTcElT3mCyV/A5Ix0ejtpJjvfDyPNRxCWtUtDzSeM2xJiBljbNbruD YHpkIStQqOG/jQzO8xE4CDpehXPhWCiyOiiOA6FaZxEY3IfxhjH9AtmIKBOSsAzLZqRERoYx qrS7LJupDFMy2d3I+WuGzFtRL9GQNWYYYRpJ94pEy+okMSXPYfMzhhHQhNRXNOYKiZLl+QWM KvOW6r6CYYdRAE1K/UTbYu8kMU6RZzPpDJPFqP65PNrDX43qmo5MSNS1Y4eWCaFxU7N+RWxq fDBQWkZIQfvjT2GAfXEo2kdn9PzgOXKMzJnSnFkhp+OvNsvueSmuj5y4oA3ZzA1KtMcbaxPb LhcRN8s7dQVdG4lPIxKCvAqfRMVvTF+khvImV8r2lFQVtLRXFcYpl2vvtP6yaaQzMklc9Hkp yabKI4IJFSv/Czn8FHIxAwAA Archived-At: Subject: Re: [sipcore] Syntax of Feature-Caps header - suggestion to remove Feature-Caps header field in REGISTER 555 responses - the pull request X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 10:58:14 -0000 VGhlIHB1bGwgcmVxdWVzdDoNCg0KaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LXNpcC1w dXNoL3B1bGwvNDANCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K77u/T24gMDcvMDMvMjAxOSwg MTAuNTksICJzaXBjb3JlIG9uIGJlaGFsZiBvZiBDaHJpc3RlciBIb2xtYmVyZyIgPHNpcGNvcmUt Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPiB3cm90ZToNCg0KICAgIEhpLA0KICAgIA0KICAgIEkgd2lsbCBnbyBhaGVhZCBhbmQgc3Vn Z2VzdCB0aGF0IHdlIFJFTU9WRSB0aGUgdXNhZ2Ugb2YgdGhlIEZlYXR1cmUtQ2FwcyBoZWFkZXIg ZmllbGQgaW4gUkVHSVNURVIgNTU1IHJlc3BvbnNlcy4gVGhpcyBtZWFucyB0aGF0IHRoZSBuZXR3 b3JrIGNhbm5vdCBpbmZvcm0gdGhlIFVBIGFib3V0IHN1cHBvcnRlZCBQTlNzIGluIGEgNTU1IFJF R0lTVEVSIHJlc3BvbnNlLCBidXQgdGhlIG5ldHdvcmsgY2FuIHN0aWxsIGRvIGl0IGluIGEgMjAw IFJFR0lTVEVSIHJlc3BvbnNlIChxdWVyeSBtb2RlKS4NCiAgICANCiAgICBQbGVhc2UgbGV0IG1l IGtub3cgYXNhcCBpZiB5b3UgZGlzYWdyZWUgd2l0aCBzdWNoIGFwcHJvYWNoLiBJIHdpbGwgcHJl cGFyZSBhIFBSIGR1cmluZyB0aGUgZGF5Lg0KICAgIA0KICAgIFJlZ2FyZHMsDQogICAgDQogICAg Q2hyaXN0ZXINCiAgICANCiAgICANCiAgICANCiAgICANCiAgICANCiAgICANCiAgICBPbiAwNi8w My8yMDE5LCAxNy4yMCwgInNpcGNvcmUgb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJnIiA8 c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20+IHdyb3RlOg0KICAgIA0KICAgICAgICBIaSBZZWhvc2h1YSwNCiAgICAgICAg DQogICAgICAgID5UaGUgbGFzdCBmaXggeW91IG1hZGUgaW4gdGhlIGV4YW1wbGUgbWFkZSBtZSBy ZS1yZWFkIFJGQyA2ODA5Lg0KICAgICAgICA+SSBub3RpY2VkIHRoYXQgdGhlIFJGQyBpbmRpY2F0 ZXMgdGhhdDoNCiAgICAgICAgPiAgIFRoZSBGZWF0dXJlLUNhcHMgaGVhZGVyIGZpZWxkIGNhbiBi ZSB1c2VkIHdpdGhpbiBhIFNJUCBSRUdJU1RFUg0KICAgICAgICA+ICAgcmVxdWVzdCBhbmQgd2l0 aGluIHRoZSAyMDAgKE9LKSByZXNwb25zZSBhc3NvY2lhdGVkIHdpdGggc3VjaCBhDQogICAgICAg ID4gICByZXF1ZXN0Lg0KICAgICAgICA+DQogICAgICAgID4gQWx0aG91Z2ggbm90IGV4cGxpY2l0 bHkgZm9yYmlkZGVuLCBhIEZlYXR1cmUtQ2FwcyBoZWFkZXIgaXMgbm90IGV4cGVjdGVkIHRvIGJl IGluY2x1ZGVkIGluIG5vbi0yMDAgcmVzcG9uc2VzLg0KICAgICAgICA+IEluIHRoZSBkcmFmdCwg dGhlcmUgYXJlIGNhc2VzIHRoYXQgZG8gaW5jbHVkZSBGZWF0dXJlLUNhcHMgaGVhZGVyIGluIHN1 Y2ggcmVzcG9uc2VzIChsaWtlIDU1NSkuDQogICAgICAgIA0KICAgICAgICBDb3JyZWN0LiBHb29k IGNhdGNoLg0KICAgICAgICANCiAgICAgICAgPkkgYmVsaWV2ZSB0aGF0IHRoZSBkcmFmdCBtYWtl cyBhIGNvcnJlY3QgdXNlIG9mIHRoZSBoZWFkZXIsIGJ1dCBpdCBtaWdodCBiZSB3b3J0aCB0aGlu a2luZyB3aHkgUkZDIDY4MDkgaGFzIG5vdA0KICAgICAgICA+dGhvdWdodCBvZiB0aGlzIHVzZSBj YXNlLg0KICAgICAgICANCiAgICAgICAgSSBhc3N1bWUgdGhlIHJlYXNvbiBpcyB0aGF0IHRoZSBz Y29wZSBvZiBhIGZlYXR1cmUtY2FwYWJpbGl0eSBpbmRpY2F0b3IgaXMgdGhlIGJpbmRpbmcgY3Jl YXRlZCBieSBhIFJFR0lTVEVSLzIwMC4NCiAgICAgICAgDQogICAgICAgIE9uZSBvcHRpb24gd291 bGQgYmUgdG8gc2F5IHRoYXQgc2lwLXB1c2ggdXBkYXRlcyA2ODA5IGJ5IGFsbG93aW5nIHRoZSBG ZWF0dXJlLUNhcHMgaGVhZGVyIGluIDU1NS4NCiAgICAgICAgDQogICAgICAgIEFub3RoZXIgb3B0 aW9uIHdvdWxkIGJlIHRvIHJlbW92ZSB0aGUgRmVhdHVyZS1DYXBzIGhlYWRlciBmcm9tIDU1NSBy ZXNwb25zZXMuIEl0IHdvdWxkbid0IGFmZmVjdCB0aGUgbWVjaGFuaXNtIGluIGdlbmVyYWwsIGFz IGl0IG9ubHkgcHJvdmlkZXMgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiAoYW5kLCBpbmNsdWRpbmcg Ri1DIGluIDU1NSBpcyBvbmx5IGEgU0hPVUxEKS4gSWYgYSBVQSBzdXBwb3J0cyBtdWx0aXBsZSBQ TlNzIGl0IGNhbiBhbHdheXMgcGVyZm9ybSBhIHF1ZXJ5IHRvIGZpbmQgb3V0IHdoYXQgUE5TcyB0 aGUgbmV0d29yayBzdXBwb3J0LiBJZiB0aGUgVUEgb25seSBzdXBwb3J0cyBvbmUgUE5TLCBhbmQg dGhlIG5ldHdvcmsgZG9lc24ndCBzdXBwb3J0IGl0IGFuZCBzZW5kcyA1NTUsIGl0IGRvZXNuJ3Qg cmVhbGx5IG1hdHRlciB0byB0aGUgVUEgd2hhdCBQTlMgdGhlIG5ldHdvcmsgc3VwcG9ydHMuDQog ICAgICAgIA0KICAgICAgICBSZWdhcmRzLA0KICAgICAgICANCiAgICAgICAgQ2hyaXN0ZXINCiAg ICAgICAgDQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgT24gRnJpLCBNYXIgMSwgMjAxOSBh dCAxOjIyIFBNIENocmlzdGVyIEhvbG1iZXJnIDxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPiB3cm90ZToNCiAgICAgICAgSGksDQogICAgICAgICANCiAgICAgICAgSSBhbHNv IG5vdGVkIHRoYXQgYWRkaW5nIHRoZSDigJgr4oCZIGlzIG5vdCBlbm91Z2guIE5vdGUgdGhhdCB0 aGUgRmVhdHVyZS1DYXBzIGhlYWRlciBmaWVsZCBzeW50YXggYWxzbyBtYW5kYXRlcyB0aGUg4oCY KuKAmS4NCiAgICAgICAgIA0KICAgICAgICBTbywgdGhlIGNvcnJlY3Qgd2F5IGlzOg0KICAgICAg ICAgDQogICAgICAgIEZlYXR1cmUtQ2FwczogKjsrc2lwLjYwOA0KICAgICAgICAgDQogICAgICAg IFJlZ2FyZHMsDQogICAgICAgICANCiAgICAgICAgQ2hyaXN0ZXINCiAgICAgICAgIA0KICAgICAg ICAgDQogICAgICAgIEZyb206IHNpcGNvcmUgPG1haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5v cmc+IG9uIGJlaGFsZiBvZiBDaHJpc3RlciBIb2xtYmVyZyA8bWFpbHRvOmNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbT4NCiAgICAgICAgRGF0ZTogVGh1cnNkYXksIDI4IEZlYnJ1YXJ5IDIw MTkgYXQgMTYuNTANCiAgICAgICAgVG86IFllaG9zaHVhIEdldiA8bWFpbHRvOnlvc2hpZ2V2QGdt YWlsLmNvbT4NCiAgICAgICAgQ2M6ICJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyIgPG1haWx0bzpz aXBjb3JlQGlldGYub3JnPg0KICAgICAgICBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFN5bnRheCBv ZiBGZWF0dXJlLUNhcHMgaGVhZGVyDQogICAgICAgICANCiAgICAgICAgSEkgWWVob3NodWEsDQog ICAgICAgICANCiAgICAgICAgUGxlYXNlIHNlZSBpbmxpbmUuDQogICAgICAgICANCiAgICAgICAg PkkgaGF2ZSBhIHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGUgc3ludGF4IG9mIHRoZSBGZWF0dXJlLUNh cHMgaGVhZGVyIHNpbmNlIEkndmUgbm90IG1hbmFnZWQgdG8gZmluZCBhbnkgcmVhbCBleGFtcGxl cyBvZiBpdHMgdXNhZ2UuDQogICAgICAgID4gDQogICAgICAgID5UaGUgQUJORiBpbiBSRkMgNjgw OSBpcyBkZWZpbmVkIGFzOg0KICAgICAgICA+ICAgRmVhdHVyZS1DYXBzID0gIkZlYXR1cmUtQ2Fw cyIgSENPTE9OIGZjLXZhbHVlDQogICAgICAgID4gICAgICAgICAgICAgICAgICAgKihDT01NQSBm Yy12YWx1ZSkNCiAgICAgICAgPiAgIGZjLXZhbHVlICAgICA9ICIqIiAqKFNFTUkgZmVhdHVyZS1j YXApDQogICAgICAgID4gICBmZWF0dXJlLWNhcCAgICAgICA9ICAiKyIgZmNhcC1uYW1lIFtFUVVB TCBMRFFVT1QgKGZjYXAtdmFsdWUtbGlzdA0KICAgICAgICA+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC8gZmNhcC1zdHJpbmctdmFsdWUgKSBSRFFVT1RdDQogICAgICAgID4gDQogICAgICAg ID4gRm9sbG93aW5nIHRoaXMgc3ludGF4LCBJIGd1ZXNzIHRoYXQgZm9yIHNpcC1wdXNoIHRoZSBo ZWFkZXIgd2lsbCBsb29rIGxpa2U6DQogICAgICAgID4gICBGZWF0dXJlLUNhcHM6ICo7K3NpcC5w bnM9IndlYnB1c2giDQogICAgICAgID4gDQogICAgICAgID4gDQogICAgICAgID5PbmUgZXhhbXBs ZSBJIGNvdWxkIGZpbmQgaXMgb24gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtc2lwY29yZS1yZWplY3RlZC0wMzoNCiAgICAgICAgPiAgIEZlYXR1cmUtQ2Fwczogc2lwLjYw OA0KICAgICAgICA+V2l0aG91dCB0aGUgYXN0ZXJpc2sgYW5kIHRoZSBwbHVzIHNpZ24uDQogICAg ICAgID4gDQogICAgICAgID4gV2hpY2ggb25lIGlzIGNvcnJlY3Q/IA0KICAgICAgICAgDQogICAg ICAgIFRoZSBzaXAucG5zIGV4YW1wbGUgaXMgY29ycmVjdC4gVGhlIHNpcC42MDggZXhhbXBsZSBu ZWVkcyB0byBiZSBjb3JyZWN0ZWQuIA0KICAgICAgICAgDQogICAgICAgIChJIFRISU5LIEkgaGFk IHByZXZpb3VzbHkgY29tbWVudGVkIG9uIHRoaXMgd2hlbiByZWFkaW5nIHNpcGNvcmUtcmVqZWN0 ZWQsIGJ1dCBJIG1heSBiZSB3cm9uZ+KApikNCiAgICAgICAgIA0KICAgICAgICA+RHVlIHRvIHRo ZSBsYWNrIG9mIGV4YW1wbGVzLCB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBhZGQgYW4gZXhhbXBs ZSB0byB0aGUgc2lwLXB1c2ggZHJhZnQgdGhhdCBpbmNsdWRlcyBmZWF0dXJlIGNhcGFiaWxpdGll cyANCiAgICAgICAgPmFuZCBtZWRpYSB0YWdzIChlc3BlY2lhbGx5IHRoYXQgc2lwLnBuc3JlZyBp cyB1c2VkIGZvciBib3RoKT8NCiAgICAgICAgIA0KICAgICAgICBJIHdpbGwgbG9vayBpbnRvIGl0 LiBJIGd1ZXNzIHRoYXQgY291bGQgYmUgZG9uZSB3aGVuIGFkZHJlc3NpbmcgQmVu4oCZcyBjb21t ZW50cy4NCiAgICAgICAgIA0KICAgICAgICBSZWdhcmRzLA0KICAgICAgICAgDQogICAgICAgIENo cmlzdGVyDQogICAgICAgICANCiAgICAgICAgDQogICAgICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgIHNpcGNvcmUgbWFpbGluZyBsaXN0 DQogICAgICAgIHNpcGNvcmVAaWV0Zi5vcmcNCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQogICAgICAgIA0KICAgIA0KICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgc2lwY29yZSBtYWlsaW5n IGxpc3QNCiAgICBzaXBjb3JlQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zaXBjb3JlDQogICAgDQoNCg== From nobody Thu Mar 7 10:42:01 2019 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 4663412796B for ; Thu, 7 Mar 2019 10:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.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 H3fEUge0YrOT for ; Thu, 7 Mar 2019 10:41:58 -0800 (PST) Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [198.46.93.79]) (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 7080A1277DE for ; Thu, 7 Mar 2019 10:41:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Message-Id:In-Reply-To:To:References:Date: Subject:Mime-Version:Content-Type:From:Sender:Reply-To:Cc: Content-Transfer-Encoding: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=RvNEsmgyTyuvFAWCQs7eg3CfIsdlZbhXAjW9RC2iZvQ=; b=gaYrx+G7h0ybf45Kyu0Fih6B0 6skz/BG1Mn0XwyWlEBzAEePMoe4c6lyuczj+IUr16L38x3zS+8punrnKw0j+p852tApN/SP/AFkvb aXLGhhkzPrP+4tP/Xch+qPTVsKpGvQuWp0OppJngWQM8c21qT8nb2NE+bv7j7MFkeI+uA=; Received: from [174.205.7.154] (port=10310 helo=[192.168.43.104]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h1xxk-006ANw-Im for sipcore@ietf.org; Thu, 07 Mar 2019 10:41:57 -0800 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_2931FE3E-281D-44B2-9F1A-FC869A45670D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 7 Mar 2019 13:41:46 -0500 References: <6fc6d835-a4c5-1fc1-677b-0ac14c241a6f@nostrum.com> To: SIPCORE In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.102.3) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-rejected Terminology X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 18:42:00 -0000 --Apple-Mail=_2931FE3E-281D-44B2-9F1A-FC869A45670D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 DeMorgan=E2=80=99 theorem for Standards, which I forgot: x UNLESS y is the same as FOR ALL NOT y, MUST x. Thanks! Anyone else? > On Mar 6, 2019, at 9:28 AM, Brian Rosen wrote: >=20 > 5) Cut the second Terminology paragraph. Reword the instances into If = MUST else SHOULD, but be explicit about the condition. >=20 >=20 >=20 >> On Mar 5, 2019, at 5:24 PM, Eric Burger = wrote: >>=20 >> Grumble, grumble. That=E2=80=99s my civil disobedience to (1) put the = 2119 language into active voice and (2) point out that SHOULD is useless = without UNLESS. The various levels of folding on my part would be: >>=20 >> (1) leave it as is >>=20 >> (2) cut the second Terminology paragraph and turn the =E2=80=98UNLESS' = instances into =E2=80=98unless' instances. >>=20 >> (3) cut the second Terminology paragraph and remove the unless = clause, turning the SHOULD into the useless SHOULD. >>=20 >> (4) cut the second Terminology paragraph and use the evil passive = voice version of the 2119 Terminology paragraph, written by non-writers >>=20 >> How low shall I go? ;-) I=E2=80=99m willing to go all the way if = demanded, but my vote would be to keep the language as is. However, = it=E2=80=99s only one vote - I=E2=80=99m the editor not author and = it=E2=80=99s a work group document, so I will bend to the will of the = work group. >>=20 >>> On Mar 5, 2019, at 2:01 PM, A. Jean Mahoney = wrote: >>>=20 >>> Hi Eric and Bhavik, >>>=20 >>> I've been working on the Document Shepherd write-up for the = sipcore-rejected draft. The draft's Terminology section and the = normative text that uses the term "UNLESS" need updating: >>>=20 >>> 2. Terminology >>>=20 >>> This document uses the terms "MUST", "MUST NOT", "REQUIRED", = "SHALL", >>> "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >>> "OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only >>> when, they appear in all capitals, as shown here. >>>=20 >>> As a matter of principle, this document uses the term "UNLESS" to >>> distinguish when a "SHOULD" means "MAY". Otherwise, the "SHOULD" >>> means "MUST". Without UNLESS, SHOULD is meaningless. A.k.a. >>> Burger's Law of Protocol Meaningless Terms. >>>=20 >>>=20 >>> The following two statements are covered by the "UNLESS" addition: >>>=20 >>> [1] >>> If an intermediary issues a 608 code, the intermediary SHOULD = include >>> a Call-Info header in the response, UNLESS there are indicators the >>> calling party will use the contents of the Call-Info header for >>> malicious purposes (see Section 6). >>>=20 >>> [2] >>> As such, the intermediary SHOULD play the announcement, >>> UNLESS the caveats described in Section 3.5 and Section 6 hold. >>>=20 >>>=20 >>> Would you rewrite these statements so that they only use the key = words described by [RFC2119][RFC8174]? As the statements are currently = constructed, it would be somewhat difficult for an implementer to know = what to do since both statements point to largish sections of = descriptive text. >>>=20 >>> Thanks! >>>=20 >>> Jean >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 --Apple-Mail=_2931FE3E-281D-44B2-9F1A-FC869A45670D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEfEc/N7T7IfiAuDEHDDCGh758rskFAlyBZeoACgkQDDCGh758 rslB2xAAk3XtFEgUx+j1TLZwReP5s+Y5zTAtOoyjJDD+T2Z37y/ap5Ky44o6+N6c xYagzQvImNuzYUMfP/yBwREOfL862HcdhTLXZRajegUGHKNA1pQBGzT9st/x4/oo QlMjcCpsv/j5S1olIIHFBU6j0w2AmOihhIzCJOqyP+QxYS7uCk1pki+2NJJAtDjW NXrsoFpRWA2EQD+Zt39Yt+UaC2QqH/2z+DMSdyts8nhKRtvWRpnbfaLazAi9Mr1L z2+gZFD99QxkTPYFdSbS5OaQKcOpcl2DdHKeznMsl5gp2Kr16TIJOpJRh+HeTD09 HGrgK53HOZBk6PTXZzJHaW9wPnyOZSxgLeySRst7Jls1lq3mG2/ZeP6KdqIUHxVB fySHwzSdkz4PbP9OGuZx+3/1B2QZq5Png3E7d6SLc1QR6bUrJPIrlTARRO4qCkHg W7rnMaRwihUF41mUf6H7pIkZE4T67Euj3MVGJfruF4S5dwrR2Z8DiQRsjvSPSJbH dd/kE2LCIH6oCuBibMaNnImv31pNf2BSnnYNCPgZjavBq4rJajuPAIQWAEQGEOKq PxxUvjUMGHimtR5kWRHBlaGUq/S+DX/ZnwZVFSqRHdbXjwPp1UUZPKqfseUJPmLq sffkDtNjHGZp6++KJw8UvLubydw1yITBGX+GIans4reXwIud/T0= =0IL/ -----END PGP SIGNATURE----- --Apple-Mail=_2931FE3E-281D-44B2-9F1A-FC869A45670D-- From nobody Thu Mar 7 12:04:11 2019 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 D043F130FC4 for ; Thu, 7 Mar 2019 12:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=rbbn.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 bIoeYJvthDc6 for ; Thu, 7 Mar 2019 12:03:58 -0800 (PST) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [216.205.24.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74739130EC6 for ; Thu, 7 Mar 2019 12:03:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1551988987; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references; bh=YMjWN8VRJDc9PUEhhyZIxG9kjs+YPDMMMY4DKWf2xzI=; b=FlI+CQcLWO1hOETaHtPoc8omgIqemA54P/lF7XwWRR8vXVZpmCrpw+KYE6mm1eA6BEdKbGLh2bQFi0gT8ac9uPIBcbO8EfzQo9uXJzH9l65b8B7Rcmgja+dVHH65d3cbS+qloSV1s1idFQyZc0nNQrbdW3pGCluByWKTlfsXCAo= Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-dm3nam05lp2055.outbound.protection.outlook.com [104.47.49.55]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-309-zDLK831APKaogiHC4o5Y-A-1; Thu, 07 Mar 2019 15:03:04 -0500 Received: from BN6PR03MB2802.namprd03.prod.outlook.com (10.175.125.8) by BN6PR03MB2434.namprd03.prod.outlook.com (10.168.223.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.17; Thu, 7 Mar 2019 20:03:01 +0000 Received: from BN6PR03MB2802.namprd03.prod.outlook.com ([fe80::2125:5072:debb:6ed1]) by BN6PR03MB2802.namprd03.prod.outlook.com ([fe80::2125:5072:debb:6ed1%5]) with mapi id 15.20.1686.018; Thu, 7 Mar 2019 20:03:01 +0000 From: "Asveren, Tolga" To: "sipcore@ietf.org" Thread-Topic: Re: [sipcore] draft-ietf-sipcore-rejected Terminology Thread-Index: AdTVIL1i+ElzYq4jRDmqAPTnDaFZ8w== Date: Thu, 7 Mar 2019 20:03:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.80.74.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 67a2e6ae-9867-426f-17de-08d6a337e73e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN6PR03MB2434; x-ms-traffictypediagnostic: BN6PR03MB2434: x-microsoft-exchange-diagnostics: 1; BN6PR03MB2434; 20:luwpUsdi6E2HKanjNhRk3oeSBFAfDfFMcPyc5avfiljuPwOoo1ca23Lgd/xrfyr0KiNhOv0tFpQNNHlBqm5HI65+dtVa4GVgM6AHR8n5M2s+uLD+Jfeyw4F/a9DAvuS20H2kmNGf7hEE3oMUU9dGG5XOCULWBfkIJ0ifgRV13as= x-microsoft-antispam-prvs: x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39860400002)(366004)(346002)(136003)(376002)(396003)(189003)(199004)(476003)(966005)(486006)(53546011)(74316002)(33656002)(7736002)(7696005)(54896002)(6506007)(53936002)(229853002)(71200400001)(5640700003)(71190400001)(9686003)(106356001)(55016002)(6306002)(2351001)(102836004)(105586002)(256004)(316002)(8936002)(6246003)(26005)(6436002)(478600001)(5660300002)(66066001)(6116002)(97736004)(790700001)(68736007)(3846002)(2501003)(81166006)(99286004)(186003)(1730700003)(14454004)(25786009)(8676002)(2906002)(81156014)(86362001)(6916009)(52536013)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR03MB2434; H:BN6PR03MB2802.namprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: IbgOqQQw+JvxLuHKNwecNX78PtM5m+L6eOjCp/S5cc9gnEvgu2v2XDYzwzcrqgnjMw10i1xSHm1F2kKvXGGtrxBiD2aG62eOWWKjbI1Cer2c2WcSJI74RlJlou6oXgClp7jHmfHbtk/v/od5teVKscqnlG+PLdVAFlWE+EqE189xvRSsCRuZqn9ZwpRjNph1te2x5jhsHLCxmvoyIl9HmnC49KRg6W9xsB+SB5vofWKSwIZgI9X6fAjm3F1YyT74WZdoaEHZ7G8GyjgbtZ+itpDihZ5FP3BEQB+XPCq8bL27oeO/2aAAX2TJN3rN216njZUpfbihnm+1wf7SK/ppDgUFo8eIUp/y5qB+lCu88VV2WU4v4HNwiYFdomEviIT5oz/iDvhNsLVnU6vVwYTO6tVrK9EdMrykmJQ9DlDLdCc= MIME-Version: 1.0 X-OriginatorOrg: rbbn.com X-MS-Exchange-CrossTenant-Network-Message-Id: 67a2e6ae-9867-426f-17de-08d6a337e73e X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2019 20:03:01.6778 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2434 X-MC-Unique: zDLK831APKaogiHC4o5Y-A-1 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="_000_BN6PR03MB28022F6AFD282FF0D91FD67EA54C0BN6PR03MB2802namp_" Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-rejected Terminology X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 20:04:04 -0000 --_000_BN6PR03MB28022F6AFD282FF0D91FD67EA54C0BN6PR03MB2802namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Both 2) and 5) sound good to me. Thanks, Tolga DeMorgan' theorem for Standards, which I forgot: x UNLESS y is the same as FOR ALL NOT y, MUST x. Thanks! Anyone else? > On Mar 6, 2019, at 9:28 AM, Brian Rosen wrote: > > 5) Cut the second Terminology paragraph. Reword the instances into If MUST else SHOULD, but be explicit about the condition. > > > >> On Mar 5, 2019, at 5:24 PM, Eric Burger wro= te: >> >> Grumble, grumble. That's my civil disobedience to (1) put the 2119 langu= age into active voice and (2) point out that SHOULD is useless without UNLE= SS. The various levels of folding on my part would be: >> >> (1) leave it as is >> >> (2) cut the second Terminology paragraph and turn the 'UNLESS' instances= into 'unless' instances. >> >> (3) cut the second Terminology paragraph and remove the unless clause, t= urning the SHOULD into the useless SHOULD. >> >> (4) cut the second Terminology paragraph and use the evil passive voice = version of the 2119 Terminology paragraph, written by non-writers >> >> How low shall I go? ;-) I'm willing to go all the way if demanded, but m= y vote would be to keep the language as is. However, it's only one vote - I= 'm the editor not author and it's a work group document, so I will bend to = the will of the work group. >> >>> On Mar 5, 2019, at 2:01 PM, A. Jean Mahoney wrote= : >>> >>> Hi Eric and Bhavik, >>> >>> I've been working on the Document Shepherd write-up for the sipcore-rej= ected draft. The draft's Terminology section and the normative text that us= es the term "UNLESS" need updating: >>> >>> 2. Terminology >>> >>> This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL", >>> "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >>> "OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only >>> when, they appear in all capitals, as shown here. >>> >>> As a matter of principle, this document uses the term "UNLESS" to >>> distinguish when a "SHOULD" means "MAY". Otherwise, the "SHOULD" >>> means "MUST". Without UNLESS, SHOULD is meaningless. A.k.a. >>> Burger's Law of Protocol Meaningless Terms. >>> >>> >>> The following two statements are covered by the "UNLESS" addition: >>> >>> [1] >>> If an intermediary issues a 608 code, the intermediary SHOULD include >>> a Call-Info header in the response, UNLESS there are indicators the >>> calling party will use the contents of the Call-Info header for >>> malicious purposes (see Section 6). >>> >>> [2] >>> As such, the intermediary SHOULD play the announcement, >>> UNLESS the caveats described in Section 3.5 and Section 6 hold. >>> >>> >>> Would you rewrite these statements so that they only use the key words = described by [RFC2119][RFC8174]? As the statements are currently constructe= d, it would be somewhat difficult for an implementer to know what to do sin= ce both statements point to largish sections of descriptive text. >>> >>> Thanks! >>> >>> Jean >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > ---------------------------------------------------------------------------= -------------------------------------------- Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipie= nt. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly= prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies,= including any attachments. ---------------------------------------------------------------------------= -------------------------------------------- --_000_BN6PR03MB28022F6AFD282FF0D91FD67EA54C0BN6PR03MB2802namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Both 2) and 5) sound good to me.

 

 

Thanks,

Tolga

 

 

DeMorgan’ theorem for Standards, which I forgo= t:

x UNLESS y is the same as FOR ALL NOT y, MUST x.

Thanks!

 

Anyone else?

 

> On Mar 6, 2019, at 9:28 AM, Brian Rosen <br@= brianrosen.net> wrote:

>

> 5) Cut the second Terminology paragraph.  = Reword the instances into If <condition> MUST else SHOULD, but be exp= licit about the condition.

>

>

>

>> On Mar 5, 2019, at 5:24 PM, Eric Burger <= ;eburger@standardstrack.com> wrote:

>>

>> Grumble, grumble. That’s my civil dis= obedience to (1) put the 2119 language into active voice and (2) point out = that SHOULD is useless without UNLESS. The various levels of folding on my = part would be:

>>

>> (1) leave it as is

>>

>> (2) cut the second Terminology paragraph an= d turn the ‘UNLESS' instances into ‘unless' instances.

>>

>> (3) cut the second Terminology paragraph an= d remove the unless clause, turning the SHOULD into the useless SHOULD.

>>

>> (4) cut the second Terminology paragraph an= d use the evil passive voice version of the 2119 Terminology paragraph, wri= tten by non-writers

>>

>> How low shall I go? ;-) I’m willing t= o go all the way if demanded, but my vote would be to keep the language as = is. However, it’s only one vote - I’m the editor not author and= it’s a work group document, so I will bend to the will of the work group.

>>

>>> On Mar 5, 2019, at 2:01 PM, A. Jean Mah= oney <mahoney@nostrum.com> wrote:

>>>

>>> Hi Eric and Bhavik,

>>>

>>> I've been working on the Document Sheph= erd write-up for the sipcore-rejected draft. The draft's Terminology sectio= n and the normative text that uses the term "UNLESS" need updatin= g:

>>>

>>> 2.  Terminology

>>>

>>> This document uses the terms "MUST= ", "MUST NOT", "REQUIRED", "SHALL",=

>>> "SHALL NOT", "SHOULD&quo= t;, "SHOULD NOT", "RECOMMENDED", "MAY", and

>>> "OPTIONAL" as described in BC= P14 [RFC2119][RFC8174] when, and only

>>> when, they appear in all capitals, as s= hown here.

>>>

>>> As a matter of principle, this document= uses the term "UNLESS" to

>>> distinguish when a "SHOULD" m= eans "MAY".  Otherwise, the "SHOULD"

>>> means "MUST".  Without U= NLESS, SHOULD is meaningless.  A.k.a.

>>> Burger's Law of Protocol Meaningless Te= rms.

>>>

>>>

>>> The following two statements are covere= d by the "UNLESS" addition:

>>>

>>> [1]

>>> If an intermediary issues a 608 code, t= he intermediary SHOULD include

>>> a Call-Info header in the response, UNL= ESS there are indicators the

>>> calling party will use the contents of = the Call-Info header for

>>> malicious purposes (see Section 6).

>>>

>>> [2]

>>>      &nbs= p; As such, the intermediary SHOULD play the announcement,

>>> UNLESS the caveats described in Section= 3.5 and Section 6 hold.

>>>

>>>

>>> Would you rewrite these statements so t= hat they only use the key words described by [RFC2119][RFC8174]? As the sta= tements are currently constructed, it would be somewhat difficult for an im= plementer to know what to do since both statements point to largish sections of descriptive text.

>>>

>>> Thanks!

>>>

>>> Jean

>>>

>>>

>>>

>>>

>>>

>>>

>>> _______________________________________= ________

>>> sipcore mailing list

>>> sipcore@ietf.org

>>> https://www.ietf.org/mailman/listinfo/sipcore

>>

>> ___________________________________________= ____

>> sipcore mailing list

>> sipcore@ietf.org

>> https://www.ietf.org/mailman/listinfo/sipcore=

>

 



Noti= ce: This e-mail together with any attachments may contain information of Ri= bbon Communications Inc. that is confidential and/or proprietary for the so= le use of the intended recipient. Any review, disclosure, reliance or dist= ribution by others or forwarding without express permission is strictly pro= hibited. If you are not the intended recipient, please notify the sender i= mmediately and then delete all copies, including any attachments.
--_000_BN6PR03MB28022F6AFD282FF0D91FD67EA54C0BN6PR03MB2802namp_-- From nobody Fri Mar 8 03:31:43 2019 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 7B05F12796C for ; Fri, 8 Mar 2019 03:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=NM+af9f3; dkim=pass (1024-bit key) header.d=ericsson.com header.b=OJ6h5UP1 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 Hce9pUZyZ_OJ for ; Fri, 8 Mar 2019 03:31:39 -0800 (PST) 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 A2EBF1277D8 for ; Fri, 8 Mar 2019 03:31:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552044696; x=1554636696; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1/akhBgkd/7H9LWwSsXzepIuGQ+AmHDRnJfFJMlppUE=; b=NM+af9f3ylIjSp3vYjXhTAHc4pVea12oK0ac21XdpImOv9+hc9IB+vFFa7zNFp8X TR7uVTZRBCcGFxm99M+rhccT3F8HdFfK/Cui3NXVicKmbn8/n1JzaWkAUz8vay0Q kmiXWfy5P85H8zhlckwc83RlKh8OIOPVal6hnxC0bto=; X-AuditID: c1b4fb2d-2198b9e00000062f-59-5c825298b780 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 15.D7.01583.892528C5; Fri, 8 Mar 2019 12:31:36 +0100 (CET) Received: from ESESBMR506.ericsson.se (153.88.183.202) by ESESBMB502.ericsson.se (153.88.183.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 8 Mar 2019 12:31:36 +0100 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMR506.ericsson.se (153.88.183.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 8 Mar 2019 12:31:36 +0100 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 8 Mar 2019 12:31:35 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1/akhBgkd/7H9LWwSsXzepIuGQ+AmHDRnJfFJMlppUE=; b=OJ6h5UP1CDyvwjJbr18I5JaQTsP4GDFaKrKhJ/l1hZHTdRPnvg+dfyZ/7GOhNdnJW2V5cN9K8rj9O9t50f2MMCyc5wd7gfJcYm/idQUiM3VlQrYtmlKfuQPXYTmWVcHmVTvMkvrFODZKgDlaNU5DcT7ILwtQvUtWtH8HC/An6DI= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4187.eurprd07.prod.outlook.com (20.176.166.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.15; Fri, 8 Mar 2019 11:31:34 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae%3]) with mapi id 15.20.1709.009; Fri, 8 Mar 2019 11:31:34 +0000 From: Christer Holmberg To: Yehoshua Gev , "sipcore@ietf.org" , Ben Campbell Thread-Topic: [sipcore] Syntax of Feature-Caps header - suggestion to remove Feature-Caps header field in REGISTER 555 responses - the pull request Thread-Index: AQHU1NSk8pGKS3LbGUe6Cll7rNPiZKYBvNSA Date: Fri, 8 Mar 2019 11:31:34 +0000 Message-ID: <1C6F1432-9CB9-45A2-A4AA-FF1DEEA1F211@ericsson.com> References: <59D9D95B-6789-4F2B-AF54-313FC651EA63@ericsson.com> In-Reply-To: <59D9D95B-6789-4F2B-AF54-313FC651EA63@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [192.176.1.88] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: afdd02a0-48be-4879-c122-08d6a3b99ed6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4187; x-ms-traffictypediagnostic: HE1PR07MB4187: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUI0MTg3OzIzOk9UZzF1OEpsNnA2R2d5MlJSZnA0UE42ODh5?= =?utf-8?B?QUFtZzY2dkFucHd6RDRWL2ZrclNvOWFvYWdmZCsyWllmZ3c0VWRpR0IzRTc0?= =?utf-8?B?UVZyUXVvZnJFUER6amZFcUhIUUhSNTRhUXJzYkxEMzJ2bTlpa2lHWGQzVk9Z?= =?utf-8?B?amxDNmZXYUtNbDBMcFdCQitPMW8vcHVWRGFIUzA5Y0lqa2MzVVdiQlBVd1Ev?= =?utf-8?B?dE9KQndoVlNKS0NwZC9UVmZTb1VReG43OERuK0xHVDU4cFJEQURhcGM2a1du?= =?utf-8?B?VzlUQUJEWU8rZVI5M1g4dnRSZlhUbGMyVzJYVXVGVE5CMXpEb3pyVFZoNVg0?= =?utf-8?B?T0ZSMzNmUG9CV1prS1NrZEhYM1FGbzY0d3BqaXVDLzJ2RzZUYlBDTm5BZERY?= =?utf-8?B?eTRUQjEwVlh1ajBwakhLZmNFU0xaUTZzcmhXNHZZd3RBY1BxYUEzT1kxbmpL?= =?utf-8?B?NkVIU1JHa0VSSWRJTUZPZytpaGNFSUhZNDQ5SkQrbFZwcnZobjF4UmZhY0lE?= =?utf-8?B?ZEJ3QVJFVGlWc0IvWUl4eGlwWTgyaGd2alFYcXZsaEdldjJHMzNtMUJVci9u?= =?utf-8?B?cnlZTy9MQ2RMaGE4Rk9KaTMxT2c5MEhSTHdZLzdEZzVFWFZnYXNYbVE3L2tD?= =?utf-8?B?c291dDRVelM4QkdDYjZaNTZPWmQ1ODBZMjkwVHE1Y0VYVVpSSzQ0RjNDcmhm?= =?utf-8?B?MHdUZ0Vva2VZOTNnOUZ3YTN6T3RRMVI3dnZXR2tURE1TLzNkdGIwclpSc1Fu?= =?utf-8?B?SEdGV1dKQmc3TTVZN0c5TW9OR3NMbE9DNVV4STFKR0p4TGdLWW1zV1ZDZnVK?= =?utf-8?B?NnFiOURsU3dLQjRMcFFJWnBuYkkvNXcvdGNlSlByY2lpdzlpQ3F6dXZ4Y0NB?= =?utf-8?B?aVVsSGNRNFdOb2NQM0ZyVmlXc05IclY3RktwUjNJWG5LWXR4QTlHNVk4S0lw?= =?utf-8?B?MzdnbTdQZGJ2Qy9HZnNSM0xjV2lyYUJ2U3dnZTk1TUxqSUZCb0g1MkxJcVZ0?= =?utf-8?B?QVpHNGljUU1XWXJ3dHZpQVo5SzljVGNFV3dOMlVYaThPeEhDd2JGbWJKSzVI?= =?utf-8?B?REdTenZYZjF4OUVoc01HNmRmV3NNRTdJN3c2eENsWS9CaWlnR0hTS09VdE8r?= =?utf-8?B?eXM3SmZhWXIzSG5WeG9rOGRZWnZRekgvY3RibzFvUHYyY29nYytYY3Y0eVhO?= =?utf-8?B?M3AvckVmbjViaVNWZFdNTVJpRWdwaHhCa1NwaXoxbnZLN01qWjJXUWlLQ2Z1?= =?utf-8?B?Y09KcmtYMDllaWc3QWFWYXNtaGt4V3Q5Sk1TWmNIYm1BYTZ5U1JOWVF4dXYv?= =?utf-8?B?ZEMxL0IyblRzUjNJbVdCSDN0UEh4a0xycGFzQUNHWklYb2plN01zeGRFVUZv?= =?utf-8?B?VGVtVDF0eUJTNjZKcTNycEhsRVAvaWVHcTdOSWFtZkdsNDJjdFF0VURQVnBm?= =?utf-8?B?QnZNbWIwZ1lWNGQ1eWI1VjFtaCtBcFRkWmZkT2N6QTVraUZxYnZ6Njh5QkdC?= =?utf-8?B?MXQ4ZHVWcVFqMDREZVE0dm80ZFl0VlFjcTBDTytERFBVY3ZuZm9EbVJ2bjVE?= =?utf-8?B?eFQweElDVWlScFhkSkU4UWtXODRqMU84cjVsczd3Ync0UzNKdm1oM00xRWhQ?= =?utf-8?B?KzNuaTJCM1o2QlBsRnh3K2lYK205OTNSUCt3ZzhSd1NUaDNXamY2dSt2Qk1B?= =?utf-8?B?OUV6SW1HL3ZKT2YwQkRoZHY2NWdaeWdOYWh5UFZkZmxCRnVaYmdUbUVmckNQ?= =?utf-8?B?cHNTc3NDS3pKS2x0UFFQMVA2ZEttTHhGa2NsM0d2RzQ4Qll2QjlKVnBMZXBO?= =?utf-8?B?S3BBTkNWTm5MMDRBa2Q0K0d2eVY5OGtmQjM2WUZiSHF5WCsyYmFPN1Q4cGsx?= =?utf-8?Q?6CcfCznKit8=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0970508454 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(39860400002)(396003)(346002)(376002)(52024003)(199004)(189003)(966005)(71190400001)(476003)(6306002)(71200400001)(11346002)(446003)(6486002)(6506007)(229853002)(97736004)(68736007)(2616005)(26005)(102836004)(256004)(316002)(76176011)(486006)(2906002)(14454004)(83716004)(110136005)(8676002)(99286004)(33656002)(8936002)(14444005)(53546011)(478600001)(105586002)(6512007)(53936002)(186003)(58126008)(81166006)(81156014)(6116002)(44832011)(25786009)(7736002)(3846002)(82746002)(66066001)(5660300002)(6436002)(36756003)(106356001)(2501003)(6246003)(305945005)(86362001)(153083001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4187; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: p8tvQejxnYdCL6z3B7YN1yybiUCKEH2K7I5ahguB2CO6HdI8H+2o5+1kE5M6MtGkMearbqax+TD7iLFEvDXpqMsrZGw1Sm2blHSrsR+imzT5d0eGMrT8OOP9VHpW4zEt4RCYxBEBCxLx382+egoDuaBXrGLkwlxULREIm8Vl96XAtphcx5LMOzj7GF5mI5mWD85XtRP3phrfx7VTrKKaqwE6mCsLm7B3sxeTSO1GndO3klH6vKraFxMgIkhnBIWvE3MnLN4lLn4sVnh9SfKNcdQjMGKTyzRwDZ7NoAh0qoGRX51Zu34vKldKrYOpVBIdUJ4Y57DhuyABRA26cxByu9aNh8AsZJOimhTxe5ODemmuTcVs5tCRz40SjTXHRX4WgcKR8UgoncLcNypTr+vs4McBE+L7xHVzPBuYZIacbVU= Content-Type: text/plain; charset="utf-8" Content-ID: <70646F10283FAF4DB7BFDC5F1E409103@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: afdd02a0-48be-4879-c122-08d6a3b99ed6 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2019 11:31:34.7574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4187 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe3fOtrPV4nXOfFgWNixS8ZofFt0stAZlaIVIWjn0oKZO2THJ PpQXDJwVZuZlklslE7QUL9gUNdSlmeK1D2UYSqOwVFTUFEvb8azo2+/5X3ifB16KkJbz5VSC Jo3WatRJCoGYLIt4xXiVXsiO8m0qD1Aa8vqFyuXVBoFyvX6CCCRULfoJoaqyco2n0rdYyVDi svhoLJ2UkE5rfY5Hi+P1c+vC1Mygm4Ot9YJMZDylQyIKcADMmhf4OiSmpNiC4FOHmccNywjq u03Ev6Haet8ee86D4kndlkPiAgIGsrLtsUIeGL8vkNwwhSC3tAPpEEUJsBLyNzzZF2VYAxU5 tQI244iLEDTrX24VZPgxgpySYZItyLA/NOYdZAskdoParNktWYJPwD1zJCtLbfihwiJgWYQD YbmkkGQZ4V3w890LHssEdoZxq4HHXYqhsm2I4NgJpr9s8Fl2wj7Q9GDS3lXD6+pJe8YV5p70 CzjeA6OGfMRxCHSPFG/tD/gjApOhym54QE97s5BjOTwdWhJyoREptM7U2Y1EWHpTJWSPAewC axaXAuSr/29Xvc0hsDvUtfpwsgqmygcQx/ugKH9KyLIEO0BfmZU0In41cmJohkmO8z/kTWsT YhgmReOtodMakO3LdDate5lRzY+TXQhTSLFDcvZIdpSUr05nMpK7EFCEQiZxDLJJklh1xi1a m3JNeyOJZrrQbopUOEt+SR2ipDhOnUYn0nQqrf3r8iiRPBOZeuUHLh3eu81Mhzv99mvvJzxj Ht1VLa5V9QjccgeZryvO/iuLz4a3b3x762o6f10XbzZeHb/NG3OE0z5DvcXhExNhYTtn4jaD I9GdcxG+PdX7S9JC3MfeX1xxmX/YlnCmzfXzaOOx1RaLQtnXeSV0c3y+Zl+0KH1sviVpusY3 OEhBMvFqPw9Cy6j/AEqztssuAwAA Archived-At: Subject: Re: [sipcore] Syntax of Feature-Caps header - suggestion to remove Feature-Caps header field in REGISTER 555 responses - the pull request X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 11:31:41 -0000 SGksDQoNClNpbmNlIG5vYm9keSBoYXMgb2JqZWN0ZWQgdG8gdGhlIHN1Z2dlc3RlZCBjaGFuZ2Us IEkgaW50ZW5kIHRvIG1lcmdlIHRoZSBQUiBhbmQgc3VibWl0IGEgbmV3IHZlcnNpb24gb2YgdGhl IGRyYWZ0Lg0KDQpDaGFuZ2U6IE5vIGxvbmdlciBhbGxvd2VkIHRvIGluc2VydCBGZWF0dXJlLUNh cHMgKGFuZCB0aGUgYXNzb2NpYXRlZCBzaXAucG5zIGZlYXR1cmUtY2FwYWJpbGl0eSBpbmRpY2F0 b3IpIGluIGEgNTU1IHJlc3BvbnNlLg0KUmVhc29uOiBSRkMgNjgwOSBvbmx5IGFsbG93cyBGLUMg aW4gUkVHSVNURVIgMjAwIHJlc3BvbnNlcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQrv u79PbiAwNy8wMy8yMDE5LCAxMi41OCwgInNpcGNvcmUgb24gYmVoYWxmIG9mIENocmlzdGVyIEhv bG1iZXJnIiA8c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KDQogICAgVGhlIHB1bGwgcmVxdWVzdDoNCiAg ICANCiAgICBodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtc2lwLXB1c2gvcHVsbC80MA0K ICAgIA0KICAgIFJlZ2FyZHMsDQogICAgDQogICAgQ2hyaXN0ZXINCiAgICANCiAgICBPbiAwNy8w My8yMDE5LCAxMC41OSwgInNpcGNvcmUgb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJnIiA8 c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20+IHdyb3RlOg0KICAgIA0KICAgICAgICBIaSwNCiAgICAgICAgDQogICAgICAg IEkgd2lsbCBnbyBhaGVhZCBhbmQgc3VnZ2VzdCB0aGF0IHdlIFJFTU9WRSB0aGUgdXNhZ2Ugb2Yg dGhlIEZlYXR1cmUtQ2FwcyBoZWFkZXIgZmllbGQgaW4gUkVHSVNURVIgNTU1IHJlc3BvbnNlcy4g VGhpcyBtZWFucyB0aGF0IHRoZSBuZXR3b3JrIGNhbm5vdCBpbmZvcm0gdGhlIFVBIGFib3V0IHN1 cHBvcnRlZCBQTlNzIGluIGEgNTU1IFJFR0lTVEVSIHJlc3BvbnNlLCBidXQgdGhlIG5ldHdvcmsg Y2FuIHN0aWxsIGRvIGl0IGluIGEgMjAwIFJFR0lTVEVSIHJlc3BvbnNlIChxdWVyeSBtb2RlKS4N CiAgICAgICAgDQogICAgICAgIFBsZWFzZSBsZXQgbWUga25vdyBhc2FwIGlmIHlvdSBkaXNhZ3Jl ZSB3aXRoIHN1Y2ggYXBwcm9hY2guIEkgd2lsbCBwcmVwYXJlIGEgUFIgZHVyaW5nIHRoZSBkYXku DQogICAgICAgIA0KICAgICAgICBSZWdhcmRzLA0KICAgICAgICANCiAgICAgICAgQ2hyaXN0ZXIN CiAgICAgICAgDQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQogICAgICAgIA0KICAgICAg ICANCiAgICAgICAgT24gMDYvMDMvMjAxOSwgMTcuMjAsICJzaXBjb3JlIG9uIGJlaGFsZiBvZiBD aHJpc3RlciBIb2xtYmVyZyIgPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCiAgICAgICAgDQogICAgICAg ICAgICBIaSBZZWhvc2h1YSwNCiAgICAgICAgICAgIA0KICAgICAgICAgICAgPlRoZSBsYXN0IGZp eCB5b3UgbWFkZSBpbiB0aGUgZXhhbXBsZSBtYWRlIG1lIHJlLXJlYWQgUkZDIDY4MDkuDQogICAg ICAgICAgICA+SSBub3RpY2VkIHRoYXQgdGhlIFJGQyBpbmRpY2F0ZXMgdGhhdDoNCiAgICAgICAg ICAgID4gICBUaGUgRmVhdHVyZS1DYXBzIGhlYWRlciBmaWVsZCBjYW4gYmUgdXNlZCB3aXRoaW4g YSBTSVAgUkVHSVNURVINCiAgICAgICAgICAgID4gICByZXF1ZXN0IGFuZCB3aXRoaW4gdGhlIDIw MCAoT0spIHJlc3BvbnNlIGFzc29jaWF0ZWQgd2l0aCBzdWNoIGENCiAgICAgICAgICAgID4gICBy ZXF1ZXN0Lg0KICAgICAgICAgICAgPg0KICAgICAgICAgICAgPiBBbHRob3VnaCBub3QgZXhwbGlj aXRseSBmb3JiaWRkZW4sIGEgRmVhdHVyZS1DYXBzIGhlYWRlciBpcyBub3QgZXhwZWN0ZWQgdG8g YmUgaW5jbHVkZWQgaW4gbm9uLTIwMCByZXNwb25zZXMuDQogICAgICAgICAgICA+IEluIHRoZSBk cmFmdCwgdGhlcmUgYXJlIGNhc2VzIHRoYXQgZG8gaW5jbHVkZSBGZWF0dXJlLUNhcHMgaGVhZGVy IGluIHN1Y2ggcmVzcG9uc2VzIChsaWtlIDU1NSkuDQogICAgICAgICAgICANCiAgICAgICAgICAg IENvcnJlY3QuIEdvb2QgY2F0Y2guDQogICAgICAgICAgICANCiAgICAgICAgICAgID5JIGJlbGll dmUgdGhhdCB0aGUgZHJhZnQgbWFrZXMgYSBjb3JyZWN0IHVzZSBvZiB0aGUgaGVhZGVyLCBidXQg aXQgbWlnaHQgYmUgd29ydGggdGhpbmtpbmcgd2h5IFJGQyA2ODA5IGhhcyBub3QNCiAgICAgICAg ICAgID50aG91Z2h0IG9mIHRoaXMgdXNlIGNhc2UuDQogICAgICAgICAgICANCiAgICAgICAgICAg IEkgYXNzdW1lIHRoZSByZWFzb24gaXMgdGhhdCB0aGUgc2NvcGUgb2YgYSBmZWF0dXJlLWNhcGFi aWxpdHkgaW5kaWNhdG9yIGlzIHRoZSBiaW5kaW5nIGNyZWF0ZWQgYnkgYSBSRUdJU1RFUi8yMDAu DQogICAgICAgICAgICANCiAgICAgICAgICAgIE9uZSBvcHRpb24gd291bGQgYmUgdG8gc2F5IHRo YXQgc2lwLXB1c2ggdXBkYXRlcyA2ODA5IGJ5IGFsbG93aW5nIHRoZSBGZWF0dXJlLUNhcHMgaGVh ZGVyIGluIDU1NS4NCiAgICAgICAgICAgIA0KICAgICAgICAgICAgQW5vdGhlciBvcHRpb24gd291 bGQgYmUgdG8gcmVtb3ZlIHRoZSBGZWF0dXJlLUNhcHMgaGVhZGVyIGZyb20gNTU1IHJlc3BvbnNl cy4gSXQgd291bGRuJ3QgYWZmZWN0IHRoZSBtZWNoYW5pc20gaW4gZ2VuZXJhbCwgYXMgaXQgb25s eSBwcm92aWRlcyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIChhbmQsIGluY2x1ZGluZyBGLUMgaW4g NTU1IGlzIG9ubHkgYSBTSE9VTEQpLiBJZiBhIFVBIHN1cHBvcnRzIG11bHRpcGxlIFBOU3MgaXQg Y2FuIGFsd2F5cyBwZXJmb3JtIGEgcXVlcnkgdG8gZmluZCBvdXQgd2hhdCBQTlNzIHRoZSBuZXR3 b3JrIHN1cHBvcnQuIElmIHRoZSBVQSBvbmx5IHN1cHBvcnRzIG9uZSBQTlMsIGFuZCB0aGUgbmV0 d29yayBkb2Vzbid0IHN1cHBvcnQgaXQgYW5kIHNlbmRzIDU1NSwgaXQgZG9lc24ndCByZWFsbHkg bWF0dGVyIHRvIHRoZSBVQSB3aGF0IFBOUyB0aGUgbmV0d29yayBzdXBwb3J0cy4NCiAgICAgICAg ICAgIA0KICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgIA0KICAgICAgICAgICAgQ2hy aXN0ZXINCiAgICAgICAgICAgIA0KICAgICAgICAgICAgDQogICAgICAgICAgICANCiAgICAgICAg ICAgIE9uIEZyaSwgTWFyIDEsIDIwMTkgYXQgMToyMiBQTSBDaHJpc3RlciBIb2xtYmVyZyA8bWFp bHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQogICAgICAgICAgICBI aSwNCiAgICAgICAgICAgICANCiAgICAgICAgICAgIEkgYWxzbyBub3RlZCB0aGF0IGFkZGluZyB0 aGUg4oCYK+KAmSBpcyBub3QgZW5vdWdoLiBOb3RlIHRoYXQgdGhlIEZlYXR1cmUtQ2FwcyBoZWFk ZXIgZmllbGQgc3ludGF4IGFsc28gbWFuZGF0ZXMgdGhlIOKAmCrigJkuDQogICAgICAgICAgICAg DQogICAgICAgICAgICBTbywgdGhlIGNvcnJlY3Qgd2F5IGlzOg0KICAgICAgICAgICAgIA0KICAg ICAgICAgICAgRmVhdHVyZS1DYXBzOiAqOytzaXAuNjA4DQogICAgICAgICAgICAgDQogICAgICAg ICAgICBSZWdhcmRzLA0KICAgICAgICAgICAgIA0KICAgICAgICAgICAgQ2hyaXN0ZXINCiAgICAg ICAgICAgICANCiAgICAgICAgICAgICANCiAgICAgICAgICAgIEZyb206IHNpcGNvcmUgPG1haWx0 bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBDaHJpc3RlciBIb2xtYmVy ZyA8bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCiAgICAgICAgICAgIERh dGU6IFRodXJzZGF5LCAyOCBGZWJydWFyeSAyMDE5IGF0IDE2LjUwDQogICAgICAgICAgICBUbzog WWVob3NodWEgR2V2IDxtYWlsdG86eW9zaGlnZXZAZ21haWwuY29tPg0KICAgICAgICAgICAgQ2M6 ICJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyIgPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KICAg ICAgICAgICAgU3ViamVjdDogUmU6IFtzaXBjb3JlXSBTeW50YXggb2YgRmVhdHVyZS1DYXBzIGhl YWRlcg0KICAgICAgICAgICAgIA0KICAgICAgICAgICAgSEkgWWVob3NodWEsDQogICAgICAgICAg ICAgDQogICAgICAgICAgICBQbGVhc2Ugc2VlIGlubGluZS4NCiAgICAgICAgICAgICANCiAgICAg ICAgICAgID5JIGhhdmUgYSBxdWVzdGlvbiByZWdhcmRpbmcgdGhlIHN5bnRheCBvZiB0aGUgRmVh dHVyZS1DYXBzIGhlYWRlciBzaW5jZSBJJ3ZlIG5vdCBtYW5hZ2VkIHRvIGZpbmQgYW55IHJlYWwg ZXhhbXBsZXMgb2YgaXRzIHVzYWdlLg0KICAgICAgICAgICAgPiANCiAgICAgICAgICAgID5UaGUg QUJORiBpbiBSRkMgNjgwOSBpcyBkZWZpbmVkIGFzOg0KICAgICAgICAgICAgPiAgIEZlYXR1cmUt Q2FwcyA9ICJGZWF0dXJlLUNhcHMiIEhDT0xPTiBmYy12YWx1ZQ0KICAgICAgICAgICAgPiAgICAg ICAgICAgICAgICAgICAqKENPTU1BIGZjLXZhbHVlKQ0KICAgICAgICAgICAgPiAgIGZjLXZhbHVl ICAgICA9ICIqIiAqKFNFTUkgZmVhdHVyZS1jYXApDQogICAgICAgICAgICA+ICAgZmVhdHVyZS1j YXAgICAgICAgPSAgIisiIGZjYXAtbmFtZSBbRVFVQUwgTERRVU9UIChmY2FwLXZhbHVlLWxpc3QN CiAgICAgICAgICAgID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgLyBmY2FwLXN0cmluZy12 YWx1ZSApIFJEUVVPVF0NCiAgICAgICAgICAgID4gDQogICAgICAgICAgICA+IEZvbGxvd2luZyB0 aGlzIHN5bnRheCwgSSBndWVzcyB0aGF0IGZvciBzaXAtcHVzaCB0aGUgaGVhZGVyIHdpbGwgbG9v ayBsaWtlOg0KICAgICAgICAgICAgPiAgIEZlYXR1cmUtQ2FwczogKjsrc2lwLnBucz0id2VicHVz aCINCiAgICAgICAgICAgID4gDQogICAgICAgICAgICA+IA0KICAgICAgICAgICAgPk9uZSBleGFt cGxlIEkgY291bGQgZmluZCBpcyBvbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1zaXBjb3JlLXJlamVjdGVkLTAzOg0KICAgICAgICAgICAgPiAgIEZlYXR1cmUtQ2Fwczog c2lwLjYwOA0KICAgICAgICAgICAgPldpdGhvdXQgdGhlIGFzdGVyaXNrIGFuZCB0aGUgcGx1cyBz aWduLg0KICAgICAgICAgICAgPiANCiAgICAgICAgICAgID4gV2hpY2ggb25lIGlzIGNvcnJlY3Q/ IA0KICAgICAgICAgICAgIA0KICAgICAgICAgICAgVGhlIHNpcC5wbnMgZXhhbXBsZSBpcyBjb3Jy ZWN0LiBUaGUgc2lwLjYwOCBleGFtcGxlIG5lZWRzIHRvIGJlIGNvcnJlY3RlZC4gDQogICAgICAg ICAgICAgDQogICAgICAgICAgICAoSSBUSElOSyBJIGhhZCBwcmV2aW91c2x5IGNvbW1lbnRlZCBv biB0aGlzIHdoZW4gcmVhZGluZyBzaXBjb3JlLXJlamVjdGVkLCBidXQgSSBtYXkgYmUgd3Jvbmfi gKYpDQogICAgICAgICAgICAgDQogICAgICAgICAgICA+RHVlIHRvIHRoZSBsYWNrIG9mIGV4YW1w bGVzLCB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBhZGQgYW4gZXhhbXBsZSB0byB0aGUgc2lwLXB1 c2ggZHJhZnQgdGhhdCBpbmNsdWRlcyBmZWF0dXJlIGNhcGFiaWxpdGllcyANCiAgICAgICAgICAg ID5hbmQgbWVkaWEgdGFncyAoZXNwZWNpYWxseSB0aGF0IHNpcC5wbnNyZWcgaXMgdXNlZCBmb3Ig Ym90aCk/DQogICAgICAgICAgICAgDQogICAgICAgICAgICBJIHdpbGwgbG9vayBpbnRvIGl0LiBJ IGd1ZXNzIHRoYXQgY291bGQgYmUgZG9uZSB3aGVuIGFkZHJlc3NpbmcgQmVu4oCZcyBjb21tZW50 cy4NCiAgICAgICAgICAgICANCiAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAgDQog ICAgICAgICAgICBDaHJpc3Rlcg0KICAgICAgICAgICAgIA0KICAgICAgICAgICAgDQogICAgICAg ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAg ICAgICAgICAgc2lwY29yZSBtYWlsaW5nIGxpc3QNCiAgICAgICAgICAgIHNpcGNvcmVAaWV0Zi5v cmcNCiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lw Y29yZQ0KICAgICAgICAgICAgDQogICAgICAgIA0KICAgICAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICBzaXBjb3JlIG1haWxpbmcgbGlz dA0KICAgICAgICBzaXBjb3JlQGlldGYub3JnDQogICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KICAgICAgICANCiAgICANCiAgICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIHNpcGNvcmUgbWFpbGlu ZyBsaXN0DQogICAgc2lwY29yZUBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KICAgIA0KDQo= From nobody Sun Mar 10 05:44:04 2019 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 9EC8C1200ED; Sun, 10 Mar 2019 05:43:56 -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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <155222183659.31102.8010690566294210914@ietfa.amsl.com> Date: Sun, 10 Mar 2019 05:43:56 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-28.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 12:43:57 -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 WG of the IETF. Title : Push Notification with the Session Initiation Protocol (SIP) Authors : Christer Holmberg Michael Arnold Filename : draft-ietf-sipcore-sip-push-28.txt Pages : 40 Date : 2019-03-10 Abstract: This document describes how a Push Notification Service (PNS) can be used to wake a suspended Session Initiation Protocol (SIP) User Agent (UA) with push notifications, and also describes how the UA can send binding-refresh REGISTER requests and receive incoming SIP requests in an environment in which the UA may be suspended. The document defines new SIP URI parameters to exchange PNS information between the UA and the SIP entity that will then request that push notifications be sent to the UA, and to trigger such push notification requests. The document also defines new feature- capability indicators that can be used to indicate support of this mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-28 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-28 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-push-28 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 Sun Mar 10 05:46:41 2019 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 ECFFF127982 for ; Sun, 10 Mar 2019 05:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=BOYdWDxI; dkim=pass (1024-bit key) header.d=ericsson.com header.b=kOEV/nkE 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 OcQ4Z05VeISK for ; Sun, 10 Mar 2019 05:46:38 -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 1D9ED1200ED for ; Sun, 10 Mar 2019 05:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552221996; x=1554813996; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5vrWC7HEG1B/cuAHiodwbCrwzLPXgbrIvrfmdPHY/RM=; b=BOYdWDxIzHtE2cMfXnVFk5FiZy9TThJ2AdwZ2d4r6S7e6QWR5978/hrWD7XHZsiM 11ZYgVRxnvXwA+ymwX69ukrdCJiQP2OGteB+fSckzEIuKSwq9DNKsqcwq6Cgypcb x4xj9ftpftBQuHllxe/yx4v3l7VYRdMzxqKx7ehPedo=; X-AuditID: c1b4fb30-fabff7000000355c-3d-5c85072b5481 Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C5.7B.13660.B27058C5; Sun, 10 Mar 2019 13:46:35 +0100 (CET) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sun, 10 Mar 2019 13:46:35 +0100 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sun, 10 Mar 2019 13:46:35 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5vrWC7HEG1B/cuAHiodwbCrwzLPXgbrIvrfmdPHY/RM=; b=kOEV/nkEDz2GinEg3wW0R7/SY1T1irySfYRxk6bw25cQIGD1J8INBzu9X0lac/LvFBCktFN8nsUPN/m9OPAHfTv/UHv9ndHds2j1InYPbFRIg3JsXXZbZlXR/rRWG4BMXpdbdpXKYtzA8wjlqOPTMBzNzOlYG4l6kbDoh7kkvvM= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB0953.eurprd07.prod.outlook.com (10.162.27.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.9; Sun, 10 Mar 2019 12:46:34 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae%3]) with mapi id 15.20.1709.011; Sun, 10 Mar 2019 12:46:34 +0000 From: Christer Holmberg To: "sipcore@ietf.org" CC: "sipcore-chairs@ietf.org" , Ben Campbell , Yehoshua Gev Thread-Topic: Draft new version: SIP Push -28 Thread-Index: AQHU1z9KCFpIU1Q1R0uUpMm3Kl000A== Date: Sun, 10 Mar 2019 12:46:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 x-originating-ip: [192.176.1.94] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2654186f-cc3b-49db-93dd-08d6a5566d70 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB0953; x-ms-traffictypediagnostic: HE1PR07MB0953: x-microsoft-antispam-prvs: x-forefront-prvs: 0972DEC1D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(366004)(136003)(396003)(189003)(199004)(54906003)(6486002)(6116002)(68736007)(316002)(105586002)(6506007)(25786009)(53936002)(6512007)(6306002)(99286004)(3846002)(66066001)(558084003)(256004)(58126008)(2906002)(486006)(44832011)(5660300002)(2616005)(476003)(86362001)(54896002)(5640700003)(1730700003)(81166006)(8936002)(106356001)(2351001)(81156014)(6346003)(102836004)(7736002)(2501003)(8676002)(26005)(82746002)(478600001)(97736004)(36756003)(6916009)(186003)(14454004)(71190400001)(83716004)(33656002)(6436002)(4326008)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB0953; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: x69k3vduGIiV++6QjwJTcsUQVNkA3AesXRkblCYP/WGfJWSPLbXGi+y+oZcKrjEqrSoR65mfc44fu3xUnR9f4WQPpkDsp8TVh0UeNmk7IS2Xlt/nl7vCJMl7AYNjWrLAhLfqoqrJq/DOcv5Ocp1Jxa5GzjNrje0bdvrNq+EwWYut/wbzCDzNOgvqH3O67J8lORrd3cieeWh9dLqJsTfrD8UFavWocHBYrdViUk1Si0Ae3sWLA7sNG/LefK42zIF0M/SZ4GFmz63TWLL4xFptjjCStOztH25GbZqp4pHmk7g8B+QDrY2DWRqHCz2lRJciAoDhBRnDBAPG/JZPF3HJTDg33LKv2NNh2Bf5FbsqL5di5LMZn0nQqgviadyiTX0iI+xXzzz3jCD/dovf5VRpk4XO7YskU8erpYzLRwat7tE= Content-Type: multipart/alternative; boundary="_000_B76B1E0826F9472CA92353DAE09224F0ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2654186f-cc3b-49db-93dd-08d6a5566d70 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2019 12:46:33.9747 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0953 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGee+9272OBm83Zwf7oAaFKX4UBSukjCBGGERURq106c1JOuXe FWlJxtofTZQhUtvK1odkadGHSqkrcdl3ZEUgpZYfC1mpK0ybKJrXd0H//d7nec7hnMPL0bxP Ec3lmC2CaDbmapUqxrX3gSU+jrUZkiqDyTrP2desrmz0Cq0bC91X6ibv9dApjL7J3cPqq6sn KL27yc/soPepkrOE3Jxjgpi4MUNlmrjhYguGlhz3TVRSJWh0sR1FcIDXwktHgLEjFcfjdgS/ v7ko2eDxOIK6kXRiVFMQan6E5AeDHTT8cLbSxKmgoP58iCKPfgTXvw6wdsRxSqyD0uk4uVUk XgU1442szDQ+CVfHupHMC3AMXLpZj0gmHrwX+ym5NBInwIvg3HgMXgG3pmfmZDXeBN5vqbKM cBT8eXWLIh0Xwme/hyLbYKj2dtCENRAYmFbIrMGJ0FDeyxB9Gdg6rQrCS+CDpxQR3g5PQ3eV 8iaAPyHoehYMh2LhnetHOHQEhr7bw40Ww3igiSYFPxXgGTyDyOkEqLltQ2RSI7TW9oYnWgq1 ZX0MKeigIfj+FXKgWPd/WxDOhLZJ/xyr8Xx46fIz7tkD0LN3vNOcSCLLobK0jyUcA7aLVWHW Q13fafb/zGXE1SKNJEiH8rLXrEkQxJxMSco3J5gFy300+7PaGiaTHqLA4GYfwhzSzlN/nDlj 4BXGY1Jhng8BR2sj1W+nZiV1lrGwSBDz08WjuYLkQ4s4RrtQPcXPN/A422gRjghCgSD+cyku IroEpZ5cuUp8s8uZVrd/Xdfw4RVfnpyLWpk43GtiK7YdcEY5CrxR3pFUw4XsqsdOZxpftJtv LOGKW1WBTVa7W0orbklab8o8Z+ted2ePb/kC87X+oYENBx35z1O2Wi9HY1Fn3nmi/XbnqaQ4 szVoaVHevVZVaN2/JRj6kFFU/rZC80vLSCbj6lhalIx/AZSx4qVVAwAA Archived-At: Subject: [sipcore] Draft new version: SIP Push -28 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 12:46:40 -0000 --_000_B76B1E0826F9472CA92353DAE09224F0ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiBTSVAgUHVzaC4NCg0KQmFz ZWQgb24gWWVob3NodWHigJlzIGNvbW1lbnRzLCBJIGhhdmUgcmVtb3ZlZCB0aGUgdXNhZ2Ugb2Yg RmVhdHVyZS1DYXBzIGluIFJFR0lTVEVSIDU1NSByZXNwb25zZXMuDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQo= --_000_B76B1E0826F9472CA92353DAE09224F0ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <0BE8F77147ECD34A9D979F4F57765D6C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRkkiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+SSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIFNJUCBQ dXNoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5CYXNlZCBvbiBZZWhvc2h1YeKAmXMgY29tbWVudHMsIEkgaGF2ZSBy ZW1vdmVkIHRoZSB1c2FnZSBvZiBGZWF0dXJlLUNhcHMgaW4gUkVHSVNURVIgNTU1IHJlc3BvbnNl cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B76B1E0826F9472CA92353DAE09224F0ericssoncom_-- From nobody Mon Mar 11 01:21:53 2019 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 6F14B13103D; Mon, 11 Mar 2019 01:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZO0U5c8LkO-s; Mon, 11 Mar 2019 01:21:42 -0700 (PDT) Received: from mailout21.telekom.de (MAILOUT21.telekom.de [194.25.225.215]) (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 95B1F130F4C; Mon, 11 Mar 2019 01:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1552292502; x=1583828502; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=l3/d+jACLV0CEOUppferx/5lqrYoCVx6EUJ3KrWl8gM=; b=J1L5d38Xudm4hKuStmDbQ8Y2/hgDP1YvZ9wKehLS9USMoNqN7NZf/5E4 Th/eHHNw5+fUwBAdDvQqkL+5kUNB0vZaSBqqTygNwtUK2bOh0WdF8USw3 j5z8LZLsIRlS5Fz4GGIqJsHT6lJ3qcUhwW5tOrglbg8uTMZW8QEhkvN9v +1VyKAi7Z+hs66nDXxO6osyCtodZ/QTCoLFfOgm/h65+Wn9Y/ziSSb0Sx dUMOp2MFknqNhbt06BG2SywtToOy9UtYFdxyTlKvo/hMOGU01tzeiVXng 9geyYy0fG7WyST/IsxQBLeZppvNV15WLYClsmSskhoybnNzl4GFpYyQxJ A==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Mar 2019 09:21:39 +0100 X-IronPort-AV: E=Sophos;i="5.58,467,1544482800"; d="scan'208";a="484665874" Received: from he105651.emea1.cds.t-internal.com ([10.169.119.62]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 11 Mar 2019 09:20:36 +0100 Received: from HE105651.EMEA1.cds.t-internal.com (10.169.119.62) by HE105651.emea1.cds.t-internal.com (10.169.119.62) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 11 Mar 2019 09:20:35 +0100 Received: from HE104163.emea1.cds.t-internal.com (10.171.40.38) by HE105651.EMEA1.cds.t-internal.com (10.169.119.62) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 11 Mar 2019 09:20:35 +0100 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.15) by O365mail05.telekom.de (172.30.0.230) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 11 Mar 2019 09:20:35 +0100 Received: from FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE (10.158.150.149) by FRXPR01MB0133.DEUPRD01.PROD.OUTLOOK.DE (10.158.150.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.20; Mon, 11 Mar 2019 08:20:35 +0000 Received: from FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE ([fe80::1dd6:9036:77f4:3bdb]) by FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE ([fe80::1dd6:9036:77f4:3bdb%6]) with mapi id 15.20.1686.021; Mon, 11 Mar 2019 08:20:35 +0000 From: To: , CC: , , Thread-Topic: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) Thread-Index: AQHU1MtbypIRSkP9z0SB907dYCfr7qYGG/mQ Date: Mon, 11 Mar 2019 08:20:34 +0000 Message-ID: References: <155193609023.13714.4531517779875308584.idtracker@ietfa.amsl.com> In-Reply-To: <155193609023.13714.4531517779875308584.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.220] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 88640678-f56b-4115-e0f1-08d6a5fa6f88 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:FRXPR01MB0133; x-ms-traffictypediagnostic: FRXPR01MB0133: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(346002)(39860400002)(376002)(366004)(189003)(199004)(55016002)(53936002)(71190400001)(71200400001)(9686003)(14454004)(26005)(186003)(561944003)(33656002)(74482002)(76176011)(97736004)(7696005)(6306002)(52396003)(105586002)(106356001)(6116002)(3846002)(86362001)(5660300002)(81166006)(256004)(81156014)(8676002)(2906002)(14444005)(450100002)(305945005)(75402003)(7736002)(102836004)(68736007)(478600001)(110136005)(486006)(966005)(54906003)(476003)(446003)(11346002)(72206003)(316002)(4326008)(66574012)(66066001)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:FRXPR01MB0133; H:FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-exchange-diagnostics: =?iso-8859-1?Q?1; FRXPR01MB0133; 23:NTFTdVE1QLuz1oAG9b8pAZyrmfcM8BRyoUQeKFg?= =?iso-8859-1?Q?hRyRmI6TQOgczTAteuUVgGEcQ/oXNyCZJz0cVeK+bd9sjtNWbiYfoswW+v?= =?iso-8859-1?Q?IQVFuQ0dkKKqQVAMZzF6A5cixLNTrVMmDNiitLPh+L6qQyQ2CFpeKSPARW?= =?iso-8859-1?Q?y3JNkWW01EhTfQnHBCazmymEmZQylRcHWc1prTyFXWQ4YFz3U0NPDBTstP?= =?iso-8859-1?Q?d9L6j8j76WcdHOafBwmhKvtPIaZ7F/4eQc5jf4ltmyJo2HRrrhe7FMDoe9?= =?iso-8859-1?Q?Ugi0YhyOBsvjZ31+Pci5hWpqXLurS/jTLHayyc2Okg/omDhE8Izi7yw6ef?= =?iso-8859-1?Q?FVOWN88ZRoZQIzfKm5VScYDg8uHECRB/5zdDDCArMAT2cZW4QG8Jb4oc9b?= =?iso-8859-1?Q?V5wpXbt7gW/okgvrzx3A+Ge7+Yfy8mZc4OOUlPqkYFhL56GiiXQRiM/p5k?= =?iso-8859-1?Q?/xTn+Wv4RMmkNauo0bo9O+3wXtHTLjncvymmCdXVsbuR/bukXWxpyJkP6t?= =?iso-8859-1?Q?SpzS3GuE9sfrPP0l4v3hSRyKWeEq1U4CUTmTjXL7qo65oO6qdykkUC3sjj?= =?iso-8859-1?Q?YgQmIjCjbjw0uQMTNhkeywiLHRrdreF3v7kft5mdT9o6azeGGw7EKH7mjZ?= =?iso-8859-1?Q?BbaP1TDlUAOMg4GZfNLpErnxoJd/N7KUNoabfBWmLFCGQpX/a37aKPOJkY?= =?iso-8859-1?Q?5wuZfRvsKwjqgvmZiVQWEKmetGde9dTFhPj7QQS4yGEIhWdi2Aigwmk1wR?= =?iso-8859-1?Q?dN+GabnbnLbNDgp5pvIVJJX7lkAvKiAiLWAvJNWC7U8iLtbKZ0XKtyG2ij?= =?iso-8859-1?Q?g9GvwI/iue+5cqGsFGiNVeMi38s7K65qYgQ7ik6T2UX+p5xHsQ+YdW0mr7?= =?iso-8859-1?Q?Io+ihUc2JFZ+eCqVsNzOqqX3WH2ji5ParcVMvrpr5xAyaW++V+UgmPMwlU?= =?iso-8859-1?Q?fpcP6Sdg5xb08QbqXgQYqrg/anNB8iKb8UEHw4R/9DbE7jEaa1Q0p6xlUG?= =?iso-8859-1?Q?1qDE/d5aIOYdp3B+RnQG1gO17H5IDWUSNgyZ0pzXbByF1WavHgCzzzgqrN?= =?iso-8859-1?Q?DtowFmOEQ7ned6RwJHN2WdU0h3SXdozvREIXBhSWgcmcwSFRSZuRT1vocz?= =?iso-8859-1?Q?gRmyR2hHiUb4Z3bV9pnNrDN5sUip97bUvMNUMYX72BLM2e1MxF42Nz8ZDA?= =?iso-8859-1?Q?cKj26YsbDvXws6XtjlOTXqiB4rU2O+imV0+fHTWlZk0FKC8vpaMnIPvGTG?= =?iso-8859-1?Q?E836rLfW6zfGuytz80sy2MbB8MzmTCR7iPsN29mDwexc+RnKgfOuXc1cD9?= =?iso-8859-1?Q?sj1PsKbKgpbjbeE1zWUr7pw?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 0sb+HTJLiF6F5+DvtqkZvnNVVL5+LTvBl/lY7+XVr1h7Hc52w4DD/m2C4jpNPFM6OjeAbahkg0vjlqF3WTbVemr9lNhUIDpv+ghfiy1qugi3hXKR+98IfeVhP3Lyfmqdah7Sbt/it9Qjj4in8xHVmEyanugxQt4N1hU3Po8bqXfM4wVavJek+icH8HCQORthAEcz2PqB91LWLR10ix/7PnLKgBSIV0gZ5bz9DbgMP4zqdXqqMxS7abVHm2pcjJOEsWlrfY5LSpbJSNEqPSKIVG0zqa5U5Gd4ccvKN/M9+kYRWu/Wivg1fGa6JaZ+uicHfrnK/ZZztIdOQayXm018IJ1ingpgEUYSuThxUDzh5RfymD4BnVGNiyxmrwFV2OVxxjF487YAniCPbBmL3kikhpoSx8Kfp0Bi86ZbByJHTQ8= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 88640678-f56b-4115-e0f1-08d6a5fa6f88 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2019 08:20:34.9961 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRXPR01MB0133 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 08:21:45 -0000 Hi, Thank you for your comments. I went through the comments and=20 here are my answers and proposals to the comments made. Sorry If some of you get the mail twice, since I answered in another way al= ready. Discuss on Section 4 Do you want to see something beyond the Note I put in? Note: These are the values defined within as loca= tion. Thus other values are not within the scope of this document. The last try to change these values in ITU-T was around 2001/2002 for some = mobile network code points. This was rejected since operators said that the= re is willingness to change ISUP for such coding points. The values are sta= ble since 20 years so there will be no change of these values in future, si= nce invest will go into IP based networks like IMS.=20 Comments on Section 1,3 and 4 Nits on Section 1+3 corrected. Section 4: I try to reformulate the sentence. Proposal: UAC or UAS SHALL include the location parameter in a request or respons= e when setting up the Reason header field with a [Q.850] cause. This app= roach is only possible in cases when the ISUP [Q.850] location is availabl= e. If you are OK with these changes I will produce a new draft and upload it. Thank you and Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore Im Auftrag von Datatracker on > behalf of Benjamin Kaduk > Gesendet: Donnerstag, 7. M=E4rz 2019 06:22 > An: The IESG > Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org; sipcore-chairs@ietf.org; > sipcore@ietf.org > Betreff: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason- > q850-loc-06: (with DISCUSS and COMMENT) >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-sipcore-reason-q850-loc-06: Discuss >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > 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-reason-q850-loc/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I support Adam's Discuss. >=20 > I also think that the Section 4 text: >=20 > The use of the location parameter is restricted to Q850 cause values. > Other values MUST be ignored if present. >=20 > needs to be clear about whether it is intended to limit to the exact 16 s= trings > listed above, or whether the intent is to update with Q850 if new values = are > allocated. Are string aliases allowed for the "national-use" codepoints = if > allocated within a given nation? >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Section 1 >=20 > the reason of release. The reason of release does indicate why a SIP > Dialog or an PSTN call, in case where the call was interworked to the >=20 > nits: s/does indicate/indicates/ ; s/an PSTN/a PSTN/ >=20 > Section 3 >=20 > The primary intent of the parameter defined in this specification is > for use in IMS (IP Multimedia Subsystem) networks defined by 3GPP but > also open to be used by any other network that includes ISUP >=20 > nit: s/also/it is also/ >=20 > Section 4 >=20 > Depending on whether the message is a request or a response the UAC > or UAS SHALL include the location parameter when setting up the > Reason header field with a [Q.850] cause. This approach is only > possible in cases when the ISUP [Q.850] location is available. >=20 > I don't understand what depends on whether the message is a request or a > response. >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Mar 11 01:25:34 2019 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 4407F13104B; Mon, 11 Mar 2019 01:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxT64VoY4soI; Mon, 11 Mar 2019 01:25:21 -0700 (PDT) Received: from mailout41.telekom.de (MAILOUT41.telekom.de [194.25.225.151]) (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 4787F130F4C; Mon, 11 Mar 2019 01:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1552292720; x=1583828720; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SyZXkRA/PQkgKpdbNOGvpOiOmkiL7BmRKgcd7DrUqes=; b=sU9V/u4eRHkPCedMyXoeZ1PUBDnv08CgnNjX5u5SG2KImfIw/BIxRKiZ f6aHDZ+sBsfXhPYSwrrmoaS6dtR4rujtZHOUSVTlYwvaHCpb4GZ6X9G9K CyfKr/yA2zzt42ksCpjTQ4CCEjLTpiJsamnRwcc8OAsbh8dKrto9JHBXa r6HoCfBtdAjcORZAV5w+yqgdvp4LoCbkJgQLlCsmMddcSbu695ls93W4p nBoa6YFax45rjDPYT/W4XznwxjDfMnION1Fbvzy/joVe09PQqE9EmxUCx y4oPDXSqn8fQfUsw8ea+9BdRBmbL8UdTk3rcZeJv/cshoyk1uY3kh/Knw Q==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Mar 2019 09:25:16 +0100 Received: from he105701.emea1.cds.t-internal.com ([10.169.119.22]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 11 Mar 2019 09:23:47 +0100 Received: from HE105700.EMEA1.cds.t-internal.com (10.169.119.29) by HE105701.emea1.cds.t-internal.com (10.169.119.22) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 11 Mar 2019 09:23:46 +0100 Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE105700.EMEA1.cds.t-internal.com (10.169.119.29) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 11 Mar 2019 09:23:46 +0100 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.22) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 11 Mar 2019 09:23:44 +0100 Received: from FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE (10.158.150.149) by FRXPR01MB0133.DEUPRD01.PROD.OUTLOOK.DE (10.158.150.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.20; Mon, 11 Mar 2019 08:23:42 +0000 Received: from FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE ([fe80::1dd6:9036:77f4:3bdb]) by FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE ([fe80::1dd6:9036:77f4:3bdb%6]) with mapi id 15.20.1686.021; Mon, 11 Mar 2019 08:23:42 +0000 From: To: , CC: , , , , Thread-Topic: Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) Thread-Index: AQHU0xJ/37mALULf3kix2lQq0GEU+KYGIJIg Date: Mon, 11 Mar 2019 08:23:42 +0000 Message-ID: References: <155176292818.5224.17119790703710957363.idtracker@ietfa.amsl.com> In-Reply-To: <155176292818.5224.17119790703710957363.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.220] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e9e25fa7-f534-4d35-fa19-08d6a5fadf81 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:FRXPR01MB0133; x-ms-traffictypediagnostic: FRXPR01MB0133: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(346002)(39860400002)(376002)(366004)(189003)(199004)(55016002)(53936002)(71190400001)(71200400001)(9686003)(14454004)(26005)(186003)(561944003)(33656002)(74482002)(76176011)(97736004)(7696005)(6306002)(52396003)(105586002)(106356001)(6116002)(3846002)(86362001)(5660300002)(81166006)(256004)(81156014)(8676002)(2906002)(14444005)(305945005)(75402003)(7736002)(102836004)(68736007)(478600001)(110136005)(486006)(966005)(54906003)(476003)(446003)(11346002)(72206003)(316002)(4326008)(66574012)(66066001)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:FRXPR01MB0133; H:FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-exchange-diagnostics: =?utf-8?B?MTtGUlhQUjAxTUIwMTMzOzIzOkFYdGxQZGNkOEVzdW15MEdzY1VCanlZTEVs?= =?utf-8?B?TW1OOERuNUhVd0pnOHU1OURGKzVNU1ZCNmI0MExOVlFPdHg0R3NxeU1WMjFY?= =?utf-8?B?Qm4vMzFOWTB1U21Na2RQQmZaQ1h4cU80bXNKeVZpQVFGaGhMdWZBNk40a1JG?= =?utf-8?B?andMU2MyVG8vOGlRQ2lTVHFuK2VNTTVUVmpLN2J3MjVJWUJPMWNsL09pODBJ?= =?utf-8?B?WFRzQVV0RVF2aEp5UGg3NEJZQ3h2OXZsem9YMHN5MFdjc0tteEMyVFFyZTVC?= =?utf-8?B?bmRYd1lrQzZrRGc5bENOZHIvY1E0TEI2Z2hTV3dNUHU4amlaZXljanF3QXZV?= =?utf-8?B?cis3M1IrZ2M4MVpZZEEyNTJ5Ykw3bXM2NExIQnFCQlBlZHFMeFZZZWpxdUtv?= =?utf-8?B?OWROalJ6V29kcW9IYnVEWnNiMGhIL05uUEFsYlRuNVBXYTZzUUNRWnVUMTFJ?= =?utf-8?B?Mm10Nk5BQ1pJOUdWMGV1ZC80cUlKNVdJZ2k4a3JWMldWUTFYdC9rUXlkc0VZ?= =?utf-8?B?RW5lb3BmZ2lQQlVDWmxTa21TRkdNNEpDVkpNUE5GbXB3SlUvWCtsZ0p4MEdG?= =?utf-8?B?cGNzNWZhMVdwei9kVWlwdllQOW9tb2pYVVdWUElJK1ZLNEREdUZRRXVsM0Yz?= =?utf-8?B?MkFhWVB2NVY3aFJzNkFwcThQWU53eHRtK1dPUjNyRThnTWFrMUZHRXhWdTZz?= =?utf-8?B?bG1uaHcxd0RnZGs0S3BVT2haRS9oWFJpZVV0eTVCVy9vUXFOUkJCSDREUTJH?= =?utf-8?B?c0VWVWtNY3doT2VsTlRvZnBnK1o0YU93cGl5a2dYdHZXc1pEaldtaElDWFZz?= =?utf-8?B?RUVHODdFOFVxUXdQTnJyMGNWZTNPeUlvMUpLVmo1VXF2RE9Gb0owc0FjdWQy?= =?utf-8?B?RmI0NS9SeE43cHlBMXVaVCtMUldQdlEvSkpzVG9tZUdxcUVuTm5WeFRDUEhQ?= =?utf-8?B?VjI4RVFXelFPb3ZGTDNvNUQ3dE80OExHVDRXc2F2eVUxNnIzOFNMSGkxcGVI?= =?utf-8?B?MU42UzlnMXRtb09Ya04yTVFkZ2M1aDJobERvelNxQ0NHc0NTMWxhWVlpU3NI?= =?utf-8?B?QWZLSXVkd3ZlcHQzb3pwUS9jNTRtRjVEenE2QUZNY25xRHlTdWJ6YytWMnFF?= =?utf-8?B?aHhBRDljNEpPM0I4eitwV25ndytKQXgxak1VWHJMRHNRcVk5cU1MZ3EwZitn?= =?utf-8?B?V28xR01TeU9xZkxvbTVqcEtiOFRVa1IzRFVnOCtzaktTMVdXTmQ5T1gvcWR6?= =?utf-8?B?YmhmZkZFWkhteDFibjVDMDZPZlozclRXQ05jNk42YzhJTUl4bStLRlprbFdU?= =?utf-8?B?cXpWd1RIeXVWLzZEeTM0bHlkK251bWgzVEJKSndpcFoyZEp0WVZZclhGN1ZJ?= =?utf-8?B?eWxZWjY4MWdhLzFCVVlqSkFsYXF0ZWlJUzdMcHFVQjkyb1VUbXJ4MHN3Z2gv?= =?utf-8?B?eDlPTis4UldBd2dlT25SS0hrRDR3MFYyT3NjVDk1VVppTmdHYWRXOWZkU0FD?= =?utf-8?B?b0dpRGVhM0lOVXBFWEt1T21DTUQ2QTkxdXBmV25VRlNiZFlZWUtkQTdKem5D?= =?utf-8?B?M2l0OURUM0JHRVJZSnduejIvd0lPOUZKRDJsd0FwY0dxOWVnNUJvVlMzUjBU?= =?utf-8?B?UmxLdURiRUxFZXZjcS84SFZDZ3A3bWsyOGtMMEZWZ3laOUxwWGxYSDBBPT0=?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: c9orxwIJ5Ko36rvmFXUgFO3RYgswNcicAREyf8j1No6w/ronbl4VQ6DJ3Xn+DQ0jEvAw5RDR9QJpk+wgj3lj9jpISoteOsKVVKUuFUZd6TTLafn8uaPQ07TDaXk1sXz86OcVmuOZSSzh0Dotse6GhtqX/ymP7bAe72yX9oz3Etns8iU72y1KgVSEnwVt24DH+rAlMWMQS7otrDMWpYBdjLNZjaqDgN9KuBDIne3nw8RCloFZYxx340euXYmXAnJjC5zVfIYVBhxUeEWYABbVTSC1TsGNTX9KQFpF9dK0kQeK1esGbEyQ1+czMw+OYWhGaONduhV8TelxnwyeUXMFuzxtXWpPauKXY0mgKRKixrRp3pv7jAC5uL6YDB3MWuN+wCGnid+u/qit7OxSdPpZnRhfHWtb2hYgA4zFK4o+Bjk= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e9e25fa7-f534-4d35-fa19-08d6a5fadf81 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2019 08:23:42.8897 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRXPR01MB0133 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 08:25:25 -0000 SGksDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuIEkgd2VudCB0aHJvdWdoIHRoZSBjb21t ZW50cyBhbmQgaGVyZSBhcmUgbXkgYW5zd2VycyBhbmQgcHJvcG9zYWxzIHRvIHRoZSBjb21tZW50 cyBtYWRlLg0KU29ycnkgSWYgc29tZSBvZiB5b3UgZ2V0IHRoZSBtYWlsIHR3aWNlLCBzaW5jZSBJ IGFuc3dlcmVkIGluIGFub3RoZXIgd2F5IGFscmVhZHkuDQoNCjEuICBEaXNjdXNzOg0Kwqc0IEFC TkYNCkhhdmUgaW5jb3Jwb3JhdGVkIHRoZSBwcm9wb3NhbC4NCg0KMS4gIENvbW1lbnRzOg0KSSBo YXZlIGluY29ycG9yYXRlZCBhbGwgcHJvcG9zZWQgY2hhbmdlcy4gDQrCpzEgZG9uZToNClRleHQg cmVhZHMgbm93Og0KUkZDNjQzMiBzcGVjaWZpZXMgdGhhdCBhIElTVVAgUS44NTAgY2F1c2UgY29k ZSBjYW4gYmUgY2FycmllZCB3aXRoaW4gYSBTSVAgcmVzcG9uc2UsIGJ1dCBub3QgdGhlIFEuODUw IGxvY2F0aW9uIGluZm9ybWF0aW9uLg0KDQrCpzQNClNvIHRleHQgcmVhZHMgbm93Og0KQXMgZGVm aW5lZCBieSBSRkM2NDMyIGFueSBTSVAgUmVzcG9uc2UgbWVzc2FnZSwgd2l0aCB0aGUgZXhjZXB0 aW9uIG9mIGEgMTAwIChUcnlpbmcpLCBNQVkgY29udGFpbiBhIFJlYXNvbiBoZWFkZXIgZmllbGQg d2l0aCBhIFEuODUwIFtRLjg1MF0gY2F1c2UgY29kZS4NCg0Kwqc1DQpEb25lIGFzIHByb3Bvc2Vk LiANClJlbW92ZWQgYmxhbmsgbGluZSBhbmQgYWRkZWQgdHdvIHZpYSBoZWFkZXIuDQoNCg0KSWYg eW91IGFyZSBPSyB3aXRoIHRoZXNlIGNoYW5nZXMgSSB3aWxsIHByb2R1Y2UgYSBuZXcgZHJhZnQg YW5kIHVwbG9hZCBpdC4NCg0KVGhhbmsgeW91IGFuZCBCZXN0IFJlZ2FyZHMNCg0KUm9sYW5kDQoN Cj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiBWb246IEFkYW0gUm9hY2gg PGFkYW1Abm9zdHJ1bS5jb20+DQo+IEdlc2VuZGV0OiBEaWVuc3RhZywgNS4gTcOkcnogMjAxOSAw NjoxNQ0KPiBBbjogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBkcmFmdC1pZXRmLXNp cGNvcmUtcmVhc29uLXE4NTAtbG9jQGlldGYub3JnOyBCcmlhbiBSb3Nlbg0KPiA8YnJAYnJpYW5y b3Nlbi5uZXQ+OyBzaXBjb3JlLWNoYWlyc0BpZXRmLm9yZzsgYnJAYnJpYW5yb3Nlbi5uZXQ7DQo+ IHNpcGNvcmVAaWV0Zi5vcmcNCj4gQmV0cmVmZjogQWRhbSBSb2FjaCdzIERpc2N1c3Mgb24gZHJh ZnQtaWV0Zi1zaXBjb3JlLXJlYXNvbi1xODUwLWxvYy0wNjoNCj4gKHdpdGggRElTQ1VTUyBhbmQg Q09NTUVOVCkNCj4gDQo+IEFkYW0gUm9hY2ggaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxs b3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtc2lwY29yZS1yZWFzb24tcTg1MC1sb2MtMDY6 IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3Qg bGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbA0KPiBhZGRyZXNzZXMgaW5jbHVkZWQg aW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3Rv cnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+ IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3Np dGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBw b3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXNpcGNvcmUtcmVhc29uLXE4NTAtbG9jLw0KPiANCj4gDQo+IA0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFRoYW5r cyBmb3IgdGFraW5nIG9uIHRoZSB0YXNrIG9mIGFkZGluZyB0aGlzIHZhbHVlLiBJIGhhdmUgYSBo YW5kZnVsIG9mDQo+IGNvbW1lbnRzLCBvbmUgb2Ygd2hpY2ggcmVhbGx5IG5lZWRzIGNsYXJpZmlj YXRpb24gcHJpb3IgdG8gcHVibGljYXRpb24uDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g DQo+IFRoaXMgaXNzdWUgaXMgYSBkaXNjdXNzIGJlY2F1c2UgdGhlIGxhY2sgb2YgZm9ybWFsIGxh bmd1YWdlIGZvciB2YWx1ZXMgYW5kIHRoZQ0KPiBsYWNrIG9mIGNsYXJpdHkgYXJvdW5kIGNhc2Ug c2Vuc2l0aXZpdHkgaGFzIGludGVyb3BlcmFiaWx0eSBpbXBsaWNhdGlvbnMuDQo+IA0KPiDCpzQ6 DQo+IA0KPiA+ICBUaGUgQXVnbWVudGVkDQo+ID4gIEJORiAoQUJORikgW1JGQzUyMzRdIGZvciB0 aGlzIHBhcmFtZXRlciBpcyBzaG93biBpbiBGaWd1cmUgMS4NCj4gDQo+IEZpZ3VyZSAxIGlzIG5v dCB2YWxpZCBBQk5GLiBJdCBjb250YWlucyBBQk5GLCBhbmQgdGhlbiBoYXMgYSB3aG9sZSBidW5j aCBvZg0KPiBvdGhlciBzdHVmZi4gSSBzdXNwZWN0IHlvdSB3YW50ZWQgdG8gaGF2ZSBzb21ldGhp bmcgbW9yZSBsaWtlIHRoaXMsIHVzaW5nIFJGQw0KPiA3NDA1IGV4dGVuc2lvbnM6DQo+IA0KPiAg ICByZWFzb24tZXh0ZW5zaW9uID0vIGlzdXAtY2F1c2UtbG9jYXRpb24NCj4gDQo+ICAgIGlzdXAt Y2F1c2UtbG9jYXRpb24gPSAgImxvY2F0aW9uIiBFUVVBTCBpc3VwLWxvY2F0aW9uLXZhbHVlDQo+ IA0KPiAgICBpc3VwLWxvY2F0aW9uLXZhbHVlID0NCj4gICAgICAgJXMiVSIgLyAgICAgIDsgZm9y IDAgMCAwIDAgdXNlcg0KPiAgICAgICAlcyJMUE4iIC8gICAgOyBmb3IgMCAwIDAgMSBwcml2YXRl IG5ldHdvcmsgc2VydmluZyB0aGUgbG9jYWwgdXNlcg0KPiAgICAgICAlcyJMTiIgLyAgICAgOyBm b3IgMCAwIDEgMCBwdWJsaWMgbmV0d29yayBzZXJ2aW5nIHRoZSBsb2NhbCB1c2VyDQo+ICAgICAg ICVzIlROIiAvICAgICA7IGZvciAwIDAgMSAxIHRyYW5zaXQgbmV0d29yaw0KPiAgICAgICAlcyJS TE4iIC8gICAgOyBmb3IgMCAxIDAgMCBwdWJsaWMgbmV0d29yayBzZXJ2aW5nIHRoZSByZW1vdGUg dXNlcg0KPiAgICAgICAlcyJSUE4iIC8gICAgOyBmb3IgMCAxIDAgMSBwcml2YXRlIG5ldHdvcmsg c2VydmluZyB0aGUgcmVtb3RlIHVzZXINCj4gICAgICAgJXMiTE9DLTYiIC8gIDsgZm9yIDAgMSAx IDAgc3BhcmUNCj4gICAgICAgJXMiSU5UTCIgLyAgIDsgZm9yIDAgMSAxIDEgaW50ZXJuYXRpb25h bCBuZXR3b3JrDQo+ICAgICAgICVzIkxPQy04IiAvICA7IGZvciAxIDAgMCAwIHNwYXJlDQo+ICAg ICAgICVzIkxPQy05IiAvICA7IGZvciAxIDAgMCAxIHNwYXJlDQo+ICAgICAgICVzIkJJIiAvICAg ICA7IGZvciAxIDAgMSAwIG5ldHdvcmsgYmV5b25kIGludGVyd29ya2luZyBwb2ludA0KPiAgICAg ICAlcyJMT0MtMTEiIC8gOyBmb3IgMSAwIDEgMSBzcGFyZQ0KPiAgICAgICAlcyJMT0MtMTIiIC8g OyBmb3IgMSAxIDAgMCByZXNlcnZlZCBmb3IgbmF0aW9uYWwgdXNlDQo+ICAgICAgICVzIkxPQy0x MyIgLyA7IGZvciAxIDEgMCAxIHJlc2VydmVkIGZvciBuYXRpb25hbCB1c2UNCj4gICAgICAgJXMi TE9DLTE0IiAvIDsgZm9yIDEgMSAxIDAgcmVzZXJ2ZWQgZm9yIG5hdGlvbmFsIHVzZQ0KPiAgICAg ICAlcyJMT0MtMTUiICAgOyBmb3IgMSAxIDEgMSByZXNlcnZlZCBmb3IgbmF0aW9uYWwgdXNlDQo+ IA0KPiBJZiB5b3UgY2hvb3NlIHRvIGluc3RlYWQga2VlcCB0aGUgY3VycmVudCBmb3JtdWxhdGlv biwgcGxlYXNlOg0KPiANCj4gIC0gTW92ZSB0aGUgbGlzdCBvZiB2YWxpZCB2YWx1ZXMgb3V0IG9m IHRoZSBmaWd1cmUsIGFuZA0KPiAgLSBBZGQgdGV4dCBjbGFyaWZ5aW5nIHdoZXRoZXIgdGhlIHZh bHVlcyBhcmUgY2FzZS1zZW5zaXRpdmUuDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01N RU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBJRCBOaXRzIHJlcG9ydHM6DQo+IA0KPiAgID09 IFVudXNlZCBSZWZlcmVuY2U6ICdSRkMzMjYxJyBpcyBkZWZpbmVkIG9uIGxpbmUgMjQ1LCBidXQg bm8gZXhwbGljaXQNCj4gICAgICByZWZlcmVuY2Ugd2FzIGZvdW5kIGluIHRoZSB0ZXh0DQo+IA0K PiAgID09IFVudXNlZCBSZWZlcmVuY2U6ICdSRkMzMzIzJyBpcyBkZWZpbmVkIG9uIGxpbmUgMjUx LCBidXQgbm8gZXhwbGljaXQNCj4gICAgICByZWZlcmVuY2Ugd2FzIGZvdW5kIGluIHRoZSB0ZXh0 DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IMKnMToNCj4gDQo+ID4gIFtSRkMzMzI2 XSBzcGVjaWZpZXMgdGhhdCBhIElTVVAgW1EuODUwXSAgY2F1c2UgY29kZSBjYW4gYmUgY2Fycmll ZA0KPiA+IHdpdGhpbiBhIFNJUCByZXNwb25zZQ0KPiANCj4gVGhpcyBpc24ndCBxdWl0ZSByaWdo dCAtLSBpbnRlcnByZXRlZCBjYXJlZnVsbHksIFJGQyAzMzI2IHNwZWNpZmljYWxseSBkb2VzDQo+ ICpub3QqIGFsbG93IHRoaXM6IGl0IGVudmlzaW9ucyBzcGVjaWZpYyBmdXR1cmUgcmVzcG9uc2Ug Y29kZXMgKGluIHRoZW9yeSB1c2VkDQo+IHRvIGhlbHAgd2l0aCBIRVJGUCkgdGhhdCBvcHQtaW4g dG8gYWxsb3dpbmcgdGhlIFJlYXNvbiBoZWFkZXIgZmllbGQuICBXaGVuDQo+IHNwZWFraW5nIG9m IHRoZSBnZW5lcmFsIHVzZSBjYXNlIG9mIHNlbmRpbmcgUS44NTAgY29kZXMgaW4gYXJiaXRyYXJ5 IFNJUA0KPiByZXNwb25zZSBtZXNzYWdlcywgeW91IG5lZWQgdG8gY2l0ZSBSRkMgNjQzMiBpbnN0 ZWFkIG9mIFJGQyAzMzI2Lg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiDCpzQ6DQo+ IA0KPiA+ICBBcyBkZWZpbmVkIGJ5IFtSRkMzMzI2XSBhIFJlYXNvbiBoZWFkZXIgZmllbGQgTUFZ IGFwcGVhciBpbiBhbnkNCj4gPiByZXF1ZXN0IGluIGEgZGlhbG9nLCBpbiBhbnkgQ0FOQ0VMIHJl cXVlc3QgYW5kIGluIGFueSByZXNwb25zZSB3aG9zZQ0KPiA+IHN0YXR1cyBjb2RlIGV4cGxpY2l0 bHkgYWxsb3dzIHRoZSBwcmVzZW5jZSBvZiB0aGlzIGhlYWRlciBmaWVsZC4NCj4gDQo+IEFzIGFi b3ZlLCBJIHRoaW5rIHdlJ3JlIHRhbGtpbmcgYWJvdXQgdGhlIG1vcmUgZ2VuZXJhbCBjYXNlIChy YXRoZXIgdGhhbiB0aGUNCj4gImV4cGxpY2l0bHkgYWxsb3dzIiBjYXNlKTsgaWYgc28sIHRoaXMg dGV4dCBzaG91bGQgY2l0ZSBSRkMgNjQzMiBhbmQgY2xhcmlmeSB0aGF0DQo+ICJBbnkgU0lQIFJl c3BvbnNlIG1lc3NhZ2UsIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiBhIDEwMCAoVHJ5aW5nKSwgTUFZ DQo+IGNvbnRhaW4gYSBSZWFzb24gaGVhZGVyIGZpZWxkIHdpdGggYSBRLjg1MCBbUS44NTBdIGNh dXNlIGNvZGUuIg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiDCpzU6DQo+IA0KPiA+ ICAgICAgICBTSVAvMi4wIDQwNCBOb3QgRm91bmQNCj4gPg0KPiA+ICAgICAgICBGcm9tOiBBbGlj ZSA8c2lwczphbGljZUBhdGxhbnRhLmV4YW1wbGUuY29tPjt0YWc9MTIzNDU2Nw0KPiANCj4gUGxl YXNlIHJlbW92ZSB0aGUgYmxhbmsgbGluZSBiZXR3ZWVuIHRoZSByZXNwb25zZSBsaW5lIGFuZCB0 aGUgZmlyc3QgaGVhZGVyDQo+IGZpZWxkLg0KPiANCj4gUGxlYXNlIGFkZCBhdCBsZWFzdCBvbmUg IlZpYSIgaGVhZGVyIGZpZWxkLCBvciBhZGQgdGV4dCBpbmRpY2F0aW5nIHRoYXQgVmlhDQo+IGhl YWRlciBmaWVsZHMgaGF2ZSBiZWVuIHJlbW92ZWQgZm9yIGNvbmNpc2lvbi4NCj4gDQoNCg== From nobody Tue Mar 12 22:51:31 2019 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 B978E130E86; Tue, 12 Mar 2019 22:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 lTbJjA3sc43R; Tue, 12 Mar 2019 22:51:21 -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 D858312F1A6; Tue, 12 Mar 2019 22:51:21 -0700 (PDT) Received: from MacBook-Pro.roach.at (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 x2D5pHFK011407 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 Mar 2019 00:51:18 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1552456280; bh=zvkDzx1IMIC6kGXBS8fem5C8Nhuo4cFzomO5BRWw5wY=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Se2L5+l0fm2Y5aynIwawZfvodWJIG6pfrdt+mKLaMk0W6nRXmH5UOhJJ88VOP2lnQ 2aM2e2jHye9+wIV5lSK/S9ZBvs5mfRQyaZ1jYBbyh6Q++SiF/5S3SvInixJxie6SH0 rFiPuixDqE1O8LCjyvt+6ZIUgoQaWbU+yYDj1OyU= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: R.Jesske@telekom.de, iesg@ietf.org Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org, br@brianrosen.net, sipcore-chairs@ietf.org, sipcore@ietf.org References: <155176292818.5224.17119790703710957363.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Wed, 13 Mar 2019 00:51:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [sipcore] Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 05:51:24 -0000 Thanks. These resolutions look good to me; please upload a new version at your convenience. /a On 3/11/19 3:23 AM, R.Jesske@telekom.de wrote: > Hi, > Thank you for your comments. I went through the comments and here are my answers and proposals to the comments made. > Sorry If some of you get the mail twice, since I answered in another way already. > > 1. Discuss: > §4 ABNF > Have incorporated the proposal. > > 1. Comments: > I have incorporated all proposed changes. > §1 done: > Text reads now: > RFC6432 specifies that a ISUP Q.850 cause code can be carried within a SIP response, but not the Q.850 location information. > > §4 > So text reads now: > As defined by RFC6432 any SIP Response message, with the exception of a 100 (Trying), MAY contain a Reason header field with a Q.850 [Q.850] cause code. > > §5 > Done as proposed. > Removed blank line and added two via header. > > > If you are OK with these changes I will produce a new draft and upload it. > > Thank you and Best Regards > > Roland > >> -----Ursprüngliche Nachricht----- >> Von: Adam Roach >> Gesendet: Dienstag, 5. März 2019 06:15 >> An: The IESG >> Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org; Brian Rosen >> ; sipcore-chairs@ietf.org; br@brianrosen.net; >> sipcore@ietf.org >> Betreff: Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06: >> (with DISCUSS and COMMENT) >> >> Adam Roach has entered the following ballot position for >> draft-ietf-sipcore-reason-q850-loc-06: 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-reason-q850-loc/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Thanks for taking on the task of adding this value. I have a handful of >> comments, one of which really needs clarification prior to publication. >> >> --------------------------------------------------------------------------- >> >> This issue is a discuss because the lack of formal language for values and the >> lack of clarity around case sensitivity has interoperabilty implications. >> >> §4: >> >>> The Augmented >>> BNF (ABNF) [RFC5234] for this parameter is shown in Figure 1. >> Figure 1 is not valid ABNF. It contains ABNF, and then has a whole bunch of >> other stuff. I suspect you wanted to have something more like this, using RFC >> 7405 extensions: >> >> reason-extension =/ isup-cause-location >> >> isup-cause-location = "location" EQUAL isup-location-value >> >> isup-location-value = >> %s"U" / ; for 0 0 0 0 user >> %s"LPN" / ; for 0 0 0 1 private network serving the local user >> %s"LN" / ; for 0 0 1 0 public network serving the local user >> %s"TN" / ; for 0 0 1 1 transit network >> %s"RLN" / ; for 0 1 0 0 public network serving the remote user >> %s"RPN" / ; for 0 1 0 1 private network serving the remote user >> %s"LOC-6" / ; for 0 1 1 0 spare >> %s"INTL" / ; for 0 1 1 1 international network >> %s"LOC-8" / ; for 1 0 0 0 spare >> %s"LOC-9" / ; for 1 0 0 1 spare >> %s"BI" / ; for 1 0 1 0 network beyond interworking point >> %s"LOC-11" / ; for 1 0 1 1 spare >> %s"LOC-12" / ; for 1 1 0 0 reserved for national use >> %s"LOC-13" / ; for 1 1 0 1 reserved for national use >> %s"LOC-14" / ; for 1 1 1 0 reserved for national use >> %s"LOC-15" ; for 1 1 1 1 reserved for national use >> >> If you choose to instead keep the current formulation, please: >> >> - Move the list of valid values out of the figure, and >> - Add text clarifying whether the values are case-sensitive. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> ID Nits reports: >> >> == Unused Reference: 'RFC3261' is defined on line 245, but no explicit >> reference was found in the text >> >> == Unused Reference: 'RFC3323' is defined on line 251, but no explicit >> reference was found in the text >> >> --------------------------------------------------------------------------- >> >> §1: >> >>> [RFC3326] specifies that a ISUP [Q.850] cause code can be carried >>> within a SIP response >> This isn't quite right -- interpreted carefully, RFC 3326 specifically does >> *not* allow this: it envisions specific future response codes (in theory used >> to help with HERFP) that opt-in to allowing the Reason header field. When >> speaking of the general use case of sending Q.850 codes in arbitrary SIP >> response messages, you need to cite RFC 6432 instead of RFC 3326. >> >> --------------------------------------------------------------------------- >> >> §4: >> >>> As defined by [RFC3326] a Reason header field MAY appear in any >>> request in a dialog, in any CANCEL request and in any response whose >>> status code explicitly allows the presence of this header field. >> As above, I think we're talking about the more general case (rather than the >> "explicitly allows" case); if so, this text should cite RFC 6432 and clarify that >> "Any SIP Response message, with the exception of a 100 (Trying), MAY >> contain a Reason header field with a Q.850 [Q.850] cause code." >> >> --------------------------------------------------------------------------- >> >> §5: >> >>> SIP/2.0 404 Not Found >>> >>> From: Alice ;tag=1234567 >> Please remove the blank line between the response line and the first header >> field. >> >> Please add at least one "Via" header field, or add text indicating that Via >> header fields have been removed for concision. >> From nobody Thu Mar 14 00:24:53 2019 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 3FA6D1200D7; Thu, 14 Mar 2019 00:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWoUWVqKKrJb; Thu, 14 Mar 2019 00:24:48 -0700 (PDT) Received: from mailout31.telekom.de (MAILOUT31.telekom.de [194.25.225.143]) (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 BBF3E12008F; Thu, 14 Mar 2019 00:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1552548287; x=1584084287; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fdZ7cuvQOs2yzhy7ktcgg/VrY44PPtqsX1pNqUpl9CA=; b=OjwuNRCfk8ez8fXPzwPxnZCSo6foPmPCV9g9RYuTXBoAOCnow4EBQKYP 0MK4pVCcDxuPyfVvPw+PvTQYcbJSA1ZVo9tB2d0S8cx+XlloeKXTmJ7cP rRdqdTFYnyXSjpNgV4NaJWJ2E7xqkVTBo1sWOhtQj0avidcRXDhKD+B/D RIba7Yb3P35k4D+3VdHWCDwpEXoz1JCgc2s1avS6qGN9NH6W6EXj0JDMu 5nDj8GI4yNmrg63FGDAsTBbXGQAFIOsoXOriOk8kilgQWpeVdseE6xUcw 0yQwsCM2+F0yu2fRZtgLCmQBYzsVkqBhpCn5fKd9w5a7wZKHargWv62QB Q==; Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2019 08:24:43 +0100 X-IronPort-AV: E=Sophos;i="5.58,477,1544482800"; d="scan'208";a="245444460" Received: from he105701.emea1.cds.t-internal.com ([10.169.119.22]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/AES256-SHA; 14 Mar 2019 08:24:42 +0100 Received: from HE105651.EMEA1.cds.t-internal.com (10.169.119.62) by HE105701.emea1.cds.t-internal.com (10.169.119.22) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 14 Mar 2019 08:24:42 +0100 Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE105651.EMEA1.cds.t-internal.com (10.169.119.62) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 14 Mar 2019 08:24:42 +0100 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.17) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 14 Mar 2019 08:24:43 +0100 Received: from FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE (10.158.150.149) by FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE (10.158.150.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.20; Thu, 14 Mar 2019 07:24:41 +0000 Received: from FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE ([fe80::1dd6:9036:77f4:3bdb]) by FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE ([fe80::1dd6:9036:77f4:3bdb%6]) with mapi id 15.20.1686.021; Thu, 14 Mar 2019 07:24:41 +0000 From: To: , CC: , , , Thread-Topic: AW: Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) Thread-Index: AQHU0xJ/37mALULf3kix2lQq0GEU+KYGIJIggAL6zoCAACizAA== Date: Thu, 14 Mar 2019 07:24:41 +0000 Message-ID: References: <155176292818.5224.17119790703710957363.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.214] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f735afed-0685-4f95-60ca-08d6a84e1fe1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:FRXPR01MB0135; x-ms-traffictypediagnostic: FRXPR01MB0135: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(396003)(366004)(136003)(189003)(199004)(2906002)(14444005)(256004)(105586002)(446003)(11346002)(305945005)(97736004)(7736002)(68736007)(106356001)(33656002)(561944003)(66574012)(3846002)(476003)(71190400001)(486006)(71200400001)(6116002)(76176011)(54906003)(53546011)(110136005)(81166006)(81156014)(7696005)(2501003)(8676002)(316002)(52396003)(75402003)(26005)(102836004)(186003)(74482002)(86362001)(14454004)(478600001)(966005)(72206003)(5660300002)(8936002)(53936002)(9686003)(66066001)(6306002)(4326008)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:FRXPR01MB0135; H:FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-exchange-diagnostics: =?utf-8?B?MTtGUlhQUjAxTUIwMTM1OzIzOlhtVjJmU0xqclNwUkZXbnpGamNvVU9BWjZ2?= =?utf-8?B?ZTNQUXNPL25ncEh0aE5NbUFhbFUzM1pueGJLTThTSWF6OXFjam9jZUFZdmxH?= =?utf-8?B?NUcyWCt5alNjdW10UHhtM281NHA5UjNxaFVvT0tRMEw4ejYvbXdoRENUVnNq?= =?utf-8?B?UUFyRmE5NnMyMUdrdXZ3QVNDc0NiWGdKOTVGaG1NQ3Y1dVJiZGVpalB0VjFM?= =?utf-8?B?ZGNlY1RrQ2FjVXdMVEZhaWlBR2VXbjkzNGMrNEcrMEdjdDVCN3YrQytKaHhO?= =?utf-8?B?MDROdmFpTER5UmhkbUNic2czMGdTSGExcUpwR1gwc1V3cGZoWFYvRzgzRFdD?= =?utf-8?B?blpDcEhCVkMyTWdrVGw0ZjdXUnUxL3VxY2J4a0pmUE1jdzBZTG90TkdsdXlM?= =?utf-8?B?YVlFejEyT2lRWTBodFU2YXJiVmVpUGZnMFBxM3RjN3ZYV2hNYmxycU1jemRz?= =?utf-8?B?eE5HQkpudHRnRlY3eXJqOTF6a0k2U0w4enBabStSaDVuVjd0STNacnFkNWRY?= =?utf-8?B?UVN4aWVlTCthWTRQbDY4UXI4Q0JuS1BYSExIMkZRYUxpeVVSOE1WSGwyQXR6?= =?utf-8?B?Nm5XbSt4YXg0UFV5Tko5ZVk2cEhlTCsxaVZERkZ4QTI2cCs0VksxOEVVRWRl?= =?utf-8?B?cGxRajVPOXZyb0JDem16Q1lDZjB3R1RYTDJwdkF6aUowTG9IbkwvdktKSFJZ?= =?utf-8?B?QVJXL1RNeEx5K0YwTnJsNEpyN1E4TngzWkRIa3V4TmMxR211WHlnQVp4Q0xM?= =?utf-8?B?elV3Q09GRmlvaXhocUNOZ1VnNVltenZENTdRNGg5bU1mQU16SG9NRFhLaGlT?= =?utf-8?B?ME1KbVVZYVhsNHREamNkUkNnbklLc25yNWlEbzFnVVZKT0tCS0Y0QThFaGhk?= =?utf-8?B?MmdjZXBQNEhrZy9wN3I3bjVsRDh2Vk5nOWpVYlNIZk82WDRSSXVUQjVvMzFK?= =?utf-8?B?U0pKQlE3ZWpZc1c2bHVaQ1hDbkNsQ3ZxSGhkNTJENS9tOVU3Qk4vVkF2MWFZ?= =?utf-8?B?MW45emNQR0tjTHdUUzFjazg5akpKc2F4a1lIUWgyeTJXL2RkdGtobUN4dHFL?= =?utf-8?B?Q3dUZC9sTDl3Q3RKcW5GK3lGb28vbDNUdlJZWEFoTDVOUFlyVjNQWDZSR0Y2?= =?utf-8?B?REhQSjFra1ljZFhoT1pjeGlOekZkcHZid3dvZDhPdWVBVWppYjNrendsYy9R?= =?utf-8?B?dGZDb1NvU1hRd3F5d1UxWkc1Z2Z0eDBmR29saFlhVHp2K2gxcHNEOWNldDhN?= =?utf-8?B?Z3RVVGNXUUNoVFhrWmJuaVRzN1hHZnZQeGpyUGo4V0p1b1J5dmI4cFFxeE1C?= =?utf-8?B?dlVTNVdGMFE5UGpBdC9ETTIzZGsydGtObmdaa3BtUTB1ejhKVjR3dVFYQnZ4?= =?utf-8?B?U2lXK2RGNzBmQ1JlbTkzZ3hvSDhURk56a2pIRGFyN1NXUXFTZ3E2dGdqTzdx?= =?utf-8?B?b0FTOHJuMDhWNXIyYldIcGpCb0oyR2doaHU3azUrdjh4d25OOUpEQzdzN3ov?= =?utf-8?B?TTdFSGs3Nk9FR2hCMTUxSGxOOElnZnF6Tmp6dkxTUU43cWF3N3hNK1d6eVdV?= =?utf-8?B?UU5nS1FER3R6NVNsT0dnT0wybUh3SjhSNEJ2eWh0c01tbTZPeVNYbW84cytZ?= =?utf-8?B?SkRSMVl1OHFsRmZrRk16cGVHZkFld1FkYVRtU0dGRm5FZklnVTNUWTZlQnJi?= =?utf-8?Q?lOsvUEanHfuOc/DaUMD5FiXOVZQ7ljtecttoiw7?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: tps5s1HvA9QvJwjodXA8Hp3/9FtxUWGSx6uN59X7Nu9rN7lNolw+OJGQoP2NASeKXnVOoU92iYBZrwrp96qeVRY8cOsxTTnFalFuJ1n8JN976TCo+D6IZg30VN65C0QR8Y/NCBeKzTl4poAlKc1fGux0l8+lvU5d0PZ8iXW15b+QhldmIAHNJjdYtSi0tE3muULDGKjGyMTgqL1GY5JKjB05GUv3oBjwXcxMBdUT8W+2VQpnw0oDWReEmC1PssFvxKbIsvw4Ml/rCNjErTff7hcbUetJbuwRG2aKizapnrZGnJak1SDaeap3njpmQYOaUH9T4ceUbkU91QYOhg3/EPS5BFKjm3MEBx7QC/dy+QqT2HAky5VPKpBpNX1ahnzHDlWyJozDrtbyuuySR6VvVUEWSukKRl/bUtj/hBK7gkM= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f735afed-0685-4f95-60ca-08d6a84e1fe1 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2019 07:24:41.4873 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRXPR01MB0135 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 07:24:51 -0000 VGhhbmsgeW91IEFkYW0gZm9yIHlvdXIgQW5zd2VyLg0KSSB3aWxsIHVwbG9hZCB0aGUgZHJhZnQg YXMgc29vbiBhcyB0aGUgdXBsb2FkIHBhZ2Ugb3BlbnMgYWdhaW4uIGkuZS4gMjMuMDMuDQpPciBp cyB0aGVyZSBhbnkgcG9zc2liaWxpdHkgdG8gZG8gaXQgbm93Pw0KDQpUaGFuayB5b3UgYW5kIEJl c3QgUmVnYXJkcw0KDQpSb2xhbmQNCg0KPiAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0t LS0tDQo+IFZvbjogQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbT4NCj4gR2VzZW5kZXQ6IE1p dHR3b2NoLCAxMy4gTcOkcnogMjAxOSAwNjo1MQ0KPiBBbjogSmVzc2tlLCBSb2xhbmQgPFIuSmVz c2tlQHRlbGVrb20uZGU+OyBpZXNnQGlldGYub3JnDQo+IENjOiBkcmFmdC1pZXRmLXNpcGNvcmUt cmVhc29uLXE4NTAtbG9jQGlldGYub3JnOyBickBicmlhbnJvc2VuLm5ldDsNCj4gc2lwY29yZS1j aGFpcnNAaWV0Zi5vcmc7IHNpcGNvcmVAaWV0Zi5vcmcNCj4gQmV0cmVmZjogUmU6IEFXOiBBZGFt IFJvYWNoJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXNpcGNvcmUtcmVhc29uLXE4NTAtDQo+IGxv Yy0wNjogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IFRoYW5rcy4gVGhlc2UgcmVz b2x1dGlvbnMgbG9vayBnb29kIHRvIG1lOyBwbGVhc2UgdXBsb2FkIGEgbmV3IHZlcnNpb24gYXQN Cj4geW91ciBjb252ZW5pZW5jZS4NCj4gDQo+IC9hDQo+IA0KPiBPbiAzLzExLzE5IDM6MjMgQU0s IFIuSmVzc2tlQHRlbGVrb20uZGUgd3JvdGU6DQo+ID4gSGksDQo+ID4gVGhhbmsgeW91IGZvciB5 b3VyIGNvbW1lbnRzLiBJIHdlbnQgdGhyb3VnaCB0aGUgY29tbWVudHMgYW5kIGhlcmUgYXJlDQo+ IG15IGFuc3dlcnMgYW5kIHByb3Bvc2FscyB0byB0aGUgY29tbWVudHMgbWFkZS4NCj4gPiBTb3Jy eSBJZiBzb21lIG9mIHlvdSBnZXQgdGhlIG1haWwgdHdpY2UsIHNpbmNlIEkgYW5zd2VyZWQgaW4g YW5vdGhlciB3YXkNCj4gYWxyZWFkeS4NCj4gPg0KPiA+IDEuICBEaXNjdXNzOg0KPiA+IMKnNCBB Qk5GDQo+ID4gSGF2ZSBpbmNvcnBvcmF0ZWQgdGhlIHByb3Bvc2FsLg0KPiA+DQo+ID4gMS4gIENv bW1lbnRzOg0KPiA+IEkgaGF2ZSBpbmNvcnBvcmF0ZWQgYWxsIHByb3Bvc2VkIGNoYW5nZXMuDQo+ ID4gwqcxIGRvbmU6DQo+ID4gVGV4dCByZWFkcyBub3c6DQo+ID4gUkZDNjQzMiBzcGVjaWZpZXMg dGhhdCBhIElTVVAgUS44NTAgY2F1c2UgY29kZSBjYW4gYmUgY2FycmllZCB3aXRoaW4gYSBTSVAN Cj4gcmVzcG9uc2UsIGJ1dCBub3QgdGhlIFEuODUwIGxvY2F0aW9uIGluZm9ybWF0aW9uLg0KPiA+ DQo+ID4gwqc0DQo+ID4gU28gdGV4dCByZWFkcyBub3c6DQo+ID4gQXMgZGVmaW5lZCBieSBSRkM2 NDMyIGFueSBTSVAgUmVzcG9uc2UgbWVzc2FnZSwgd2l0aCB0aGUgZXhjZXB0aW9uIG9mIGENCj4g MTAwIChUcnlpbmcpLCBNQVkgY29udGFpbiBhIFJlYXNvbiBoZWFkZXIgZmllbGQgd2l0aCBhIFEu ODUwIFtRLjg1MF0gY2F1c2UNCj4gY29kZS4NCj4gPg0KPiA+IMKnNQ0KPiA+IERvbmUgYXMgcHJv cG9zZWQuDQo+ID4gUmVtb3ZlZCBibGFuayBsaW5lIGFuZCBhZGRlZCB0d28gdmlhIGhlYWRlci4N Cj4gPg0KPiA+DQo+ID4gSWYgeW91IGFyZSBPSyB3aXRoIHRoZXNlIGNoYW5nZXMgSSB3aWxsIHBy b2R1Y2UgYSBuZXcgZHJhZnQgYW5kIHVwbG9hZCBpdC4NCj4gPg0KPiA+IFRoYW5rIHlvdSBhbmQg QmVzdCBSZWdhcmRzDQo+ID4NCj4gPiBSb2xhbmQNCj4gPg0KPiA+PiAtLS0tLVVyc3Byw7xuZ2xp Y2hlIE5hY2hyaWNodC0tLS0tDQo+ID4+IFZvbjogQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNv bT4NCj4gPj4gR2VzZW5kZXQ6IERpZW5zdGFnLCA1LiBNw6RyeiAyMDE5IDA2OjE1DQo+ID4+IEFu OiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gPj4gQ2M6IGRyYWZ0LWlldGYtc2lwY29yZS1y ZWFzb24tcTg1MC1sb2NAaWV0Zi5vcmc7IEJyaWFuIFJvc2VuDQo+ID4+IDxickBicmlhbnJvc2Vu Lm5ldD47IHNpcGNvcmUtY2hhaXJzQGlldGYub3JnOyBickBicmlhbnJvc2VuLm5ldDsNCj4gPj4g c2lwY29yZUBpZXRmLm9yZw0KPiA+PiBCZXRyZWZmOiBBZGFtIFJvYWNoJ3MgRGlzY3VzcyBvbiBk cmFmdC1pZXRmLXNpcGNvcmUtcmVhc29uLXE4NTAtbG9jLTA2Og0KPiA+PiAod2l0aCBESVNDVVNT IGFuZCBDT01NRU5UKQ0KPiA+Pg0KPiA+PiBBZGFtIFJvYWNoIGhhcyBlbnRlcmVkIHRoZSBmb2xs b3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiA+PiBkcmFmdC1pZXRmLXNpcGNvcmUtcmVhc29u LXE4NTAtbG9jLTA2OiBEaXNjdXNzDQo+ID4+DQo+ID4+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNl IGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiA+PiBlbWFp bCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0 byBjdXQNCj4gPj4gdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gPj4N Cj4gPj4NCj4gPj4gUGxlYXNlIHJlZmVyIHRvDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ll c2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiA+PiBmb3IgbW9yZSBpbmZvcm1h dGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiA+Pg0KPiA+ Pg0KPiA+PiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywg Y2FuIGJlIGZvdW5kIGhlcmU6DQo+ID4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtc2lwY29yZS1yZWFzb24tcTg1MC1sb2MvDQo+ID4+DQo+ID4+DQo+ID4+DQo+ ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiAtDQo+ID4+IERJU0NVU1M6DQo+ID4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+PiAtDQo+ID4+DQo+ID4+IFRoYW5rcyBmb3IgdGFraW5nIG9uIHRoZSB0YXNrIG9mIGFk ZGluZyB0aGlzIHZhbHVlLiBJIGhhdmUgYSBoYW5kZnVsDQo+ID4+IG9mIGNvbW1lbnRzLCBvbmUg b2Ygd2hpY2ggcmVhbGx5IG5lZWRzIGNsYXJpZmljYXRpb24gcHJpb3IgdG8gcHVibGljYXRpb24u DQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiAtLS0tLS0NCj4gPj4NCj4gPj4gVGhpcyBp c3N1ZSBpcyBhIGRpc2N1c3MgYmVjYXVzZSB0aGUgbGFjayBvZiBmb3JtYWwgbGFuZ3VhZ2UgZm9y DQo+ID4+IHZhbHVlcyBhbmQgdGhlIGxhY2sgb2YgY2xhcml0eSBhcm91bmQgY2FzZSBzZW5zaXRp dml0eSBoYXMgaW50ZXJvcGVyYWJpbHR5DQo+IGltcGxpY2F0aW9ucy4NCj4gPj4NCj4gPj4gwqc0 Og0KPiA+Pg0KPiA+Pj4gICBUaGUgQXVnbWVudGVkDQo+ID4+PiAgIEJORiAoQUJORikgW1JGQzUy MzRdIGZvciB0aGlzIHBhcmFtZXRlciBpcyBzaG93biBpbiBGaWd1cmUgMS4NCj4gPj4gRmlndXJl IDEgaXMgbm90IHZhbGlkIEFCTkYuIEl0IGNvbnRhaW5zIEFCTkYsIGFuZCB0aGVuIGhhcyBhIHdo b2xlDQo+ID4+IGJ1bmNoIG9mIG90aGVyIHN0dWZmLiBJIHN1c3BlY3QgeW91IHdhbnRlZCB0byBo YXZlIHNvbWV0aGluZyBtb3JlDQo+ID4+IGxpa2UgdGhpcywgdXNpbmcgUkZDDQo+ID4+IDc0MDUg ZXh0ZW5zaW9uczoNCj4gPj4NCj4gPj4gICAgIHJlYXNvbi1leHRlbnNpb24gPS8gaXN1cC1jYXVz ZS1sb2NhdGlvbg0KPiA+Pg0KPiA+PiAgICAgaXN1cC1jYXVzZS1sb2NhdGlvbiA9ICAibG9jYXRp b24iIEVRVUFMIGlzdXAtbG9jYXRpb24tdmFsdWUNCj4gPj4NCj4gPj4gICAgIGlzdXAtbG9jYXRp b24tdmFsdWUgPQ0KPiA+PiAgICAgICAgJXMiVSIgLyAgICAgIDsgZm9yIDAgMCAwIDAgdXNlcg0K PiA+PiAgICAgICAgJXMiTFBOIiAvICAgIDsgZm9yIDAgMCAwIDEgcHJpdmF0ZSBuZXR3b3JrIHNl cnZpbmcgdGhlIGxvY2FsIHVzZXINCj4gPj4gICAgICAgICVzIkxOIiAvICAgICA7IGZvciAwIDAg MSAwIHB1YmxpYyBuZXR3b3JrIHNlcnZpbmcgdGhlIGxvY2FsIHVzZXINCj4gPj4gICAgICAgICVz IlROIiAvICAgICA7IGZvciAwIDAgMSAxIHRyYW5zaXQgbmV0d29yaw0KPiA+PiAgICAgICAgJXMi UkxOIiAvICAgIDsgZm9yIDAgMSAwIDAgcHVibGljIG5ldHdvcmsgc2VydmluZyB0aGUgcmVtb3Rl IHVzZXINCj4gPj4gICAgICAgICVzIlJQTiIgLyAgICA7IGZvciAwIDEgMCAxIHByaXZhdGUgbmV0 d29yayBzZXJ2aW5nIHRoZSByZW1vdGUgdXNlcg0KPiA+PiAgICAgICAgJXMiTE9DLTYiIC8gIDsg Zm9yIDAgMSAxIDAgc3BhcmUNCj4gPj4gICAgICAgICVzIklOVEwiIC8gICA7IGZvciAwIDEgMSAx IGludGVybmF0aW9uYWwgbmV0d29yaw0KPiA+PiAgICAgICAgJXMiTE9DLTgiIC8gIDsgZm9yIDEg MCAwIDAgc3BhcmUNCj4gPj4gICAgICAgICVzIkxPQy05IiAvICA7IGZvciAxIDAgMCAxIHNwYXJl DQo+ID4+ICAgICAgICAlcyJCSSIgLyAgICAgOyBmb3IgMSAwIDEgMCBuZXR3b3JrIGJleW9uZCBp bnRlcndvcmtpbmcgcG9pbnQNCj4gPj4gICAgICAgICVzIkxPQy0xMSIgLyA7IGZvciAxIDAgMSAx IHNwYXJlDQo+ID4+ICAgICAgICAlcyJMT0MtMTIiIC8gOyBmb3IgMSAxIDAgMCByZXNlcnZlZCBm b3IgbmF0aW9uYWwgdXNlDQo+ID4+ICAgICAgICAlcyJMT0MtMTMiIC8gOyBmb3IgMSAxIDAgMSBy ZXNlcnZlZCBmb3IgbmF0aW9uYWwgdXNlDQo+ID4+ICAgICAgICAlcyJMT0MtMTQiIC8gOyBmb3Ig MSAxIDEgMCByZXNlcnZlZCBmb3IgbmF0aW9uYWwgdXNlDQo+ID4+ICAgICAgICAlcyJMT0MtMTUi ICAgOyBmb3IgMSAxIDEgMSByZXNlcnZlZCBmb3IgbmF0aW9uYWwgdXNlDQo+ID4+DQo+ID4+IElm IHlvdSBjaG9vc2UgdG8gaW5zdGVhZCBrZWVwIHRoZSBjdXJyZW50IGZvcm11bGF0aW9uLCBwbGVh c2U6DQo+ID4+DQo+ID4+ICAgLSBNb3ZlIHRoZSBsaXN0IG9mIHZhbGlkIHZhbHVlcyBvdXQgb2Yg dGhlIGZpZ3VyZSwgYW5kDQo+ID4+ICAgLSBBZGQgdGV4dCBjbGFyaWZ5aW5nIHdoZXRoZXIgdGhl IHZhbHVlcyBhcmUgY2FzZS1zZW5zaXRpdmUuDQo+ID4+DQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+PiAtDQo+ID4+IENPTU1FTlQ6DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiAtDQo+ID4+ DQo+ID4+IElEIE5pdHMgcmVwb3J0czoNCj4gPj4NCj4gPj4gICAgPT0gVW51c2VkIFJlZmVyZW5j ZTogJ1JGQzMyNjEnIGlzIGRlZmluZWQgb24gbGluZSAyNDUsIGJ1dCBubyBleHBsaWNpdA0KPiA+ PiAgICAgICByZWZlcmVuY2Ugd2FzIGZvdW5kIGluIHRoZSB0ZXh0DQo+ID4+DQo+ID4+ICAgID09 IFVudXNlZCBSZWZlcmVuY2U6ICdSRkMzMzIzJyBpcyBkZWZpbmVkIG9uIGxpbmUgMjUxLCBidXQg bm8gZXhwbGljaXQNCj4gPj4gICAgICAgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0aGUgdGV4dA0K PiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gLS0tLS0tDQo+ID4+DQo+ID4+IMKnMToNCj4g Pj4NCj4gPj4+ICAgW1JGQzMzMjZdIHNwZWNpZmllcyB0aGF0IGEgSVNVUCBbUS44NTBdICBjYXVz ZSBjb2RlIGNhbiBiZSBjYXJyaWVkDQo+ID4+PiB3aXRoaW4gYSBTSVAgcmVzcG9uc2UNCj4gPj4g VGhpcyBpc24ndCBxdWl0ZSByaWdodCAtLSBpbnRlcnByZXRlZCBjYXJlZnVsbHksIFJGQyAzMzI2 DQo+ID4+IHNwZWNpZmljYWxseSBkb2VzDQo+ID4+ICpub3QqIGFsbG93IHRoaXM6IGl0IGVudmlz aW9ucyBzcGVjaWZpYyBmdXR1cmUgcmVzcG9uc2UgY29kZXMgKGluDQo+ID4+IHRoZW9yeSB1c2Vk IHRvIGhlbHAgd2l0aCBIRVJGUCkgdGhhdCBvcHQtaW4gdG8gYWxsb3dpbmcgdGhlIFJlYXNvbg0K PiA+PiBoZWFkZXIgZmllbGQuICBXaGVuIHNwZWFraW5nIG9mIHRoZSBnZW5lcmFsIHVzZSBjYXNl IG9mIHNlbmRpbmcgUS44NTANCj4gPj4gY29kZXMgaW4gYXJiaXRyYXJ5IFNJUCByZXNwb25zZSBt ZXNzYWdlcywgeW91IG5lZWQgdG8gY2l0ZSBSRkMgNjQzMg0KPiBpbnN0ZWFkIG9mIFJGQyAzMzI2 Lg0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gLS0tLS0tDQo+ID4+DQo+ID4+IMKnNDoN Cj4gPj4NCj4gPj4+ICAgQXMgZGVmaW5lZCBieSBbUkZDMzMyNl0gYSBSZWFzb24gaGVhZGVyIGZp ZWxkIE1BWSBhcHBlYXIgaW4gYW55DQo+ID4+PiByZXF1ZXN0IGluIGEgZGlhbG9nLCBpbiBhbnkg Q0FOQ0VMIHJlcXVlc3QgYW5kIGluIGFueSByZXNwb25zZSB3aG9zZQ0KPiA+Pj4gc3RhdHVzIGNv ZGUgZXhwbGljaXRseSBhbGxvd3MgdGhlIHByZXNlbmNlIG9mIHRoaXMgaGVhZGVyIGZpZWxkLg0K PiA+PiBBcyBhYm92ZSwgSSB0aGluayB3ZSdyZSB0YWxraW5nIGFib3V0IHRoZSBtb3JlIGdlbmVy YWwgY2FzZSAocmF0aGVyDQo+ID4+IHRoYW4gdGhlICJleHBsaWNpdGx5IGFsbG93cyIgY2FzZSk7 IGlmIHNvLCB0aGlzIHRleHQgc2hvdWxkIGNpdGUgUkZDDQo+ID4+IDY0MzIgYW5kIGNsYXJpZnkg dGhhdCAiQW55IFNJUCBSZXNwb25zZSBtZXNzYWdlLCB3aXRoIHRoZSBleGNlcHRpb24NCj4gPj4g b2YgYSAxMDAgKFRyeWluZyksIE1BWSBjb250YWluIGEgUmVhc29uIGhlYWRlciBmaWVsZCB3aXRo IGEgUS44NTAgW1EuODUwXQ0KPiBjYXVzZSBjb2RlLiINCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ID4+IC0tLS0tLQ0KPiA+Pg0KPiA+PiDCpzU6DQo+ID4+DQo+ID4+PiAgICAgICAgIFNJUC8y LjAgNDA0IE5vdCBGb3VuZA0KPiA+Pj4NCj4gPj4+ICAgICAgICAgRnJvbTogQWxpY2UgPHNpcHM6 YWxpY2VAYXRsYW50YS5leGFtcGxlLmNvbT47dGFnPTEyMzQ1NjcNCj4gPj4gUGxlYXNlIHJlbW92 ZSB0aGUgYmxhbmsgbGluZSBiZXR3ZWVuIHRoZSByZXNwb25zZSBsaW5lIGFuZCB0aGUgZmlyc3QN Cj4gPj4gaGVhZGVyIGZpZWxkLg0KPiA+Pg0KPiA+PiBQbGVhc2UgYWRkIGF0IGxlYXN0IG9uZSAi VmlhIiBoZWFkZXIgZmllbGQsIG9yIGFkZCB0ZXh0IGluZGljYXRpbmcNCj4gPj4gdGhhdCBWaWEg aGVhZGVyIGZpZWxkcyBoYXZlIGJlZW4gcmVtb3ZlZCBmb3IgY29uY2lzaW9uLg0KPiA+Pg0KDQo= From nobody Thu Mar 14 08:35:14 2019 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 91DCE130EE7; Thu, 14 Mar 2019 08:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 HrYrC9-9jStN; Thu, 14 Mar 2019 08:34:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F1D130EDF; Thu, 14 Mar 2019 08:34:54 -0700 (PDT) Received: from MacBook-Pro.roach.at (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 x2EFYklO045733 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Mar 2019 10:34:48 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1552577690; bh=nMFJwfDipRiwVREv318iKeqHzYu8GYKNmIzd27hPmAM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Be84reve9XWqTXC5xMPBujyz5v7NzOWk7AopcuWeO3evTCQs5KMFjZ9pdgmL9eLlO rgM+y5LU4JGHdnwUG17NyiwV6iZpMhzRhULtUCEg2td5GiSOuaT5/1mSAaQvWDPdx4 Sv66ga7R00WmnR25ghC0pHqTlCryJTlCWkk1Fj0s= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: R.Jesske@telekom.de, iesg@ietf.org Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org, br@brianrosen.net, sipcore-chairs@ietf.org, sipcore@ietf.org References: <155176292818.5224.17119790703710957363.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Thu, 14 Mar 2019 10:34:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [sipcore] Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 15:35:08 -0000 On 3/14/19 2:24 AM, R.Jesske@telekom.de wrote: > Thank you Adam for your Answer. > I will upload the draft as soon as the upload page opens again. i.e. 23.03. > Or is there any possibility to do it now? Sure. Ordinarily, you'd ask the responsible AD to approve a manual posting; but, since Ben is on PTO at the moment, I'm happy to give approval. Send an email to iesg-secretary@ietf.org with the draft attached, requesting manual posting. Be sure to copy art-ads@ietf.org on that email, and I'll send an approval message. /a From nobody Fri Mar 15 11:05:49 2019 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 9F78F130DEC; Fri, 15 Mar 2019 11:05:40 -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.94.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <155267314057.22026.2988782249297748458@ietfa.amsl.com> Date: Fri, 15 Mar 2019 11:05:40 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 18:05:41 -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 WG of the IETF. Title : ISUP Cause Location Parameter for the SIP Reason Header Field Author : Roland Jesske Filename : draft-ietf-sipcore-reason-q850-loc-07.txt Pages : 7 Date : 2019-03-15 Abstract: The SIP Reason header field is defined for carrying ISUP (Integrated Services Digital Network User Part) cause values as well as SIP response codes. Some services in SIP networks may need to know the ISUP location where the call was released in the PSTN network to correctly interpret the reason of release. This document will update RFC3326. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-reason-q850-loc-07 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-reason-q850-loc-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-reason-q850-loc-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 15 11:22:48 2019 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 A1E2D130ED0 for ; Fri, 15 Mar 2019 11:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 kzJcOGYXHt-s for ; Fri, 15 Mar 2019 11:22:44 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CFC130ECA for ; Fri, 15 Mar 2019 11:22:43 -0700 (PDT) Received: from PaulKyzivatsMBP.localdomain (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.14.7/8.12.4) with ESMTP id x2FIMf8a011419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 15 Mar 2019 14:22:42 -0400 To: sipcore@ietf.org References: <155267314057.22026.2988782249297748458@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <19111e0e-50fa-13fe-5639-8f8f2389acee@alum.mit.edu> Date: Fri, 15 Mar 2019 14:22:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <155267314057.22026.2988782249297748458@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 18:22:46 -0000 Is there a reason why isup-location-value is case sensitive? Most stuff in sip is not. Thanks, Paul From nobody Fri Mar 15 11:23:53 2019 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 E75C3130ECF; Fri, 15 Mar 2019 11:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 nIZoXeHy76Al; Fri, 15 Mar 2019 11:23:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 412F4130ED0; Fri, 15 Mar 2019 11:23:38 -0700 (PDT) Received: from MacBook-Pro.roach.at (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 x2FINXRl007253 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 Mar 2019 13:23:35 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1552674216; bh=BjQkjYCVqQ0JmrUigagF703EyU+K0uCvQuueBbFo2Aw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=qXwekWs0b3ID1vidC/vUYcOjCviCw3qJ9S0dJYVfb/Ryr/iszGegsggixNsokK5p8 0Lph2ZHIg8scbULkvKas6nucw6oy//RXUhJcitY39sHsQShbculHt5mp5eeHL0rUGy 3ewqUOFmulRhhJvX8TSdcsFgIKy2henDZ7QIkSMg= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: R.Jesske@telekom.de, iesg@ietf.org Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org, br@brianrosen.net, sipcore-chairs@ietf.org, sipcore@ietf.org References: <155176292818.5224.17119790703710957363.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Fri, 15 Mar 2019 13:23:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9BE41B94D1EA17B541D35387" Content-Language: en-US Archived-At: Subject: Re: [sipcore] Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 18:23:43 -0000 This is a multi-part message in MIME format. --------------9BE41B94D1EA17B541D35387 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 3/11/19 3:23 AM, R.Jesske@telekom.de wrote: > Hi, > Thank you for your comments. I went through the comments and here are my answers and proposals to the comments made. > Sorry If some of you get the mail twice, since I answered in another way already. > > 1. Discuss: > §4 ABNF > Have incorporated the proposal. I'm going to clear my discuss, but we'll need at least one more version (or an RFC Editor's note) that mentions RFC 7405; for example: OLD: The Augmented BNF (ABNF) [RFC5234] for this parameter is shown in Figure 1. NEW: The Augmented BNF (ABNF) [RFC5234], with case-sensitive extensions [RFC7405], for this parameter is shown in Figure 1. If you want to submit a new draft with this change, I'll approve it for posting. /a --------------9BE41B94D1EA17B541D35387 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 3/11/19 3:23 AM, R.Jesske@telekom.de wrote:
Hi,
Thank you for your comments. I went through the comments and here are my answers and proposals to the comments made.
Sorry If some of you get the mail twice, since I answered in another way already.

1.  Discuss:
§4 ABNF
Have incorporated the proposal.


I'm going to clear my discuss, but we'll need at least one more version (or an RFC Editor's note) that mentions RFC 7405; for example:

OLD:

   The Augmented
   BNF (ABNF) [RFC5234] for this parameter is shown in Figure 1.

NEW:

   The Augmented BNF (ABNF) [RFC5234], with case-sensitive
   extensions [RFC7405], for this parameter is shown in Figure 1.

If you want to submit a new draft with this change, I'll approve it for posting.

/a

--------------9BE41B94D1EA17B541D35387-- From nobody Fri Mar 15 11:27:34 2019 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 29FC2130E70 for ; Fri, 15 Mar 2019 11:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 bEgKmINtQZRu for ; Fri, 15 Mar 2019 11:27:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54FD130ED0 for ; Fri, 15 Mar 2019 11:27:31 -0700 (PDT) Received: from MacBook-Pro.roach.at (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 x2FIRRSo007899 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 Mar 2019 13:27:28 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1552674448; bh=3bCef/FBkTS573hIAliCRGuSPVB/X28/4+GSqOfnHz4=; h=Subject:To:References:From:Date:In-Reply-To; b=cNDXqbguwXSKmIR2FvMHjQJ9qyvnzVw+S0m1BFWlOPM96wY4f9Ie1y1NS6JJQSHkb 6jDEfP6v/DQ6Cd4QnMoPZGZicTL/9BG+WUlKEepB+R715KuE7i+TuZxAsngm7Bn1Gg yCvuYEcxv42MJm5NbU7HmTeTk/WELHi54M1Wgs6o= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Paul Kyzivat , sipcore@ietf.org References: <155267314057.22026.2988782249297748458@ietfa.amsl.com> <19111e0e-50fa-13fe-5639-8f8f2389acee@alum.mit.edu> From: Adam Roach Message-ID: <041b7d55-21bc-0d82-1bec-c69ac7a63e9a@nostrum.com> Date: Fri, 15 Mar 2019 13:27:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <19111e0e-50fa-13fe-5639-8f8f2389acee@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 18:27:33 -0000 On 3/15/19 1:22 PM, Paul Kyzivat wrote: > Is there a reason why isup-location-value is case sensitive? Most > stuff in sip is not. The initial draft was ambiguous, although the use of all-caps implied (to me, at least) an intention for case-sensitivity. I don't care how it's resolved, but it can't be ambiguous. It may well be that case-insensitivity is the right choice here. (I note that we didn't try to use mnemonic tokens for cause-code; I suspect we could have simply defined location as an integer -- but I get the impression that we have implementations in the field already, so it's probably too late to make such a change.) /a From nobody Fri Mar 15 11:28:58 2019 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 BD22F130ECF; Fri, 15 Mar 2019 11:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 MzhNnC1gtXme; Fri, 15 Mar 2019 11:28:48 -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 3715E130ED8; Fri, 15 Mar 2019 11:28:48 -0700 (PDT) Received: from MacBook-Pro.roach.at (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 x2FISi9j008110 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 Mar 2019 13:28:45 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1552674526; bh=45r5XJDlGMDs0gPrN1O5jOkNNrJh3nrhUEsCq36iB80=; h=Subject:From:To:Cc:References:Date:In-Reply-To; b=fbJbtmmFFLKG6YcssjovYk4AOR62fsGy7cgV6PqxZidMPky06FzSdqjcU8IAXtXuO 0OPt6+K/nDVGZ05cMfbNEmkh0PwnjtH7nB+EZbZmrRUq4HdKxhYXf7tXXBCZDMW0NQ oheXByTRW8m787IuHLI1N0hkHVKk8tQBcyR0DqQo= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at From: Adam Roach To: R.Jesske@telekom.de, iesg@ietf.org Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, br@brianrosen.net References: <155176292818.5224.17119790703710957363.idtracker@ietfa.amsl.com> Message-ID: <4c7cd81c-7f4c-b893-3c55-618fe26f4836@nostrum.com> Date: Fri, 15 Mar 2019 13:28:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [sipcore] Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 18:28:50 -0000 On 3/15/19 1:23 PM, Adam Roach wrote: > On 3/11/19 3:23 AM, R.Jesske@telekom.de wrote: >> Hi, >> Thank you for your comments. I went through the comments and here are my answers and proposals to the comments made. >> Sorry If some of you get the mail twice, since I answered in another way already. >> >> 1. Discuss: >> §4 ABNF >> Have incorporated the proposal. > > > I'm going to clear my discuss > Based on Paul Kyzivat's comment on the SIPCORE mailing list, I'm going to hold off and talk to Ben before I clear. Sorry for the confusion. /a From nobody Mon Mar 18 07:04:17 2019 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 D8EDC126F72; Mon, 18 Mar 2019 07:04:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 jp4Nv6nUhBL2; Mon, 18 Mar 2019 07:04:06 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 A9E14127A73; Mon, 18 Mar 2019 07:04:05 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2IE3xBg021007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Mar 2019 10:04:01 -0400 Date: Mon, 18 Mar 2019 09:03:58 -0500 From: Benjamin Kaduk To: R.Jesske@telekom.de Cc: noreply@ietf.org, iesg@ietf.org, draft-ietf-sipcore-reason-q850-loc@ietf.org, sipcore@ietf.org, sipcore-chairs@ietf.org Message-ID: <20190318140358.GB80498@kduck.mit.edu> References: <155193609023.13714.4531517779875308584.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 14:04:09 -0000 On Mon, Mar 11, 2019 at 08:20:34AM +0000, R.Jesske@telekom.de wrote: > Hi, > Thank you for your comments. I went through the comments and > here are my answers and proposals to the comments made. > Sorry If some of you get the mail twice, since I answered in another way already. I do not mind the extra mail, and I must apologize myself for the slowness of the reply. > > Discuss on Section 4 > Do you want to see something beyond the Note I put in? > Note: These are the values defined within as location. Thus other values are not within the scope of this document. The main thing I wanted to be clarified was that the string name is the actual codepoint used on the wire (as opposed to some encoding of the four-bit value). Changing to use ABNF for the specification os isup-location-value is sufficient to clarify that point; the only remaining potential issue would be regarding potential future changes/allocations... > The last try to change these values in ITU-T was around 2001/2002 for some mobile network code points. This was rejected since operators said that there is willingness to change ISUP for such coding points. The values are stable since 20 years so there will be no change of these values in future, since invest will go into IP based networks like IMS. ... and it sounds like the expected chances of any such changes are very low. I would still ask you to consider adding a note to the effect of "Note that the 'LOC=*' names are the wire codepoints for the values currently left as 'spare' or 'reserved' in [Q.850]; these will continue to be the wire codepoints in the case of future allocation or national usage." I am happy to listen to some reasoning about why even that statement is not needed, though. (BTW, given the presence of all 16 possible 4-bit values, I don't think the current Note about "other values are not within the scope" is adding much value, and potentially could be replaced by my suggested note above.) > Comments on Section 1,3 and 4 > Nits on Section 1+3 corrected. > > Section 4: > I try to reformulate the sentence. > Proposal: > > UAC or UAS SHALL include the location parameter in a request or response when setting up the Reason header field with a [Q.850] cause. This approach is only possible in cases when the ISUP [Q.850] location is available. That helps a lot, thank you. > If you are OK with these changes I will produce a new draft and upload it. That would work, but it's also fine if you want to wait until the issue Adam raised comes to a complete resolution on the list. Thanks, Benjamin > Thank you and Best Regards > > Roland > > -----Ursprngliche Nachricht----- > > Von: sipcore Im Auftrag von Datatracker on > > behalf of Benjamin Kaduk > > Gesendet: Donnerstag, 7. Mrz 2019 06:22 > > An: The IESG > > Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org; sipcore-chairs@ietf.org; > > sipcore@ietf.org > > Betreff: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason- > > q850-loc-06: (with DISCUSS and COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-sipcore-reason-q850-loc-06: 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-reason-q850-loc/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I support Adam's Discuss. > > > > I also think that the Section 4 text: > > > > The use of the location parameter is restricted to Q850 cause values. > > Other values MUST be ignored if present. > > > > needs to be clear about whether it is intended to limit to the exact 16 strings > > listed above, or whether the intent is to update with Q850 if new values are > > allocated. Are string aliases allowed for the "national-use" codepoints if > > allocated within a given nation? > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 1 > > > > the reason of release. The reason of release does indicate why a SIP > > Dialog or an PSTN call, in case where the call was interworked to the > > > > nits: s/does indicate/indicates/ ; s/an PSTN/a PSTN/ > > > > Section 3 > > > > The primary intent of the parameter defined in this specification is > > for use in IMS (IP Multimedia Subsystem) networks defined by 3GPP but > > also open to be used by any other network that includes ISUP > > > > nit: s/also/it is also/ > > > > Section 4 > > > > Depending on whether the message is a request or a response the UAC > > or UAS SHALL include the location parameter when setting up the > > Reason header field with a [Q.850] cause. This approach is only > > possible in cases when the ISUP [Q.850] location is available. > > > > I don't understand what depends on whether the message is a request or a > > response. > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Mar 18 18:58:12 2019 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 A0391130F0B for ; Mon, 18 Mar 2019 18:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 qWN6yUxK5lXD for ; Mon, 18 Mar 2019 18:58:09 -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 E6676130EAF for ; Mon, 18 Mar 2019 18:58:08 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2J1w2bL077741 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 18 Mar 2019 20:58:03 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1552960684; bh=pdATm6j3IOdGM8ciuuLTyHoUpFKXv/KSENxIpl0kqxg=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=EHdyLyznY0sh5ADdhlgvddvd6DFMXxNx5uBLoOOQ60beaYYJkTejJ0Yrheq+2NGIy 5Kd20TkUegWzXP2XvtXUDAnhZ1wQ8XP/1gYkGXqcbynmesVATIcr7/a2iZXs9DAtpA 3FaNDwD+DVp+/9pUs1HZHuVNDP3hl8w/8VjDwXz0= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: <154B4A8E-FEF4-487B-9D46-F715ADA82529@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_89BF253B-5A4B-4A5B-A803-BDCAB0EEF2D4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 18 Mar 2019 20:57:54 -0500 In-Reply-To: <041b7d55-21bc-0d82-1bec-c69ac7a63e9a@nostrum.com> Cc: Paul Kyzivat , sipcore@ietf.org To: Adam Roach References: <155267314057.22026.2988782249297748458@ietfa.amsl.com> <19111e0e-50fa-13fe-5639-8f8f2389acee@alum.mit.edu> <041b7d55-21bc-0d82-1bec-c69ac7a63e9a@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 01:58:11 -0000 --Apple-Mail=_89BF253B-5A4B-4A5B-A803-BDCAB0EEF2D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 15, 2019, at 1:27 PM, Adam Roach wrote: >=20 > On 3/15/19 1:22 PM, Paul Kyzivat wrote: >> Is there a reason why isup-location-value is case sensitive? Most = stuff in sip is not. >=20 >=20 > The initial draft was ambiguous, although the use of all-caps implied = (to me, at least) an intention for case-sensitivity. I don't care how = it's resolved, but it can't be ambiguous. It may well be that = case-insensitivity is the right choice here. >=20 > (I note that we didn't try to use mnemonic tokens for cause-code; I = suspect we could have simply defined location as an integer -- but I get = the impression that we have implementations in the field already, so = it's probably too late to make such a change.) I would assume it to be the same as for 3326, which of course doesn=E2=80=99= t say either. But doesn=E2=80=99t 3261 make all this sort of thing = case-insensitive unless stated otherwise? 7.3.1 says "Unless otherwise = stated in the definition of a particular header field, field values, = parameter names, and parameter values are case-insensitive.=E2=80=9C Ben. >=20 > /a >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_89BF253B-5A4B-4A5B-A803-BDCAB0EEF2D4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlyQTKIACgkQgFZKbJXz 1A3GRA/8CMJQQPKbpgxxQNyIpVbQNRPdnKQJKyUE2lCK/PiutO0ZYBU0cjE/B6ap bP86ziXfck4vHBXRyNYhr8PCXPx+axSUuQUBmP6zFTQ59pPzjZ8y11Sdhosq6S9G s2Z1+eRftSK3utbAPmfzsWVjvY4kopLIj45FvdEPh+ZZriW+0c7iyptiCPlzeVTv 6ky2PCKqTJyPBrow2gLOcXaUnFtXm1prVZ8oyaN+eFxxOL+sgXguHA9kX88+e/gm p0hq9VushdcZK5e+qYjM071iy+emyIIuWQXnieGVK9LqyjmARWA5YRI3spLV5r8w 5tXgkTHdlD3WdMVM4oQP63z37ByYjPSZNEkuQQcgaJlatfknC3i7MIIqd6o5lFVQ m73ewuj0WvIzCcCjNPJEYnfaVvpdwQfVIoqOu3gZd4VasiWIL7NYj9oQzlcCtkE5 e9csMY6et7NQOQTQF83Nc/q/pQ99qmkhcBEZE+bncd21gmNEtRBBqes8ZFLeJaQv gYXd8do/rBNto8Jbl8iFPVARvAOkihD7XmkqNOBFWfK2/yLRkZ8+spJ85jBv/VlD g1DQbAFKPc5gEHauFaYlsK6KCwdN3Lc7/OmfKuk8er8XPermt+g0ieOYJo47iwQp D0m8/Te9rg64B+CZfVybSk9T+cIXTHlxn2h6nOvFklveAtsp3fU= =F0I1 -----END PGP SIGNATURE----- --Apple-Mail=_89BF253B-5A4B-4A5B-A803-BDCAB0EEF2D4-- From nobody Tue Mar 19 11:43:33 2019 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 02216131535; Tue, 19 Mar 2019 11:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 pHm0ZyOPjJjC; Tue, 19 Mar 2019 11:43:30 -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 F0EE513150E; Tue, 19 Mar 2019 11:43:29 -0700 (PDT) Received: from MacBook-Pro.roach.at (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 x2JIhN5K042742 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Mar 2019 13:43:24 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553021007; bh=Kxqhz/ctrI4TXhJfUBmE1u+XH9T7xgHOBJ7Painmc84=; h=Subject:From:To:Cc:References:Date:In-Reply-To; b=Q5lA5lwUZ0MbNhzUfofXGmODzi7RD2DQEg3EW8XjxGiNN6NOf/OU0gNJOK1pQOFaq F3osUMoHmnjuvajrL1F3hOOgMqnSYPBGu4BttlUzaws1dcF8ta3HBxjMdBr5JHp2Fj VI/uSbXjfitXNkUP46zk0zcuCVJqccOs6lWCeHic= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at From: Adam Roach To: R.Jesske@telekom.de, iesg@ietf.org Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, br@brianrosen.net References: <155176292818.5224.17119790703710957363.idtracker@ietfa.amsl.com> <4c7cd81c-7f4c-b893-3c55-618fe26f4836@nostrum.com> Message-ID: <1e95f0cf-3e09-44ac-b2e8-401dbdd38581@nostrum.com> Date: Tue, 19 Mar 2019 13:43:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <4c7cd81c-7f4c-b893-3c55-618fe26f4836@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [sipcore] Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 18:43:31 -0000 On 3/15/19 1:28 PM, Adam Roach wrote: > On 3/15/19 1:23 PM, Adam Roach wrote: >> On 3/11/19 3:23 AM, R.Jesske@telekom.de wrote: >>> Hi, >>> Thank you for your comments. I went through the comments and here >>> are my answers and proposals to the comments made. >>> Sorry If some of you get the mail twice, since I answered in another >>> way already. >>> >>> 1.  Discuss: >>> §4 ABNF >>> Have incorporated the proposal. >> >> >> I'm going to clear my discuss >> > > Based on Paul Kyzivat's comment on the SIPCORE mailing list, I'm going > to hold off and talk to Ben before I clear. Sorry for the confusion. > Based on Paul's comment and on Ben's reminder that SIP fields are generally case-insensitive (both on the SIPCORE mailing list), I think the solution here is to simply remove all of the instances of "%s" in the BNF I sent. Sorry for the extra round-trip here. /a From nobody Tue Mar 19 12:25:46 2019 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 4F97D12D4E8 for ; Tue, 19 Mar 2019 12:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=web.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9fyGdbn56cS for ; Tue, 19 Mar 2019 12:25:43 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.4]) (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 2F0271200ED for ; Tue, 19 Mar 2019 12:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1553023527; bh=YCzCQoKe3Qdlep3UlJH2nP8pJauIpjyVCKoyj7d5Epo=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date; b=eHXNSlMXHizMZ7p1rGmBQeveQ9yWVW0kM0YPMbf09TZH3GTzEglm4hh48dmgV1oTm RZfS6gZin9fHC4NTR2CJ1cdPqaNhhTZ0NhaB7G0EoU4ItYI4mMKtrju9T1o+vHLnMC QiBr+d9oKcEqM4oF2hi1fLLguA9tXjZT7xErZ0Ys= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from [194.208.80.46] ([194.208.80.46]) by msvc-mesg-web001.server.lan (via HTTP); Tue, 19 Mar 2019 20:25:27 +0100 MIME-Version: 1.0 Message-ID: From: "Roland Jesske" To: "Ben Campbell" , "Adam Roach" , "Ben Campbell" , "Adam Roach" Cc: sipcore@ietf.org Content-Type: text/html; charset=UTF-8 Importance: normal Date: Tue, 19 Mar 2019 20:25:27 +0100 Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-Provags-ID: V03:K1:7H3F/tmHeAS0rdWMJxTR2wrrGdqjAUFGhATjUO/DGYrd9GkqAKWcUfpndocZ6XX2HmAxO QvzblcpcldURaR60eYDsW+cHizFqNX/b2aOQZnrABDV/8D4OUd2xjPRGqkXcquQNQMCEMlmM0SNX HqxMj3cGnRm36TVgJmL8M2st71xwWNyUbMe9Sm2NsUrYFEr/T4uvFzmG3EUnUI4F0+vICq2cUx6A Nro2UVnto+brzbwEf9nbcTUNDZo9EPnFejjDXKIyWzVC0zN+D7aRjUdD1AsKSsrm4nU/f53xBqGO As= X-UI-Out-Filterresults: notjunk:1;V03:K0:UMg5cEqGm1I=:SUiJAuiSOyNYCaWSMdnd/G yAkM7Be+NlFraPKL2sZasoq3L90I9TTrA47cEYEdPUAtIld1W3s5nKvi48JaQifG06LH+jVP5 0zmA3H2oxVV9mouG4HrpVibYGNRDBSJxM1qboE8+iX+lgQwLv6gWvBI8KcNu6pLAvjxYYK5aD wovy/tE4c0yQQo1kLnK/4Yn7wA3Zx9d7iuAxO2XI0cZcPDhNjf6LIZNEKOhlM+bQEir+P9Dma 1nBKBzaw67qorwTFBZ7CZFYZ/tzhF8EoAkV2JSj0tJXxx8Q8bglimEL1DKtperZcmZpKb/wkH 9cTf8xNZhIprMGYFlq0eqrMvfs+GTEBtByr5ZdBrSTADjlIjDiUEiQoywFUP+cmCK8+9qF2FP DT6vrvfzieFiV9DhejX7mk15M3w8gXkhdWSFKc/zESWN/lmcua7lqTl40iwLkzDamFp1y1cl4 yko9ko8exj3lpChIO/9eS2ALuUsS5aHnr6SSCKD2T+dEwKEu+Ax8YS0EDkmopY07ZDKF/jrxB osghT3fPAc1v/3OH3wx2OEWc4uKV6XzOt/LX4wa2ETaE/eaSD4aykBRmlCuLpj8p8mzjwg7Ol /80EsH3dIxIAQKFsLo8mhJQfZevLAhaUpmOkeQuPj9rrIlIiG/9hb7rA== Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 19:25:45 -0000
Hi,
Sorry for my late answer=2E I'm not in the office=2E
So personally I do not care=2E And I got no other comment from my people= =2E So we could also go fore case insensitive if people are happy=2E If it = is ok I will release an further draft when I'm back=2E
Roland
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit WEB=2EDE Mail gesendet=2E
Am 19=2E03=2E19, 02:57, Be= n Campbell <ben@nostrum=2Ecom> schrieb:
> On Mar 15, 2019, at 1:27 PM, Adam Roach wrote: >=20 > On 3/15/19 1:22 PM, Paul Kyzivat wrote: >> Is there a reason why isup-location-value is case sensitive? Most stuff= in sip is not=2E >=20 >=20 > The initial draft was ambiguous, although the use of all-caps implied (t= o me, at least) an intention for case-sensitivity=2E I don't care how it's = resolved, but it can't be ambiguous=2E It may well be that case-insensitivi= ty is the right choice here=2E >=20 > (I note that we didn't try to use mnemonic tokens for cause-code; I susp= ect we could have simply defined location as an integer -- but I get the im= pression that we have implementations in the field already, so it's probabl= y too late to make such a change=2E) I would assume it to be the same as for 3326, which of course doesn=E2=80= =99t say either=2E But doesn=E2=80=99t 3261 make all this sort of thing cas= e-insensitive unless stated otherwise? 7=2E3=2E1 says "Unless otherwise st= ated in the definition of a particular header field, field values, paramete= r names, and parameter values are case-insensitive=2E=E2=80=9C Ben=2E >=20 > /a >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf=2Eorg > https://www=2Eietf=2Eorg/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf=2Eorg https://www=2Eietf=2Eorg/mailman/listinfo/sipcore
From nobody Tue Mar 19 19:21:28 2019 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 9973D12D4F3; Tue, 19 Mar 2019 19:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 0RTQfpPFWBSt; Tue, 19 Mar 2019 19:21:11 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A886A128B01; Tue, 19 Mar 2019 19:21:11 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2K2L1sD016640 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Mar 2019 21:21:03 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553048468; bh=ECP21jk3sSDIKu6M3XweYvXhFT33CprlDxPBoyzlxRQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=fHWBgfHHsfZqmaY7R0s7aKG37CQR2UC85sMZrLYXYBNYomwBsORG1/rmtu2DbWSjx RNNghDUyF9rTkdi1mE/TFs+EA4oFp52oiJRAVCbFHbbzKd4ImBTQsEGrPr6XOnRiT4 ZLqfYYZJLTs1KGmN7Y9btuO3PDivr37MJum4Mcns= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: <623C7EE8-05D6-4BD6-98AA-1B5750EB522D@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8C9FA427-A65B-47F0-B880-5C700DBBD234"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 19 Mar 2019 21:20:55 -0500 In-Reply-To: <1e95f0cf-3e09-44ac-b2e8-401dbdd38581@nostrum.com> Cc: R.Jesske@telekom.de, iesg@ietf.org, br@brianrosen.net, draft-ietf-sipcore-reason-q850-loc@ietf.org, sipcore@ietf.org, sipcore-chairs@ietf.org To: Adam Roach References: <155176292818.5224.17119790703710957363.idtracker@ietfa.amsl.com> <4c7cd81c-7f4c-b893-3c55-618fe26f4836@nostrum.com> <1e95f0cf-3e09-44ac-b2e8-401dbdd38581@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [sipcore] Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 02:21:14 -0000 --Apple-Mail=_8C9FA427-A65B-47F0-B880-5C700DBBD234 Content-Type: multipart/alternative; boundary="Apple-Mail=_4AB8F12E-53D1-4F27-B139-51C5888FCE3D" --Apple-Mail=_4AB8F12E-53D1-4F27-B139-51C5888FCE3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 19, 2019, at 1:43 PM, Adam Roach wrote: >=20 > On 3/15/19 1:28 PM, Adam Roach wrote: >> On 3/15/19 1:23 PM, Adam Roach wrote: >>> On 3/11/19 3:23 AM, R.Jesske@telekom.de wrote: >>>> Hi, >>>> Thank you for your comments. I went through the comments and here = are my answers and proposals to the comments made. >>>> Sorry If some of you get the mail twice, since I answered in = another way already. >>>>=20 >>>> 1. Discuss: >>>> =C2=A74 ABNF >>>> Have incorporated the proposal. >>>=20 >>>=20 >>> I'm going to clear my discuss >>>=20 >>=20 >> Based on Paul Kyzivat's comment on the SIPCORE mailing list, I'm = going to hold off and talk to Ben before I clear. Sorry for the = confusion. >>=20 >=20 > Based on Paul's comment and on Ben's reminder that SIP fields are = generally case-insensitive (both on the SIPCORE mailing list), I think = the solution here is to simply remove all of the instances of "%s" in = the BNF I sent. Sorry for the extra round-trip here. >=20 Like the following? If so, I can drop this into an RFC Editor note: OLD: reason-extension =3D/ isup-cause-location isup-cause-location =3D "location" EQUAL isup-location-value isup-location-value =3D %s"U" / ; for 0 0 0 0 user %s"LPN" / ; for 0 0 0 1 private network serving the local user %s"LN" / ; for 0 0 1 0 public network serving the local user %s"TN" / ; for 0 0 1 1 transit network %s"RLN" / ; for 0 1 0 0 public network serving the remote user %s"RPN" / ; for 0 1 0 1 private network serving the remote user %s"LOC-6" / ; for 0 1 1 0 spare %s"INTL" / ; for 0 1 1 1 international network %s"LOC-8" / ; for 1 0 0 0 spare %s"LOC-9" / ; for 1 0 0 1 spare %s"BI" / ; for 1 0 1 0 network beyond interworking point %s"LOC-11" / ; for 1 0 1 1 spare %s"LOC-12" / ; for 1 1 0 0 reserved for national use %s"LOC-13" / ; for 1 1 0 1 reserved for national use %s"LOC-14" / ; for 1 1 1 0 reserved for national use %s"LOC-15" ; for 1 1 1 1 reserved for national use Figure 1: isup-cause-location NEW: reason-extension =3D/ isup-cause-location isup-cause-location =3D "location" EQUAL isup-location-value isup-location-value =3D "U" / ; for 0 0 0 0 user "LPN" / ; for 0 0 0 1 private network serving the local user "LN" / ; for 0 0 1 0 public network serving the local user "TN" / ; for 0 0 1 1 transit network "RLN" / ; for 0 1 0 0 public network serving the remote user "RPN" / ; for 0 1 0 1 private network serving the remote user "LOC-6" / ; for 0 1 1 0 spare "INTL" / ; for 0 1 1 1 international network "LOC-8" / ; for 1 0 0 0 spare "LOC-9" / ; for 1 0 0 1 spare "BI" / ; for 1 0 1 0 network beyond interworking point "LOC-11" / ; for 1 0 1 1 spare "LOC-12" / ; for 1 1 0 0 reserved for national use "LOC-13" / ; for 1 1 0 1 reserved for national use "LOC-14" / ; for 1 1 1 0 reserved for national use "LOC-15" ; for 1 1 1 1 reserved for national use Figure 1: isup-cause-location --Apple-Mail=_4AB8F12E-53D1-4F27-B139-51C5888FCE3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 19, 2019, at 1:43 PM, Adam Roach <adam@nostrum.com> = wrote:

On 3/15/19 1:28 PM, Adam Roach = wrote:
On = 3/15/19 1:23 PM, Adam Roach wrote:
On 3/11/19 3:23 AM, R.Jesske@telekom.de wrote:
Hi,
Thank you for your comments. = I went through the comments and here are my answers and proposals to the = comments made.
Sorry If some of you get the mail twice, = since I answered in another way already.

1.  Discuss:
=C2=A74 ABNF
Have= incorporated the proposal.


I'm going to clear my discuss


Based on Paul Kyzivat's comment = on the SIPCORE mailing list, I'm going to hold off and talk to Ben = before I clear. Sorry for the confusion.


Based on Paul's comment and on Ben's reminder that SIP fields = are generally case-insensitive (both on the SIPCORE mailing list), I = think the solution here is to simply remove all of the instances of "%s" = in the BNF I sent. Sorry for the extra round-trip here.


Like the = following? If so, I can drop this into an RFC Editor note:

OLD:
reason-extension =3D/ =
isup-cause-location
isup-cause-location =3D  "location" EQUAL isup-location-value

   isup-location-value =3D
      %s"U" /      ; for 0 0 0 0 user
      %s"LPN" /    ; for 0 0 0 1 private network serving the local user
      %s"LN" /     ; for 0 0 1 0 public network serving the local user
      %s"TN" /     ; for 0 0 1 1 transit network
      %s"RLN" /    ; for 0 1 0 0 public network serving the remote user
      %s"RPN" /    ; for 0 1 0 1 private network serving the remote user
      %s"LOC-6" /  ; for 0 1 1 0 spare
      %s"INTL" /   ; for 0 1 1 1 international network
      %s"LOC-8" /  ; for 1 0 0 0 spare
      %s"LOC-9" /  ; for 1 0 0 1 spare
      %s"BI" /     ; for 1 0 1 0 network beyond interworking point
      %s"LOC-11" / ; for 1 0 1 1 spare
      %s"LOC-12" / ; for 1 1 0 0 reserved for national use
      %s"LOC-13" / ; for 1 1 0 1 reserved for national use
      %s"LOC-14" / ; for 1 1 1 0 reserved for national use
      %s"LOC-15"   ; for 1 1 1 1 reserved for national use

                       Figure 1: isup-cause-location
NEW:
reason-extension =3D/ =
isup-cause-location
isup-cause-location =3D  "location" EQUAL isup-location-value

   isup-location-value =3D
      "U" /      ; for 0 0 0 0 user
      "LPN" /    ; for 0 0 0 1 private network serving the local user
      "LN" /     ; for 0 0 1 0 public network serving the local user
      "TN" /     ; for 0 0 1 1 transit network
      "RLN" /    ; for 0 1 0 0 public network serving the remote user
      "RPN" /    ; for 0 1 0 1 private network serving the remote user
      "LOC-6" /  ; for 0 1 1 0 spare
      "INTL" /   ; for 0 1 1 1 international network
      "LOC-8" /  ; for 1 0 0 0 spare
      "LOC-9" /  ; for 1 0 0 1 spare
      "BI" /     ; for 1 0 1 0 network beyond interworking point
      "LOC-11" / ; for 1 0 1 1 spare
      "LOC-12" / ; for 1 1 0 0 reserved for national use
      "LOC-13" / ; for 1 1 0 1 reserved for national use
      "LOC-14" / ; for 1 1 1 0 reserved for national use
      "LOC-15"   ; for 1 1 1 1 reserved for national use

                       Figure 1: isup-cause-location




= --Apple-Mail=_4AB8F12E-53D1-4F27-B139-51C5888FCE3D-- --Apple-Mail=_8C9FA427-A65B-47F0-B880-5C700DBBD234 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlyRo4cACgkQgFZKbJXz 1A1ptQ//eKOVDjZqHsKgupyxaDRS+kkXFF5PzG8smj3t+P1J+WUbRcTamE3gI4bY +FeP+ANm73jE2rBqwsCQ67RJ3IRMAa1Vrp6GxyxiBLYV8/ioCgugIkKUsJGz1cZk UukoQbj0yXqK8rjT/crHPHiKLaJ5cOqMxh6L9W1Fosipk0qiM49flkVNS/Tb0lgE AQp+YRWRhXHvyMLqTMRpY00LdZhz8qEPU0R+ZcmgtSi3asPj4+n2aVf2Hv+fGsot LP9NUSUGhpOMfou/gEiMeOezuYDmaEK/fQjpe9l0t/9AdlRn3aigi9VRChSrbR5P HHA0KKS4bbJcky0tewozRpuR3LKOU5lRrkN/Ylk9nege9e2B+65fp9bZgHfq/ZaJ UIzzL3wbdHcSfqxXE1DfO1JN4Xebxfhad3ckEe1p/OzKh6HyHGx9c0I9AccRMcie na0aQQ23Gci6NjJGfXYJ7uRDDIwWPJpEfYa5ElxbqmU5vk0nqOZqcJpKlqTrL7Dm /Ok4tEVfhR425jprRlRGjRSKsDXLOGZCc4AmtQIf30Ft0SrsAw9l3z7+Bzt2HnP9 BqV6JGLSlHd7LEXeBzPYxU/ZJUoPhmsyT2bcp059eojJ31unnCL6hsL64NoLwpAY sfGMziISF/UchW80EjNVG30BmdHVVcqqWsAhOlONXuVyiOJ+Nfk= =RBAN -----END PGP SIGNATURE----- --Apple-Mail=_8C9FA427-A65B-47F0-B880-5C700DBBD234-- From nobody Tue Mar 19 19:26:49 2019 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 86539130EA7; Tue, 19 Mar 2019 19:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 rQ-CD6tZ8GFD; Tue, 19 Mar 2019 19:26:38 -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 0F54A130EA0; Tue, 19 Mar 2019 19:26:38 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2K2QXmX017536 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Mar 2019 21:26:35 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553048796; bh=GRmUO2n0HYNvz09HS5BZKNy20skyXLYvCgQ0aGjaXBI=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=vTjGbVa5wQ/MeJX+ZFiNTMW47ksO9bQTjA3F4Zyr1NwM7xBbPfF/ZZ2UdUwYmLq2m tKn6GCYMESfFtvhXknG9vPhSFk8Fk869oTBS5tjKP3nkU1Ar7gF2nNst5AnwttHTSa PfVOMfWnpP6UGYwjY7aPypmeYwyjZYFGRyAKGzpc= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E5DDFCA7-48A3-4835-9F19-E7DB836659B2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 19 Mar 2019 21:26:27 -0500 In-Reply-To: <623C7EE8-05D6-4BD6-98AA-1B5750EB522D@nostrum.com> Cc: R.Jesske@telekom.de, iesg@ietf.org, br@brianrosen.net, draft-ietf-sipcore-reason-q850-loc@ietf.org, sipcore@ietf.org, sipcore-chairs@ietf.org To: Adam Roach References: <155176292818.5224.17119790703710957363.idtracker@ietfa.amsl.com> <4c7cd81c-7f4c-b893-3c55-618fe26f4836@nostrum.com> <1e95f0cf-3e09-44ac-b2e8-401dbdd38581@nostrum.com> <623C7EE8-05D6-4BD6-98AA-1B5750EB522D@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [sipcore] Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 02:26:41 -0000 --Apple-Mail=_E5DDFCA7-48A3-4835-9F19-E7DB836659B2 Content-Type: multipart/alternative; boundary="Apple-Mail=_F2848FAE-647F-4753-BEB2-B9E0A92ABA60" --Apple-Mail=_F2848FAE-647F-4753-BEB2-B9E0A92ABA60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 19, 2019, at 9:20 PM, Ben Campbell wrote: >=20 >=20 >=20 >> On Mar 19, 2019, at 1:43 PM, Adam Roach > wrote: >>=20 >> On 3/15/19 1:28 PM, Adam Roach wrote: >>> On 3/15/19 1:23 PM, Adam Roach wrote: >>>> On 3/11/19 3:23 AM, R.Jesske@telekom.de = wrote: >>>>> Hi, >>>>> Thank you for your comments. I went through the comments and here = are my answers and proposals to the comments made. >>>>> Sorry If some of you get the mail twice, since I answered in = another way already. >>>>>=20 >>>>> 1. Discuss: >>>>> =C2=A74 ABNF >>>>> Have incorporated the proposal. >>>>=20 >>>>=20 >>>> I'm going to clear my discuss >>>>=20 >>>=20 >>> Based on Paul Kyzivat's comment on the SIPCORE mailing list, I'm = going to hold off and talk to Ben before I clear. Sorry for the = confusion. >>>=20 >>=20 >> Based on Paul's comment and on Ben's reminder that SIP fields are = generally case-insensitive (both on the SIPCORE mailing list), I think = the solution here is to simply remove all of the instances of "%s" in = the BNF I sent. Sorry for the extra round-trip here. >>=20 >=20 > Like the following? If so, I can drop this into an RFC Editor note: Or do we also need to remove the double-quotes? >=20 > OLD: > reason-extension =3D/ isup-cause-location > isup-cause-location =3D "location" EQUAL isup-location-value >=20 > isup-location-value =3D > %s"U" / ; for 0 0 0 0 user > %s"LPN" / ; for 0 0 0 1 private network serving the local = user > %s"LN" / ; for 0 0 1 0 public network serving the local user > %s"TN" / ; for 0 0 1 1 transit network > %s"RLN" / ; for 0 1 0 0 public network serving the remote = user > %s"RPN" / ; for 0 1 0 1 private network serving the remote = user > %s"LOC-6" / ; for 0 1 1 0 spare > %s"INTL" / ; for 0 1 1 1 international network > %s"LOC-8" / ; for 1 0 0 0 spare > %s"LOC-9" / ; for 1 0 0 1 spare > %s"BI" / ; for 1 0 1 0 network beyond interworking point > %s"LOC-11" / ; for 1 0 1 1 spare > %s"LOC-12" / ; for 1 1 0 0 reserved for national use > %s"LOC-13" / ; for 1 1 0 1 reserved for national use > %s"LOC-14" / ; for 1 1 1 0 reserved for national use > %s"LOC-15" ; for 1 1 1 1 reserved for national use >=20 > Figure 1: isup-cause-location > NEW: > reason-extension =3D/ isup-cause-location > isup-cause-location =3D "location" EQUAL isup-location-value >=20 > isup-location-value =3D > "U" / ; for 0 0 0 0 user > "LPN" / ; for 0 0 0 1 private network serving the local user > "LN" / ; for 0 0 1 0 public network serving the local user > "TN" / ; for 0 0 1 1 transit network > "RLN" / ; for 0 1 0 0 public network serving the remote user > "RPN" / ; for 0 1 0 1 private network serving the remote user > "LOC-6" / ; for 0 1 1 0 spare > "INTL" / ; for 0 1 1 1 international network > "LOC-8" / ; for 1 0 0 0 spare > "LOC-9" / ; for 1 0 0 1 spare > "BI" / ; for 1 0 1 0 network beyond interworking point > "LOC-11" / ; for 1 0 1 1 spare > "LOC-12" / ; for 1 1 0 0 reserved for national use > "LOC-13" / ; for 1 1 0 1 reserved for national use > "LOC-14" / ; for 1 1 1 0 reserved for national use > "LOC-15" ; for 1 1 1 1 reserved for national use >=20 > Figure 1: isup-cause-location --Apple-Mail=_F2848FAE-647F-4753-BEB2-B9E0A92ABA60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 19, 2019, at 9:20 PM, Ben Campbell <ben@nostrum.com> = wrote:



On Mar 19, 2019, at 1:43 PM, = Adam Roach <adam@nostrum.com> wrote:

On 3/15/19 1:28 PM, Adam Roach = wrote:
On 3/15/19 1:23 PM, Adam Roach wrote:
On 3/11/19 3:23 AM, R.Jesske@telekom.de wrote:
Hi,
Thank = you for your comments. I went through the comments and here are my = answers and proposals to the comments made.
Sorry If some = of you get the mail twice, since I answered in another way already.

1.  Discuss:
=C2=A74 = ABNF
Have incorporated the proposal.


I'm going to clear = my discuss


Based = on Paul Kyzivat's comment on the SIPCORE mailing list, I'm going to hold = off and talk to Ben before I clear. Sorry for the confusion.


Based on Paul's comment and on Ben's = reminder that SIP fields are generally case-insensitive (both on the = SIPCORE mailing list), I think the solution here is to simply remove all = of the instances of "%s" in the BNF I sent. Sorry for the extra = round-trip here.


Like = the following? If so, I can drop this into an RFC Editor = note:

Or do we = also need to remove the double-quotes?


OLD:
reason-extension =3D/ =
isup-cause-location
isup-cause-location =3D  "location" EQUAL isup-location-value

   isup-location-value =3D
      %s"U" /      ; for 0 0 0 0 user
      %s"LPN" /    ; for 0 0 0 1 private network serving the local user
      %s"LN" /     ; for 0 0 1 0 public network serving the local user
      %s"TN" /     ; for 0 0 1 1 transit network
      %s"RLN" /    ; for 0 1 0 0 public network serving the remote user
      %s"RPN" /    ; for 0 1 0 1 private network serving the remote user
      %s"LOC-6" /  ; for 0 1 1 0 spare
      %s"INTL" /   ; for 0 1 1 1 international network
      %s"LOC-8" /  ; for 1 0 0 0 spare
      %s"LOC-9" /  ; for 1 0 0 1 spare
      %s"BI" /     ; for 1 0 1 0 network beyond interworking point
      %s"LOC-11" / ; for 1 0 1 1 spare
      %s"LOC-12" / ; for 1 1 0 0 reserved for national use
      %s"LOC-13" / ; for 1 1 0 1 reserved for national use
      %s"LOC-14" / ; for 1 1 1 0 reserved for national use
      %s"LOC-15"   ; for 1 1 1 1 reserved for national use

                       Figure 1: isup-cause-location
NEW:
reason-extension =3D/ =
isup-cause-location
isup-cause-location =3D  "location" EQUAL isup-location-value

   isup-location-value =3D
      "U" /      ; for 0 0 0 0 user
      "LPN" /    ; for 0 0 0 1 private network serving the local user
      "LN" /     ; for 0 0 1 0 public network serving the local user
      "TN" /     ; for 0 0 1 1 transit network
      "RLN" /    ; for 0 1 0 0 public network serving the remote user
      "RPN" /    ; for 0 1 0 1 private network serving the remote user
      "LOC-6" /  ; for 0 1 1 0 spare
      "INTL" /   ; for 0 1 1 1 international network
      "LOC-8" /  ; for 1 0 0 0 spare
      "LOC-9" /  ; for 1 0 0 1 spare
      "BI" /     ; for 1 0 1 0 network beyond interworking point
      "LOC-11" / ; for 1 0 1 1 spare
      "LOC-12" / ; for 1 1 0 0 reserved for national use
      "LOC-13" / ; for 1 1 0 1 reserved for national use
      "LOC-14" / ; for 1 1 1 0 reserved for national use
      "LOC-15"   ; for 1 1 1 1 reserved for national use

                       Figure 1: =
isup-cause-location

= --Apple-Mail=_F2848FAE-647F-4753-BEB2-B9E0A92ABA60-- --Apple-Mail=_E5DDFCA7-48A3-4835-9F19-E7DB836659B2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlyRpNMACgkQgFZKbJXz 1A04XA/+Iwij+z0PKZuFqA4dKh3E0f6Y1MUVZtPV5GTUAxWd3wspOKbv626SO+gs rpNCWYud6RnZegi86p62hE6rkrqezVDtkRcNw/xUultljc0Sll6RI/IXGvbARINp tVJSEl0hiF1sG8HEBJKOde8GJJRntqiQAANrp/NZj6wWw3AlYcMpyhWUveejhHkH fhQ1nDhaFDRNpjs3tN90CWuSS22S8b66c05Yrl2nMm4Fu81Q/NBJufo/BFOjHydy QwO/Rcvoji88RtO05+hzNUF3zi0XeGjY9DHvS6Ezc7cL67ECZWYJpWIpTjIFj3pH E+ENOJOQSwzH2mM8jAdCi6h/KTY61PlQ9pPGoDyyW2lyitirpvA5m6UHCR5Tuqit qAr5qPWG2QPAS4oTSzLUT4i4Pjv+QNX77NrVxi+N9Ke9mOORhV4kd5R9lPDrpbYB 7mMEXc7aeHqe0ITbLUZlPkPv2+/GH7uRnL6e4+voPBEDm4FwHvDDrv5b41l2RHe2 nyIkpROR4wUYPBdHNb54YgM0gjh0SrcSLNgyXV2/9p7jBFZ9Yp5grXTlm8dLeae5 67mcxN9xiuJxCgmyGiPg2G/VHMAQTnXRXLEh2bEc37YLvlaAvLwD+WtTQEqACHnY NMPqpki48r5LM2MwbeWdBApMyiU9K17ncyJIdoZ/oWIP/e3pmUs= =V4pS -----END PGP SIGNATURE----- --Apple-Mail=_E5DDFCA7-48A3-4835-9F19-E7DB836659B2-- From nobody Tue Mar 19 19:30:57 2019 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 6230112D4F3; Tue, 19 Mar 2019 19:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 Ycve4RoWvV4g; Tue, 19 Mar 2019 19:30:44 -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 7F429124C04; Tue, 19 Mar 2019 19:30:44 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2K2UeVW018224 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Mar 2019 21:30:41 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553049044; bh=rwjVB6TddcUobZOyvX4vcipUzQJSDpHndB45b9zSPxc=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=L45kOi2QMDLdJHan9lz7+AgP8xO2J7cwDcYe2gRKGngUGxM+9qL0RUuYCj1L6M6el Lrpzy4K/6FYqGFqDDoJsZiTU0Psl9V79RNMlCG50xGslPTBrqkkGT5HECfDiu6IxMW VepPBpyJ1ySiiycr1I3WHz9qY3KQqryRsOuhPBQo= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: <0446BC26-28C3-42B7-8DD6-F8D054883DAF@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_5890187D-E9A0-448F-959C-A776BB3A2E8B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 19 Mar 2019 21:30:34 -0500 In-Reply-To: <20190318140358.GB80498@kduck.mit.edu> Cc: =?utf-8?Q?Michael_T=C3=BCxen_via_Datatracker?= , draft-ietf-sipcore-reason-q850-loc@ietf.org, SIPCORE , IESG , sipcore-chairs@ietf.org, Benjamin Kaduk To: "" References: <155193609023.13714.4531517779875308584.idtracker@ietfa.amsl.com> <20190318140358.GB80498@kduck.mit.edu> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 02:30:46 -0000 --Apple-Mail=_5890187D-E9A0-448F-959C-A776BB3A2E8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Roland, Am I correct to understand that changes based on this discussion have = not yet made it into a draft? If so, when do you think that could = happen? Please note that the Plenary in Prague is sort of a deadline for this; = if I am not able approve it before then it will have to transition to = another AD, which could add delays while they come up to speed on it. Thanks! Ben. > On Mar 18, 2019, at 9:03 AM, Benjamin Kaduk wrote: >=20 > On Mon, Mar 11, 2019 at 08:20:34AM +0000, R.Jesske@telekom.de wrote: >> Hi, >> Thank you for your comments. I went through the comments and >> here are my answers and proposals to the comments made. >> Sorry If some of you get the mail twice, since I answered in another = way already. >=20 > I do not mind the extra mail, and I must apologize myself for the = slowness > of the reply. >=20 >>=20 >> Discuss on Section 4 >> Do you want to see something beyond the Note I put in? >> Note: These are the values defined within = as location. Thus other values are not within the scope of this = document. >=20 > The main thing I wanted to be clarified was that the string name is = the > actual codepoint used on the wire (as opposed to some encoding of the > four-bit value). Changing to use ABNF for the specification os > isup-location-value is sufficient to clarify that point; the only = remaining > potential issue would be regarding potential future = changes/allocations... >=20 >> The last try to change these values in ITU-T was around 2001/2002 for = some mobile network code points. This was rejected since operators said = that there is willingness to change ISUP for such coding points. The = values are stable since 20 years so there will be no change of these = values in future, since invest will go into IP based networks like IMS. >=20 > .... and it sounds like the expected chances of any such changes are = very > low. I would still ask you to consider adding a note to the effect of > "Note that the 'LOC=3D*' names are the wire codepoints for the values > currently left as 'spare' or 'reserved' in [Q.850]; these will = continue to > be the wire codepoints in the case of future allocation or national > usage." I am happy to listen to some reasoning about why even that > statement is not needed, though. >=20 > (BTW, given the presence of all 16 possible 4-bit values, I don't = think the > current Note about "other values are not within the scope" is adding = much > value, and potentially could be replaced by my suggested note above.) >=20 >> Comments on Section 1,3 and 4 >> Nits on Section 1+3 corrected. >>=20 >> Section 4: >> I try to reformulate the sentence. >> Proposal: >>=20 >> UAC or UAS SHALL include the location parameter in a request or = response when setting up the Reason header field with a [Q.850] cause. = This approach is only possible in cases when the ISUP [Q.850] location = is available. >=20 > That helps a lot, thank you. >=20 >> If you are OK with these changes I will produce a new draft and = upload it. >=20 > That would work, but it's also fine if you want to wait until the = issue > Adam raised comes to a complete resolution on the list. >=20 > Thanks, >=20 > Benjamin >=20 >> Thank you and Best Regards >>=20 >> Roland >>> -----Urspr=C3=BCngliche Nachricht----- >>> Von: sipcore Im Auftrag von Datatracker = on >>> behalf of Benjamin Kaduk >>> Gesendet: Donnerstag, 7. M=C3=A4rz 2019 06:22 >>> An: The IESG >>> Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org; = sipcore-chairs@ietf.org; >>> sipcore@ietf.org >>> Betreff: [sipcore] Benjamin Kaduk's Discuss on = draft-ietf-sipcore-reason- >>> q850-loc-06: (with DISCUSS and COMMENT) >>>=20 >>> Benjamin Kaduk has entered the following ballot position for >>> draft-ietf-sipcore-reason-q850-loc-06: Discuss >>>=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-reason-q850-loc/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> I support Adam's Discuss. >>>=20 >>> I also think that the Section 4 text: >>>=20 >>> The use of the location parameter is restricted to Q850 cause = values. >>> Other values MUST be ignored if present. >>>=20 >>> needs to be clear about whether it is intended to limit to the exact = 16 strings >>> listed above, or whether the intent is to update with Q850 if new = values are >>> allocated. Are string aliases allowed for the "national-use" = codepoints if >>> allocated within a given nation? >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> Section 1 >>>=20 >>> the reason of release. The reason of release does indicate why a = SIP >>> Dialog or an PSTN call, in case where the call was interworked to = the >>>=20 >>> nits: s/does indicate/indicates/ ; s/an PSTN/a PSTN/ >>>=20 >>> Section 3 >>>=20 >>> The primary intent of the parameter defined in this specification = is >>> for use in IMS (IP Multimedia Subsystem) networks defined by 3GPP = but >>> also open to be used by any other network that includes ISUP >>>=20 >>> nit: s/also/it is also/ >>>=20 >>> Section 4 >>>=20 >>> Depending on whether the message is a request or a response the = UAC >>> or UAS SHALL include the location parameter when setting up the >>> Reason header field with a [Q.850] cause. This approach is only >>> possible in cases when the ISUP [Q.850] location is available. >>>=20 >>> I don't understand what depends on whether the message is a request = or a >>> response. >>>=20 >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 --Apple-Mail=_5890187D-E9A0-448F-959C-A776BB3A2E8B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlyRpcoACgkQgFZKbJXz 1A2Jmw//az96D64JoxO31D1JAdCEMxqQLqXIdT5tXe2h8XA40P3gbz0BHpT3N6ee QBczr9hv4y9TWJmwe2h8JitUhvzUvMJszE0PjTKyJwBLKvoUCLOmkUX3s3fNQtxb Vbi4JUvoVD7DpiQYec8HpuJvNhXodkrCkkbRiiXyTO9oozoR6KfC9inFqAnJBOYw pZTi5QR8bycBUr14PIK6RJ+oOSzrWzYBW5uxHTdXiErWVhbL4qsji/Mxw7sAYPRR t65Fo0VCj0dvKpbzJIrYjxK+fVeY0X2DLYcRE/0YGsPCKGyk8ZZuB/Ja4b0sLeuc axjxJ1W5ez+g9E3cVOeWfDGeBRSfRDYY5ALt5zE00/SuNDyQf/0LirVQpHUzIxFt QGJkg5+8aS5/4g/noKRcRvb0BHNorXgmslzofBdqP1fb9dXy6ltJlFeGe5yvFE9h rnz+hsLNsbzoLZuU3wGqetth5xUFUA6OR9LF+1kdHJvEC0XT99gQh3hVZMWN1AD3 viTnJWXcKHIUTI6XUtuUU/NFXmSEOYtUzPfFoaafmZYCNjymsZK2adNjpdWy2qLv GXNgZ/VppMwK5LThxbjeL1WO9dkGa18iZe3blHRNStWo1oqKQ+9YHG4KvTXMfc0T TYfaW3WBL7P4CWcORl6b4frWwN/+5Hq/wPu1IYfYUZWSOtKTJHk= =qloe -----END PGP SIGNATURE----- --Apple-Mail=_5890187D-E9A0-448F-959C-A776BB3A2E8B-- From nobody Tue Mar 19 20:06:00 2019 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 07BDF130EDB for ; Tue, 19 Mar 2019 20:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 s76hmhzTxkFt for ; Tue, 19 Mar 2019 20:05: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 E317A12787D for ; Tue, 19 Mar 2019 20:05:56 -0700 (PDT) Received: from MacBook-Pro.roach.at (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 x2K35qpd023990 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Mar 2019 22:05:53 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553051156; bh=y62a81IH4U9LquMsJrR+ySh4mt+KapgpE0NDmUixtmw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=hxUHMZ0lDIE8h0QMPJmlY2bve6f5anuNwLisHCKUft+KdgiIvX73EWjUImhUNSJcM 3XYpJ0MfplBOpPeWN7pDTUPLPDXuyq3Og3/m671brcLQwCsyELkTzKU1FCka6z7YuB SaLZnSz2tSx97L/OWCNLxUe1rMzquXmkYfPGY7og= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Ben Campbell Cc: R.Jesske@telekom.de, iesg@ietf.org, br@brianrosen.net, draft-ietf-sipcore-reason-q850-loc@ietf.org, sipcore@ietf.org, sipcore-chairs@ietf.org References: <155176292818.5224.17119790703710957363.idtracker@ietfa.amsl.com> <4c7cd81c-7f4c-b893-3c55-618fe26f4836@nostrum.com> <1e95f0cf-3e09-44ac-b2e8-401dbdd38581@nostrum.com> <623C7EE8-05D6-4BD6-98AA-1B5750EB522D@nostrum.com> From: Adam Roach Message-ID: <9a35b1cb-ab25-9375-2c51-dd10a66a5a39@nostrum.com> Date: Tue, 19 Mar 2019 22:05:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1B6893A21F427FAD1CAE149D" Content-Language: en-US Archived-At: Subject: Re: [sipcore] Adam Roach's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 03:05:58 -0000 This is a multi-part message in MIME format. --------------1B6893A21F427FAD1CAE149D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The double-quotes are fine. Your RFC editor note addresses my issue completely. Clearing my discuss now. /a On 3/19/19 9:26 PM, Ben Campbell wrote: > > >> On Mar 19, 2019, at 9:20 PM, Ben Campbell > > wrote: >> >> >> >>> On Mar 19, 2019, at 1:43 PM, Adam Roach >> > wrote: >>> >>> On 3/15/19 1:28 PM, Adam Roach wrote: >>>> On 3/15/19 1:23 PM, Adam Roach wrote: >>>>> On 3/11/19 3:23 AM,R.Jesske@telekom.de >>>>> wrote: >>>>>> Hi, >>>>>> Thank you for your comments. I went through the comments and here >>>>>> are my answers and proposals to the comments made. >>>>>> Sorry If some of you get the mail twice, since I answered in >>>>>> another way already. >>>>>> >>>>>> 1.  Discuss: >>>>>> §4 ABNF >>>>>> Have incorporated the proposal. >>>>> >>>>> >>>>> I'm going to clear my discuss >>>>> >>>> >>>> Based on Paul Kyzivat's comment on the SIPCORE mailing list, I'm >>>> going to hold off and talk to Ben before I clear. Sorry for the >>>> confusion. >>>> >>> >>> Based on Paul's comment and on Ben's reminder that SIP fields are >>> generally case-insensitive (both on the SIPCORE mailing list), I >>> think the solution here is to simply remove all of the instances of >>> "%s" in the BNF I sent. Sorry for the extra round-trip here. >>> >> >> Like the following? If so, I can drop this into an RFC Editor note: > > Or do we also need to remove the double-quotes? > >> >> OLD: >> reason-extension =/ isup-cause-location >> isup-cause-location = "location" EQUAL isup-location-value >> >> isup-location-value = >> %s"U" / ; for 0 0 0 0 user >> %s"LPN" / ; for 0 0 0 1 private network serving the local user >> %s"LN" / ; for 0 0 1 0 public network serving the local user >> %s"TN" / ; for 0 0 1 1 transit network >> %s"RLN" / ; for 0 1 0 0 public network serving the remote user >> %s"RPN" / ; for 0 1 0 1 private network serving the remote user >> %s"LOC-6" / ; for 0 1 1 0 spare >> %s"INTL" / ; for 0 1 1 1 international network >> %s"LOC-8" / ; for 1 0 0 0 spare >> %s"LOC-9" / ; for 1 0 0 1 spare >> %s"BI" / ; for 1 0 1 0 network beyond interworking point >> %s"LOC-11" / ; for 1 0 1 1 spare >> %s"LOC-12" / ; for 1 1 0 0 reserved for national use >> %s"LOC-13" / ; for 1 1 0 1 reserved for national use >> %s"LOC-14" / ; for 1 1 1 0 reserved for national use >> %s"LOC-15" ; for 1 1 1 1 reserved for national use >> >> Figure 1: isup-cause-location >> NEW: >> reason-extension =/ isup-cause-location >> isup-cause-location = "location" EQUAL isup-location-value >> >> isup-location-value = >> "U" / ; for 0 0 0 0 user >> "LPN" / ; for 0 0 0 1 private network serving the local user >> "LN" / ; for 0 0 1 0 public network serving the local user >> "TN" / ; for 0 0 1 1 transit network >> "RLN" / ; for 0 1 0 0 public network serving the remote user >> "RPN" / ; for 0 1 0 1 private network serving the remote user >> "LOC-6" / ; for 0 1 1 0 spare >> "INTL" / ; for 0 1 1 1 international network >> "LOC-8" / ; for 1 0 0 0 spare >> "LOC-9" / ; for 1 0 0 1 spare >> "BI" / ; for 1 0 1 0 network beyond interworking point >> "LOC-11" / ; for 1 0 1 1 spare >> "LOC-12" / ; for 1 1 0 0 reserved for national use >> "LOC-13" / ; for 1 1 0 1 reserved for national use >> "LOC-14" / ; for 1 1 1 0 reserved for national use >> "LOC-15" ; for 1 1 1 1 reserved for national use >> >> Figure 1: isup-cause-location > --------------1B6893A21F427FAD1CAE149D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
The double-quotes are fine. Your RFC editor note addresses my issue completely. Clearing my discuss now.

/a

On 3/19/19 9:26 PM, Ben Campbell wrote:


On Mar 19, 2019, at 9:20 PM, Ben Campbell <ben@nostrum.com> wrote:



On Mar 19, 2019, at 1:43 PM, Adam Roach <adam@nostrum.com> wrote:

On 3/15/19 1:28 PM, Adam Roach wrote:
On 3/15/19 1:23 PM, Adam Roach wrote:
On 3/11/19 3:23 AM, R.Jesske@telekom.de wrote:
Hi,
Thank you for your comments. I went through the comments and here are my answers and proposals to the comments made.
Sorry If some of you get the mail twice, since I answered in another way already.

1.  Discuss:
§4 ABNF
Have incorporated the proposal.


I'm going to clear my discuss


Based on Paul Kyzivat's comment on the SIPCORE mailing list, I'm going to hold off and talk to Ben before I clear. Sorry for the confusion.


Based on Paul's comment and on Ben's reminder that SIP fields are generally case-insensitive (both on the SIPCORE mailing list), I think the solution here is to simply remove all of the instances of "%s" in the BNF I sent. Sorry for the extra round-trip here.


Like the following? If so, I can drop this into an RFC Editor note:

Or do we also need to remove the double-quotes?


OLD:
reason-extension =/ isup-cause-location
isup-cause-location =  "location" EQUAL isup-location-value

   isup-location-value =
      %s"U" /      ; for 0 0 0 0 user
      %s"LPN" /    ; for 0 0 0 1 private network serving the local user
      %s"LN" /     ; for 0 0 1 0 public network serving the local user
      %s"TN" /     ; for 0 0 1 1 transit network
      %s"RLN" /    ; for 0 1 0 0 public network serving the remote user
      %s"RPN" /    ; for 0 1 0 1 private network serving the remote user
      %s"LOC-6" /  ; for 0 1 1 0 spare
      %s"INTL" /   ; for 0 1 1 1 international network
      %s"LOC-8" /  ; for 1 0 0 0 spare
      %s"LOC-9" /  ; for 1 0 0 1 spare
      %s"BI" /     ; for 1 0 1 0 network beyond interworking point
      %s"LOC-11" / ; for 1 0 1 1 spare
      %s"LOC-12" / ; for 1 1 0 0 reserved for national use
      %s"LOC-13" / ; for 1 1 0 1 reserved for national use
      %s"LOC-14" / ; for 1 1 1 0 reserved for national use
      %s"LOC-15"   ; for 1 1 1 1 reserved for national use

                       Figure 1: isup-cause-location
NEW:
reason-extension =/ isup-cause-location
isup-cause-location =  "location" EQUAL isup-location-value

   isup-location-value =
      "U" /      ; for 0 0 0 0 user
      "LPN" /    ; for 0 0 0 1 private network serving the local user
      "LN" /     ; for 0 0 1 0 public network serving the local user
      "TN" /     ; for 0 0 1 1 transit network
      "RLN" /    ; for 0 1 0 0 public network serving the remote user
      "RPN" /    ; for 0 1 0 1 private network serving the remote user
      "LOC-6" /  ; for 0 1 1 0 spare
      "INTL" /   ; for 0 1 1 1 international network
      "LOC-8" /  ; for 1 0 0 0 spare
      "LOC-9" /  ; for 1 0 0 1 spare
      "BI" /     ; for 1 0 1 0 network beyond interworking point
      "LOC-11" / ; for 1 0 1 1 spare
      "LOC-12" / ; for 1 1 0 0 reserved for national use
      "LOC-13" / ; for 1 1 0 1 reserved for national use
      "LOC-14" / ; for 1 1 1 0 reserved for national use
      "LOC-15"   ; for 1 1 1 1 reserved for national use

                       Figure 1: isup-cause-location


--------------1B6893A21F427FAD1CAE149D-- From nobody Tue Mar 19 20:20:58 2019 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 95FD7130F28; Tue, 19 Mar 2019 20:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 GTEUZ1fZG_ln; Tue, 19 Mar 2019 20:20:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56317130F18; Tue, 19 Mar 2019 20:20:41 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2K3KbsP026416 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Mar 2019 22:20:39 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553052040; bh=fd5ezB2es8Oieyx/evRPo0kX7YjBQTIjKM6d+so3v0Q=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=NqCUlktx/7wHccvomxSgvNJpQLkXwHo5lOPf6/ynv9b2jIfZUJKiexI2s/ZGQPmZ9 uYh+drp0IPmNJZiPI66Yak9LIOlI3SnYSEjh89RdIrY4WHd5DHnTD9fBmHbQtMEGfh CkuPKF2Mx5T1Xvo+PObkX5IcspDEHjKKEcMjAByE= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_5E82669A-40B0-4384-9FDF-EB6E1811E94C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 19 Mar 2019 22:20:31 -0500 In-Reply-To: <0446BC26-28C3-42B7-8DD6-F8D054883DAF@nostrum.com> Cc: =?utf-8?Q?Michael_T=C3=BCxen_via_Datatracker?= , draft-ietf-sipcore-reason-q850-loc@ietf.org, SIPCORE , IESG , sipcore-chairs@ietf.org, Benjamin Kaduk To: "" References: <155193609023.13714.4531517779875308584.idtracker@ietfa.amsl.com> <20190318140358.GB80498@kduck.mit.edu> <0446BC26-28C3-42B7-8DD6-F8D054883DAF@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 03:20:49 -0000 --Apple-Mail=_5E82669A-40B0-4384-9FDF-EB6E1811E94C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Roland. Benjamin tells me the remaining changes are small. Let me see if I can = put them in the form of an RFC Editor note, so we can hopefully avoid a = new revision. Thanks! Ben. > On Mar 19, 2019, at 9:30 PM, Ben Campbell wrote: >=20 > Hi Roland, >=20 > Am I correct to understand that changes based on this discussion have = not yet made it into a draft? If so, when do you think that could = happen? >=20 > Please note that the Plenary in Prague is sort of a deadline for this; = if I am not able approve it before then it will have to transition to = another AD, which could add delays while they come up to speed on it. >=20 > Thanks! >=20 > Ben. >=20 >> On Mar 18, 2019, at 9:03 AM, Benjamin Kaduk wrote: >>=20 >> On Mon, Mar 11, 2019 at 08:20:34AM +0000, R.Jesske@telekom.de wrote: >>> Hi, >>> Thank you for your comments. I went through the comments and >>> here are my answers and proposals to the comments made. >>> Sorry If some of you get the mail twice, since I answered in another = way already. >>=20 >> I do not mind the extra mail, and I must apologize myself for the = slowness >> of the reply. >>=20 >>>=20 >>> Discuss on Section 4 >>> Do you want to see something beyond the Note I put in? >>> Note: These are the values defined within = as location. Thus other values are not within the scope of this = document. >>=20 >> The main thing I wanted to be clarified was that the string name is = the >> actual codepoint used on the wire (as opposed to some encoding of the >> four-bit value). Changing to use ABNF for the specification os >> isup-location-value is sufficient to clarify that point; the only = remaining >> potential issue would be regarding potential future = changes/allocations... >>=20 >>> The last try to change these values in ITU-T was around 2001/2002 = for some mobile network code points. This was rejected since operators = said that there is willingness to change ISUP for such coding points. = The values are stable since 20 years so there will be no change of these = values in future, since invest will go into IP based networks like IMS. >>=20 >> .... and it sounds like the expected chances of any such changes are = very >> low. I would still ask you to consider adding a note to the effect = of >> "Note that the 'LOC=3D*' names are the wire codepoints for the values >> currently left as 'spare' or 'reserved' in [Q.850]; these will = continue to >> be the wire codepoints in the case of future allocation or national >> usage." I am happy to listen to some reasoning about why even that >> statement is not needed, though. >>=20 >> (BTW, given the presence of all 16 possible 4-bit values, I don't = think the >> current Note about "other values are not within the scope" is adding = much >> value, and potentially could be replaced by my suggested note above.) >>=20 >>> Comments on Section 1,3 and 4 >>> Nits on Section 1+3 corrected. >>>=20 >>> Section 4: >>> I try to reformulate the sentence. >>> Proposal: >>>=20 >>> UAC or UAS SHALL include the location parameter in a request or = response when setting up the Reason header field with a [Q.850] cause. = This approach is only possible in cases when the ISUP [Q.850] location = is available. >>=20 >> That helps a lot, thank you. >>=20 >>> If you are OK with these changes I will produce a new draft and = upload it. >>=20 >> That would work, but it's also fine if you want to wait until the = issue >> Adam raised comes to a complete resolution on the list. >>=20 >> Thanks, >>=20 >> Benjamin >>=20 >>> Thank you and Best Regards >>>=20 >>> Roland >>>> -----Urspr=C3=BCngliche Nachricht----- >>>> Von: sipcore Im Auftrag von Datatracker = on >>>> behalf of Benjamin Kaduk >>>> Gesendet: Donnerstag, 7. M=C3=A4rz 2019 06:22 >>>> An: The IESG >>>> Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org; = sipcore-chairs@ietf.org; >>>> sipcore@ietf.org >>>> Betreff: [sipcore] Benjamin Kaduk's Discuss on = draft-ietf-sipcore-reason- >>>> q850-loc-06: (with DISCUSS and COMMENT) >>>>=20 >>>> Benjamin Kaduk has entered the following ballot position for >>>> draft-ietf-sipcore-reason-q850-loc-06: Discuss >>>>=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-reason-q850-loc/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> I support Adam's Discuss. >>>>=20 >>>> I also think that the Section 4 text: >>>>=20 >>>> The use of the location parameter is restricted to Q850 cause = values. >>>> Other values MUST be ignored if present. >>>>=20 >>>> needs to be clear about whether it is intended to limit to the = exact 16 strings >>>> listed above, or whether the intent is to update with Q850 if new = values are >>>> allocated. Are string aliases allowed for the "national-use" = codepoints if >>>> allocated within a given nation? >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> Section 1 >>>>=20 >>>> the reason of release. The reason of release does indicate why a = SIP >>>> Dialog or an PSTN call, in case where the call was interworked to = the >>>>=20 >>>> nits: s/does indicate/indicates/ ; s/an PSTN/a PSTN/ >>>>=20 >>>> Section 3 >>>>=20 >>>> The primary intent of the parameter defined in this specification = is >>>> for use in IMS (IP Multimedia Subsystem) networks defined by 3GPP = but >>>> also open to be used by any other network that includes ISUP >>>>=20 >>>> nit: s/also/it is also/ >>>>=20 >>>> Section 4 >>>>=20 >>>> Depending on whether the message is a request or a response the = UAC >>>> or UAS SHALL include the location parameter when setting up the >>>> Reason header field with a [Q.850] cause. This approach is only >>>> possible in cases when the ISUP [Q.850] location is available. >>>>=20 >>>> I don't understand what depends on whether the message is a request = or a >>>> response. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>=20 >=20 --Apple-Mail=_5E82669A-40B0-4384-9FDF-EB6E1811E94C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlyRsX8ACgkQgFZKbJXz 1A1aRA/8CM8pd0KbfZaTkQzZk8jerdOBJdAk6cfRQdLbvT3FVyIbxCLayiN+oC8G lkJYM2rSFJMfcBIIrzrZxrRF612X2vFPKj0G28MWtBFO/otr0m2Tz2FoMVd6GnCU yRlCjpX7a/EdJf3yjnLN8+rahF2+7xH1Zsc4iXuyNustaVOKK2XuQnt65+M+fG7u 1NjY3wa4S2zFG05IdbSygtfuz25yerccFxLCM0BZvmMx+GCrPIfKHKzKy2CTSsso X3Kk3P+2p4JkrZzxhDKUp6LYCIA4tSY8TEikBgmEcP+G9uzcJ0D0CREcvKXyEzWu gCsG+12wJ6Ak9MPjebARVmELYmFL2tUCFZJctQzU15twmi/BsOlD8qvsiEcIvVIE S6raZhwEnIkxal+7xlWyLDZpGQC5OWB+BqrU9EyDLrxWG6oGF26UTYyv44gB3pDd FWVUP3/hM8bALGLa4vqiLI0Fk1XWfpxV7uCc8NRwSra1U/K148DwRPQq8iPijQO/ gLKAE9fEqkGV/dO19cGMQfFBJ1Rz16GopTAfgrTaL5AdyiZhxlJLzjhzCek0i1OZ hmcj5hlSAko7JYIAoO0K9ZN/sspeH9wJ6iLMvgE7koNOG92x3mz2peKZaOHkDTiG CbcWwJKU7y+ChkoH1sAVEUkIdvzvZdeY5bGU/96jD1H3fdEmvkQ= =8lmc -----END PGP SIGNATURE----- --Apple-Mail=_5E82669A-40B0-4384-9FDF-EB6E1811E94C-- From nobody Wed Mar 20 17:23:37 2019 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 6AF99127917; Wed, 20 Mar 2019 17:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 8S14hIAqeWqz; Wed, 20 Mar 2019 17:23:34 -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 3BFF31275F3; Wed, 20 Mar 2019 17:23:34 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2L0NTUZ032323 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Mar 2019 19:23:31 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553127813; bh=7fTayKsWct70WD11DlxDLa0KyQWpRwOQEDMUuqV95eA=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=wPjVKKPIi5motajsKpAyKRaaC5YJ6hlp0c3Vy7QxzE69Qc3EECO7baMiL0Nn7H0JE zmizWPzgYTDs2CS2zO9AbUHNmPvFlWyypygAD9WKtdobifsMsE9A9Ev89WgqT6W+iR oG1cGGCiq89QbUkWcXJvRPbLuH6hvT/yAQKSFt7E= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_3E63DB91-A88A-41AC-B4A8-E0516BF81A0B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 20 Mar 2019 19:23:24 -0500 In-Reply-To: Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org, sipcore-chairs@ietf.org, =?utf-8?Q?Michael_T=C3=BCxen_via_Datatracker?= , SIPCORE , IESG To: "" , Benjamin Kaduk References: <155193609023.13714.4531517779875308584.idtracker@ietfa.amsl.com> <20190318140358.GB80498@kduck.mit.edu> <0446BC26-28C3-42B7-8DD6-F8D054883DAF@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 00:23:36 -0000 --Apple-Mail=_3E63DB91-A88A-41AC-B4A8-E0516BF81A0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here=E2=80=99s a proposed RFC Editor note to make the changes in section = 4. I made some slight edits for clarity, and a bigger edit to include = the part about the ISUP location being available as a condition of the = SHALL, rather than a separate statement suggesting that the SHALL is not = always possible to follow. Benjamin and Roland, does this work for you? Thanks! Ben. --------------------------------- Please make the following edits to the first two paragraphs following = Figure 1 in Section 4: OLD: Note: These are the values defined within [Q.850] as location. Thus other values are not within the scope of this document. Depending on whether the message is a request or a response the UAC or UAS SHALL include the location parameter when setting up the Reason header field with a [Q.850] cause. This approach is only possible in = cases when the ISUP [Q.850] location is available. NEW: Note: These are the values defined within [Q.850] as location. Thus other values are not within the scope of this document. the 'LOC=3D*' = names are the wire codepoints for the values currently left as 'spare' or = 'reserved=E2=80=99 in [Q.850]; these will continue to be the wire codepoints in the case of = future allocation or national usage of the such values. The UAC or UAS SHALL include the location parameter in a request or = response when setting up the Reason header field with a [Q.850] cause when the ISUP [Q.850] location is available. > On Mar 19, 2019, at 10:20 PM, Ben Campbell wrote: >=20 > Signed PGP part > Hi Roland. >=20 > Benjamin tells me the remaining changes are small. Let me see if I can = put them in the form of an RFC Editor note, so we can hopefully avoid a = new revision. >=20 > Thanks! >=20 > Ben. >=20 >> On Mar 19, 2019, at 9:30 PM, Ben Campbell wrote: >>=20 >> Hi Roland, >>=20 >> Am I correct to understand that changes based on this discussion have = not yet made it into a draft? If so, when do you think that could = happen? >>=20 >> Please note that the Plenary in Prague is sort of a deadline for = this; if I am not able approve it before then it will have to transition = to another AD, which could add delays while they come up to speed on it. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>> On Mar 18, 2019, at 9:03 AM, Benjamin Kaduk wrote: >>>=20 >>> On Mon, Mar 11, 2019 at 08:20:34AM +0000, R.Jesske@telekom.de wrote: >>>> Hi, >>>> Thank you for your comments. I went through the comments and >>>> here are my answers and proposals to the comments made. >>>> Sorry If some of you get the mail twice, since I answered in = another way already. >>>=20 >>> I do not mind the extra mail, and I must apologize myself for the = slowness >>> of the reply. >>>=20 >>>>=20 >>>> Discuss on Section 4 >>>> Do you want to see something beyond the Note I put in? >>>> Note: These are the values defined within = as location. Thus other values are not within the scope of this = document. >>>=20 >>> The main thing I wanted to be clarified was that the string name is = the >>> actual codepoint used on the wire (as opposed to some encoding of = the >>> four-bit value). Changing to use ABNF for the specification os >>> isup-location-value is sufficient to clarify that point; the only = remaining >>> potential issue would be regarding potential future = changes/allocations... >>>=20 >>>> The last try to change these values in ITU-T was around 2001/2002 = for some mobile network code points. This was rejected since operators = said that there is willingness to change ISUP for such coding points. = The values are stable since 20 years so there will be no change of these = values in future, since invest will go into IP based networks like IMS. >>>=20 >>> .... and it sounds like the expected chances of any such changes are = very >>> low. I would still ask you to consider adding a note to the effect = of >>> "Note that the 'LOC=3D*' names are the wire codepoints for the = values >>> currently left as 'spare' or 'reserved' in [Q.850]; these will = continue to >>> be the wire codepoints in the case of future allocation or national >>> usage." I am happy to listen to some reasoning about why even that >>> statement is not needed, though. >>>=20 >>> (BTW, given the presence of all 16 possible 4-bit values, I don't = think the >>> current Note about "other values are not within the scope" is adding = much >>> value, and potentially could be replaced by my suggested note = above.) >>>=20 >>>> Comments on Section 1,3 and 4 >>>> Nits on Section 1+3 corrected. >>>>=20 >>>> Section 4: >>>> I try to reformulate the sentence. >>>> Proposal: >>>>=20 >>>> UAC or UAS SHALL include the location parameter in a request or = response when setting up the Reason header field with a [Q.850] cause. = This approach is only possible in cases when the ISUP [Q.850] location = is available. >>>=20 >>> That helps a lot, thank you. >>>=20 >>>> If you are OK with these changes I will produce a new draft and = upload it. >>>=20 >>> That would work, but it's also fine if you want to wait until the = issue >>> Adam raised comes to a complete resolution on the list. >>>=20 >>> Thanks, >>>=20 >>> Benjamin >>>=20 >>>> Thank you and Best Regards >>>>=20 >>>> Roland >>>>> -----Urspr=C3=BCngliche Nachricht----- >>>>> Von: sipcore Im Auftrag von Datatracker = on >>>>> behalf of Benjamin Kaduk >>>>> Gesendet: Donnerstag, 7. M=C3=A4rz 2019 06:22 >>>>> An: The IESG >>>>> Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org; = sipcore-chairs@ietf.org; >>>>> sipcore@ietf.org >>>>> Betreff: [sipcore] Benjamin Kaduk's Discuss on = draft-ietf-sipcore-reason- >>>>> q850-loc-06: (with DISCUSS and COMMENT) >>>>>=20 >>>>> Benjamin Kaduk has entered the following ballot position for >>>>> draft-ietf-sipcore-reason-q850-loc-06: Discuss >>>>>=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-reason-q850-loc/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> I support Adam's Discuss. >>>>>=20 >>>>> I also think that the Section 4 text: >>>>>=20 >>>>> The use of the location parameter is restricted to Q850 cause = values. >>>>> Other values MUST be ignored if present. >>>>>=20 >>>>> needs to be clear about whether it is intended to limit to the = exact 16 strings >>>>> listed above, or whether the intent is to update with Q850 if new = values are >>>>> allocated. Are string aliases allowed for the "national-use" = codepoints if >>>>> allocated within a given nation? >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> Section 1 >>>>>=20 >>>>> the reason of release. The reason of release does indicate why a = SIP >>>>> Dialog or an PSTN call, in case where the call was interworked to = the >>>>>=20 >>>>> nits: s/does indicate/indicates/ ; s/an PSTN/a PSTN/ >>>>>=20 >>>>> Section 3 >>>>>=20 >>>>> The primary intent of the parameter defined in this specification = is >>>>> for use in IMS (IP Multimedia Subsystem) networks defined by 3GPP = but >>>>> also open to be used by any other network that includes ISUP >>>>>=20 >>>>> nit: s/also/it is also/ >>>>>=20 >>>>> Section 4 >>>>>=20 >>>>> Depending on whether the message is a request or a response the = UAC >>>>> or UAS SHALL include the location parameter when setting up the >>>>> Reason header field with a [Q.850] cause. This approach is only >>>>> possible in cases when the ISUP [Q.850] location is available. >>>>>=20 >>>>> I don't understand what depends on whether the message is a = request or a >>>>> response. >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>=20 >>>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_3E63DB91-A88A-41AC-B4A8-E0516BF81A0B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlyS2XwACgkQgFZKbJXz 1A0CsA/+MVAxuP2rpA1YJyQXsqRIaw3E7Z+nFhFdBgqDngh8lzL2p3y1NAHqB0ct fPJTvzYZSplPUKuAGCO7BF1KER0Vkw0VW+f2XZCwGi69rSs7deaked4LBqORhgtG JAZVAaYytgmoD0VqLc16FoyquGKSpj6EsSoAybvLyEIZgklYPuUSyRfb133EBSSb OJzfO41rgDtl9wuctfU4pWS3ui/aA0ufTuZ/zvh6T6QY7BgwmPpsqIQ/wBuGisow KyUmp6lV3n/fw8Ew1TQVlWG2f5GkfbA2GBwt/jy7EA98A+gxf1iJUNl+W7v6tVaW k0BsOe3If4vMCf5Q5E6QX1gf0yGPJPdaOUwuDbPtr5vonPUMJO2GGrUnQECqksJm vMMpnvjmgSdtoHrlyxA/W0vRDU0ImX15+oUf6uGWE7X/bhKlqr2qDSCFzkhb9zhj dUH4COLxaMr4GzIZTubT9V6szfRX7uxy6uIahdVn55oOO7ZnoHKzrpORNsme0IJ2 M5eCSe9svkyuMHz+417/g/su+San3wkY3hBr7q6cNoLjWwmHHu4dvWyTfCBfVF+X xevsNpzvxGJvoEJmNDFajze8E7OQTZNG+KJv7mLJe89b3FLpEWS0DU+iqHBuybSv yth2wLnq6ykjaGCKe2lshJVCueUcu3nId4N4Eu4CITCpWBFsmno= =RLWf -----END PGP SIGNATURE----- --Apple-Mail=_3E63DB91-A88A-41AC-B4A8-E0516BF81A0B-- From nobody Wed Mar 20 17:44:08 2019 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 AC4CC12DF71; Wed, 20 Mar 2019 17:44:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 iVRb6O0mIOiB; Wed, 20 Mar 2019 17:44:03 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 CD449129A85; Wed, 20 Mar 2019 17:44:02 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2L0hvq1010938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Mar 2019 20:43:59 -0400 Date: Wed, 20 Mar 2019 19:43:57 -0500 From: Benjamin Kaduk To: Ben Campbell Cc: "" , draft-ietf-sipcore-reason-q850-loc@ietf.org, sipcore-chairs@ietf.org, Michael =?iso-8859-1?Q?T=FCxen?= via Datatracker , SIPCORE , IESG Message-ID: <20190321004356.GP80498@kduck.mit.edu> References: <155193609023.13714.4531517779875308584.idtracker@ietfa.amsl.com> <20190318140358.GB80498@kduck.mit.edu> <0446BC26-28C3-42B7-8DD6-F8D054883DAF@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 00:44:07 -0000 On Wed, Mar 20, 2019 at 07:23:24PM -0500, Ben Campbell wrote: > Here’s a proposed RFC Editor note to make the changes in section 4. I made some slight edits for clarity, and a bigger edit to include the part about the ISUP location being available as a condition of the SHALL, rather than a separate statement suggesting that the SHALL is not always possible to follow. > > Benjamin and Roland, does this work for you? Modulo typos (inline), I can clear my Discuss for that text. -Benjamin > Thanks! > > Ben. > > --------------------------------- > > Please make the following edits to the first two paragraphs following Figure 1 in > Section 4: > > OLD: > Note: These are the values defined within [Q.850] as location. Thus > other values are not within the scope of this document. > > Depending on whether the message is a request or a response the UAC > or UAS SHALL include the location parameter when setting up the Reason > header field with a [Q.850] cause. This approach is only possible in cases > when the ISUP [Q.850] location is available. > > NEW: > Note: These are the values defined within [Q.850] as location. Thus > other values are not within the scope of this document. the 'LOC=*' names I feel like this was probably my typo originally, but capital "The" and a hyphen in "LOC-*" (not equals). I still am not clear that "other values are not within the scope of this document" is saying anything helpful, but that's not a blocking comment. > are the wire codepoints for the values currently left as 'spare' or 'reserved’ > in [Q.850]; these will continue to be the wire codepoints in the case of future > allocation or national usage of the such values. > > The UAC or UAS SHALL include the location parameter in a request or response > when setting up the Reason header field with a [Q.850] cause when the > ISUP [Q.850] location is available. > > > > On Mar 19, 2019, at 10:20 PM, Ben Campbell wrote: > > > > Signed PGP part > > Hi Roland. > > > > Benjamin tells me the remaining changes are small. Let me see if I can put them in the form of an RFC Editor note, so we can hopefully avoid a new revision. > > > > Thanks! > > > > Ben. > > > >> On Mar 19, 2019, at 9:30 PM, Ben Campbell wrote: > >> > >> Hi Roland, > >> > >> Am I correct to understand that changes based on this discussion have not yet made it into a draft? If so, when do you think that could happen? > >> > >> Please note that the Plenary in Prague is sort of a deadline for this; if I am not able approve it before then it will have to transition to another AD, which could add delays while they come up to speed on it. > >> > >> Thanks! > >> > >> Ben. > >> > >>> On Mar 18, 2019, at 9:03 AM, Benjamin Kaduk wrote: > >>> > >>> On Mon, Mar 11, 2019 at 08:20:34AM +0000, R.Jesske@telekom.de wrote: > >>>> Hi, > >>>> Thank you for your comments. I went through the comments and > >>>> here are my answers and proposals to the comments made. > >>>> Sorry If some of you get the mail twice, since I answered in another way already. > >>> > >>> I do not mind the extra mail, and I must apologize myself for the slowness > >>> of the reply. > >>> > >>>> > >>>> Discuss on Section 4 > >>>> Do you want to see something beyond the Note I put in? > >>>> Note: These are the values defined within as location. Thus other values are not within the scope of this document. > >>> > >>> The main thing I wanted to be clarified was that the string name is the > >>> actual codepoint used on the wire (as opposed to some encoding of the > >>> four-bit value). Changing to use ABNF for the specification os > >>> isup-location-value is sufficient to clarify that point; the only remaining > >>> potential issue would be regarding potential future changes/allocations... > >>> > >>>> The last try to change these values in ITU-T was around 2001/2002 for some mobile network code points. This was rejected since operators said that there is willingness to change ISUP for such coding points. The values are stable since 20 years so there will be no change of these values in future, since invest will go into IP based networks like IMS. > >>> > >>> .... and it sounds like the expected chances of any such changes are very > >>> low. I would still ask you to consider adding a note to the effect of > >>> "Note that the 'LOC=*' names are the wire codepoints for the values > >>> currently left as 'spare' or 'reserved' in [Q.850]; these will continue to > >>> be the wire codepoints in the case of future allocation or national > >>> usage." I am happy to listen to some reasoning about why even that > >>> statement is not needed, though. > >>> > >>> (BTW, given the presence of all 16 possible 4-bit values, I don't think the > >>> current Note about "other values are not within the scope" is adding much > >>> value, and potentially could be replaced by my suggested note above.) > >>> > >>>> Comments on Section 1,3 and 4 > >>>> Nits on Section 1+3 corrected. > >>>> > >>>> Section 4: > >>>> I try to reformulate the sentence. > >>>> Proposal: > >>>> > >>>> UAC or UAS SHALL include the location parameter in a request or response when setting up the Reason header field with a [Q.850] cause. This approach is only possible in cases when the ISUP [Q.850] location is available. > >>> > >>> That helps a lot, thank you. > >>> > >>>> If you are OK with these changes I will produce a new draft and upload it. > >>> > >>> That would work, but it's also fine if you want to wait until the issue > >>> Adam raised comes to a complete resolution on the list. > >>> > >>> Thanks, > >>> > >>> Benjamin > >>> > >>>> Thank you and Best Regards > >>>> > >>>> Roland > >>>>> -----Ursprüngliche Nachricht----- > >>>>> Von: sipcore Im Auftrag von Datatracker on > >>>>> behalf of Benjamin Kaduk > >>>>> Gesendet: Donnerstag, 7. März 2019 06:22 > >>>>> An: The IESG > >>>>> Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org; sipcore-chairs@ietf.org; > >>>>> sipcore@ietf.org > >>>>> Betreff: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason- > >>>>> q850-loc-06: (with DISCUSS and COMMENT) > >>>>> > >>>>> Benjamin Kaduk has entered the following ballot position for > >>>>> draft-ietf-sipcore-reason-q850-loc-06: 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-reason-q850-loc/ > >>>>> > >>>>> > >>>>> > >>>>> ---------------------------------------------------------------------- > >>>>> DISCUSS: > >>>>> ---------------------------------------------------------------------- > >>>>> > >>>>> I support Adam's Discuss. > >>>>> > >>>>> I also think that the Section 4 text: > >>>>> > >>>>> The use of the location parameter is restricted to Q850 cause values. > >>>>> Other values MUST be ignored if present. > >>>>> > >>>>> needs to be clear about whether it is intended to limit to the exact 16 strings > >>>>> listed above, or whether the intent is to update with Q850 if new values are > >>>>> allocated. Are string aliases allowed for the "national-use" codepoints if > >>>>> allocated within a given nation? > >>>>> > >>>>> > >>>>> ---------------------------------------------------------------------- > >>>>> COMMENT: > >>>>> ---------------------------------------------------------------------- > >>>>> > >>>>> Section 1 > >>>>> > >>>>> the reason of release. The reason of release does indicate why a SIP > >>>>> Dialog or an PSTN call, in case where the call was interworked to the > >>>>> > >>>>> nits: s/does indicate/indicates/ ; s/an PSTN/a PSTN/ > >>>>> > >>>>> Section 3 > >>>>> > >>>>> The primary intent of the parameter defined in this specification is > >>>>> for use in IMS (IP Multimedia Subsystem) networks defined by 3GPP but > >>>>> also open to be used by any other network that includes ISUP > >>>>> > >>>>> nit: s/also/it is also/ > >>>>> > >>>>> Section 4 > >>>>> > >>>>> Depending on whether the message is a request or a response the UAC > >>>>> or UAS SHALL include the location parameter when setting up the > >>>>> Reason header field with a [Q.850] cause. This approach is only > >>>>> possible in cases when the ISUP [Q.850] location is available. > >>>>> > >>>>> I don't understand what depends on whether the message is a request or a > >>>>> response. > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> sipcore mailing list > >>>>> sipcore@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>> > >>> > >> > > > > > > > From nobody Wed Mar 20 17:47:39 2019 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 AF3CF130DEA; Wed, 20 Mar 2019 17:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 BzvRu9vuL6FS; Wed, 20 Mar 2019 17:47: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 36A2512D861; Wed, 20 Mar 2019 17:47:36 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2L0lWmW036206 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Mar 2019 19:47:34 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553129255; bh=dW9WXIiNPtPHstHY7ZhUS5RQJUZ5lQQERUHyN1wi6yg=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=d0aEG4F9iqgpki4jjUei9GTyEy5OREdNZYaHakPmq51fZdV69tkKk+PLGYdrBFSmX +cvRB0W2jHFd16b1/vIGY5WwnBJVV0cuIDPk2mGiGGf8Q//pXn1jo/if90IWGkPeqG AvpE4U+d6rB11RpLFmphMoxxLOQlVUHQ7ZM4Tal4= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_5B0E3301-458E-4FA5-8FE1-26931F3E0E4F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 20 Mar 2019 19:47:26 -0500 In-Reply-To: <20190321004356.GP80498@kduck.mit.edu> Cc: "" , draft-ietf-sipcore-reason-q850-loc@ietf.org, sipcore-chairs@ietf.org, =?utf-8?Q?Michael_T=C3=BCxen_via_Datatracker?= , SIPCORE , IESG To: Benjamin Kaduk References: <155193609023.13714.4531517779875308584.idtracker@ietfa.amsl.com> <20190318140358.GB80498@kduck.mit.edu> <0446BC26-28C3-42B7-8DD6-F8D054883DAF@nostrum.com> <20190321004356.GP80498@kduck.mit.edu> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 00:47:38 -0000 --Apple-Mail=_5B0E3301-458E-4FA5-8FE1-26931F3E0E4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 20, 2019, at 7:43 PM, Benjamin Kaduk wrote: >=20 > On Wed, Mar 20, 2019 at 07:23:24PM -0500, Ben Campbell wrote: >> Here=E2=80=99s a proposed RFC Editor note to make the changes in = section 4. I made some slight edits for clarity, and a bigger edit to = include the part about the ISUP location being available as a condition = of the SHALL, rather than a separate statement suggesting that the SHALL = is not always possible to follow. >>=20 >> Benjamin and Roland, does this work for you? >=20 > Modulo typos (inline), I can clear my Discuss for that text. >=20 > -Benjamin >=20 >> Thanks! >>=20 >> Ben. >>=20 >> --------------------------------- >>=20 >> Please make the following edits to the first two paragraphs following = Figure 1 in >> Section 4: >>=20 >> OLD: >> Note: These are the values defined within [Q.850] as location. Thus >> other values are not within the scope of this document. >>=20 >> Depending on whether the message is a request or a response the UAC >> or UAS SHALL include the location parameter when setting up the = Reason >> header field with a [Q.850] cause. This approach is only possible in = cases >> when the ISUP [Q.850] location is available. >>=20 >> NEW: >> Note: These are the values defined within [Q.850] as location. Thus >> other values are not within the scope of this document. the 'LOC=3D*' = names >=20 > I feel like this was probably my typo originally, but capital "The" = and a > hyphen in "LOC-*" (not equals). will fix in the actual note. >=20 > I still am not clear that "other values are not within the scope of = this > document" is saying anything helpful, but that's not a blocking = comment. On reflection, I agree with you. I think it wants to say =E2=80=9Cother = values are not possible=E2=80=9D or something to that effect, but it=E2=80= =99s not necessary either way. >=20 >> are the wire codepoints for the values currently left as 'spare' or = 'reserved=E2=80=99 >> in [Q.850]; these will continue to be the wire codepoints in the case = of future >> allocation or national usage of the such values. >>=20 >> The UAC or UAS SHALL include the location parameter in a request or = response >> when setting up the Reason header field with a [Q.850] cause when the >> ISUP [Q.850] location is available. >>=20 >>=20 >>> On Mar 19, 2019, at 10:20 PM, Ben Campbell wrote: >>>=20 >>> Signed PGP part >>> Hi Roland. >>>=20 >>> Benjamin tells me the remaining changes are small. Let me see if I = can put them in the form of an RFC Editor note, so we can hopefully = avoid a new revision. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>>=20 >>>> On Mar 19, 2019, at 9:30 PM, Ben Campbell wrote: >>>>=20 >>>> Hi Roland, >>>>=20 >>>> Am I correct to understand that changes based on this discussion = have not yet made it into a draft? If so, when do you think that could = happen? >>>>=20 >>>> Please note that the Plenary in Prague is sort of a deadline for = this; if I am not able approve it before then it will have to transition = to another AD, which could add delays while they come up to speed on it. >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>>=20 >>>>> On Mar 18, 2019, at 9:03 AM, Benjamin Kaduk wrote: >>>>>=20 >>>>> On Mon, Mar 11, 2019 at 08:20:34AM +0000, R.Jesske@telekom.de = wrote: >>>>>> Hi, >>>>>> Thank you for your comments. I went through the comments and >>>>>> here are my answers and proposals to the comments made. >>>>>> Sorry If some of you get the mail twice, since I answered in = another way already. >>>>>=20 >>>>> I do not mind the extra mail, and I must apologize myself for the = slowness >>>>> of the reply. >>>>>=20 >>>>>>=20 >>>>>> Discuss on Section 4 >>>>>> Do you want to see something beyond the Note I put in? >>>>>> Note: These are the values defined within = as location. Thus other values are not within the scope of this = document. >>>>>=20 >>>>> The main thing I wanted to be clarified was that the string name = is the >>>>> actual codepoint used on the wire (as opposed to some encoding of = the >>>>> four-bit value). Changing to use ABNF for the specification os >>>>> isup-location-value is sufficient to clarify that point; the only = remaining >>>>> potential issue would be regarding potential future = changes/allocations... >>>>>=20 >>>>>> The last try to change these values in ITU-T was around 2001/2002 = for some mobile network code points. This was rejected since operators = said that there is willingness to change ISUP for such coding points. = The values are stable since 20 years so there will be no change of these = values in future, since invest will go into IP based networks like IMS. >>>>>=20 >>>>> .... and it sounds like the expected chances of any such changes = are very >>>>> low. I would still ask you to consider adding a note to the = effect of >>>>> "Note that the 'LOC=3D*' names are the wire codepoints for the = values >>>>> currently left as 'spare' or 'reserved' in [Q.850]; these will = continue to >>>>> be the wire codepoints in the case of future allocation or = national >>>>> usage." I am happy to listen to some reasoning about why even = that >>>>> statement is not needed, though. >>>>>=20 >>>>> (BTW, given the presence of all 16 possible 4-bit values, I don't = think the >>>>> current Note about "other values are not within the scope" is = adding much >>>>> value, and potentially could be replaced by my suggested note = above.) >>>>>=20 >>>>>> Comments on Section 1,3 and 4 >>>>>> Nits on Section 1+3 corrected. >>>>>>=20 >>>>>> Section 4: >>>>>> I try to reformulate the sentence. >>>>>> Proposal: >>>>>>=20 >>>>>> UAC or UAS SHALL include the location parameter in a request or = response when setting up the Reason header field with a [Q.850] cause. = This approach is only possible in cases when the ISUP [Q.850] location = is available. >>>>>=20 >>>>> That helps a lot, thank you. >>>>>=20 >>>>>> If you are OK with these changes I will produce a new draft and = upload it. >>>>>=20 >>>>> That would work, but it's also fine if you want to wait until the = issue >>>>> Adam raised comes to a complete resolution on the list. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Benjamin >>>>>=20 >>>>>> Thank you and Best Regards >>>>>>=20 >>>>>> Roland >>>>>>> -----Urspr=C3=BCngliche Nachricht----- >>>>>>> Von: sipcore Im Auftrag von = Datatracker on >>>>>>> behalf of Benjamin Kaduk >>>>>>> Gesendet: Donnerstag, 7. M=C3=A4rz 2019 06:22 >>>>>>> An: The IESG >>>>>>> Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org; = sipcore-chairs@ietf.org; >>>>>>> sipcore@ietf.org >>>>>>> Betreff: [sipcore] Benjamin Kaduk's Discuss on = draft-ietf-sipcore-reason- >>>>>>> q850-loc-06: (with DISCUSS and COMMENT) >>>>>>>=20 >>>>>>> Benjamin Kaduk has entered the following ballot position for >>>>>>> draft-ietf-sipcore-reason-q850-loc-06: Discuss >>>>>>>=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-reason-q850-loc/ >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> = ---------------------------------------------------------------------- >>>>>>> DISCUSS: >>>>>>> = ---------------------------------------------------------------------- >>>>>>>=20 >>>>>>> I support Adam's Discuss. >>>>>>>=20 >>>>>>> I also think that the Section 4 text: >>>>>>>=20 >>>>>>> The use of the location parameter is restricted to Q850 cause = values. >>>>>>> Other values MUST be ignored if present. >>>>>>>=20 >>>>>>> needs to be clear about whether it is intended to limit to the = exact 16 strings >>>>>>> listed above, or whether the intent is to update with Q850 if = new values are >>>>>>> allocated. Are string aliases allowed for the "national-use" = codepoints if >>>>>>> allocated within a given nation? >>>>>>>=20 >>>>>>>=20 >>>>>>> = ---------------------------------------------------------------------- >>>>>>> COMMENT: >>>>>>> = ---------------------------------------------------------------------- >>>>>>>=20 >>>>>>> Section 1 >>>>>>>=20 >>>>>>> the reason of release. The reason of release does indicate why = a SIP >>>>>>> Dialog or an PSTN call, in case where the call was interworked = to the >>>>>>>=20 >>>>>>> nits: s/does indicate/indicates/ ; s/an PSTN/a PSTN/ >>>>>>>=20 >>>>>>> Section 3 >>>>>>>=20 >>>>>>> The primary intent of the parameter defined in this = specification is >>>>>>> for use in IMS (IP Multimedia Subsystem) networks defined by = 3GPP but >>>>>>> also open to be used by any other network that includes ISUP >>>>>>>=20 >>>>>>> nit: s/also/it is also/ >>>>>>>=20 >>>>>>> Section 4 >>>>>>>=20 >>>>>>> Depending on whether the message is a request or a response the = UAC >>>>>>> or UAS SHALL include the location parameter when setting up the >>>>>>> Reason header field with a [Q.850] cause. This approach is only >>>>>>> possible in cases when the ISUP [Q.850] location is available. >>>>>>>=20 >>>>>>> I don't understand what depends on whether the message is a = request or a >>>>>>> response. >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 --Apple-Mail=_5B0E3301-458E-4FA5-8FE1-26931F3E0E4F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlyS3x4ACgkQgFZKbJXz 1A0dJw//ZrWJGiir8iEIgWYeoDiyoNBYxqqHVbbEzaAwf47bEtssbfluoxGRghpp s5fLCLIwF6+BXRcgUlHYxfCjAxGcxH9hDjcmi1ivLg9R67W1w7Pit4X42aDNwoDn PqkBfHrrBaZSL5sqnhcrcd4dYOcH/2ZHnY8Pd92o4uKXk+OGPhtkfEKfGnawEUbV NO5pRqVPq88c2KeY7qs22e/ehrax6jRJbID/SvM/lI6fzU8GVO9nKpa/LkS2EFGn qa9Y1kTKe50zYSP1fYRffWm3enKOKbckjwOD6CaT1NsIcvci0O67wyiERj7uGetY eDcM+4uklbghpzyHj1jPJjOYTmg7OnxdMSEAI5cO8l99At1ejXyeTG7DKiPwyVPv J6ElEoRiuQjSWfG34BIGobw4ta41Uq5nwJnoYSnQTs+v71y30Dds4GSFyz3EZMKq sHmbocDl4tQyEItX4bNd8F3a+mgEHWFykuqwxAYdEk/dLUtzeGP3WsB/xUpuGRXf uyuDKWxeyqiachMneqndpwRTxf2y4JqrOeh52IwM73VtH73TLwFjPcoHjzxx2Bt5 SoMfJR9RguQYrKrK9ZKocyAXKA0xHtr5UaJER4bJirlOtrEQrf1d2tcaodYT3DqG r6woY0SY5MBEjZePgn+NaOoVGDT8rHcudjWgwWYaGOw08lQYNzE= =i9sI -----END PGP SIGNATURE----- --Apple-Mail=_5B0E3301-458E-4FA5-8FE1-26931F3E0E4F-- From nobody Wed Mar 20 17:55:41 2019 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 F2C22130DEF; Wed, 20 Mar 2019 17:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 p5XG9ydQTApa; Wed, 20 Mar 2019 17:55:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021DB1310F0; Wed, 20 Mar 2019 17:55:29 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2L0tQiC037555 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Mar 2019 19:55:27 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553129729; bh=+H22CEX+/cx7c91wj8iDge1VPsYUM4g4ahh4BTrT97M=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=rp2Hy6aOIfey3Dk6Yo3wjmXABkBkaKJiQ17msuJnxEjNUejdLHYVE0CB/S5Lk+y3+ HbhdYrbVuMjKRRPrdci9JoL5sOl6xxzQVtivzCyY7xBXbVdtuXqW20cPJsk1SeRfFi iAOSsDaAwC+ok/Cg2sJ9wpMgQXWplwzvdze6tdzA= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_BDB9E8C2-4E74-4EAC-B4E5-F30AF84DDAC0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 20 Mar 2019 19:55:20 -0500 In-Reply-To: Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org, sipcore-chairs@ietf.org, =?utf-8?Q?Michael_T=C3=BCxen_via_Datatracker?= , SIPCORE , "" , IESG To: Benjamin Kaduk References: <155193609023.13714.4531517779875308584.idtracker@ietfa.amsl.com> <20190318140358.GB80498@kduck.mit.edu> <0446BC26-28C3-42B7-8DD6-F8D054883DAF@nostrum.com> <20190321004356.GP80498@kduck.mit.edu> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 00:55:40 -0000 --Apple-Mail=_BDB9E8C2-4E74-4EAC-B4E5-F30AF84DDAC0 Content-Type: multipart/alternative; boundary="Apple-Mail=_D280D559-6C99-4E9B-B6A6-FBD576E746BE" --Apple-Mail=_D280D559-6C99-4E9B-B6A6-FBD576E746BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The RFC editor note for Benjamin=E2=80=99s and Adam=E2=80=99s points is = in place at = https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/writeu= p/ You may need to scroll down. Thanks! Ben. > On Mar 20, 2019, at 7:47 PM, Ben Campbell wrote: >=20 >=20 >=20 >> On Mar 20, 2019, at 7:43 PM, Benjamin Kaduk wrote: >>=20 >> On Wed, Mar 20, 2019 at 07:23:24PM -0500, Ben Campbell wrote: >>> Here=E2=80=99s a proposed RFC Editor note to make the changes in = section 4. I made some slight edits for clarity, and a bigger edit to = include the part about the ISUP location being available as a condition = of the SHALL, rather than a separate statement suggesting that the SHALL = is not always possible to follow. >>>=20 >>> Benjamin and Roland, does this work for you? >>=20 >> Modulo typos (inline), I can clear my Discuss for that text. >>=20 >> -Benjamin >>=20 >>> Thanks! >>>=20 >>> Ben. >>>=20 >>> --------------------------------- >>>=20 >>> Please make the following edits to the first two paragraphs = following Figure 1 in >>> Section 4: >>>=20 >>> OLD: >>> Note: These are the values defined within [Q.850] as location. Thus >>> other values are not within the scope of this document. >>>=20 >>> Depending on whether the message is a request or a response the UAC >>> or UAS SHALL include the location parameter when setting up the = Reason >>> header field with a [Q.850] cause. This approach is only possible = in cases >>> when the ISUP [Q.850] location is available. >>>=20 >>> NEW: >>> Note: These are the values defined within [Q.850] as location. Thus >>> other values are not within the scope of this document. the 'LOC=3D*' = names >>=20 >> I feel like this was probably my typo originally, but capital "The" = and a >> hyphen in "LOC-*" (not equals). >=20 > will fix in the actual note. >=20 >>=20 >> I still am not clear that "other values are not within the scope of = this >> document" is saying anything helpful, but that's not a blocking = comment. >=20 > On reflection, I agree with you. I think it wants to say =E2=80=9Cother = values are not possible=E2=80=9D or something to that effect, but it=E2=80= =99s not necessary either way. >=20 >>=20 >>> are the wire codepoints for the values currently left as 'spare' or = 'reserved=E2=80=99 >>> in [Q.850]; these will continue to be the wire codepoints in the = case of future >>> allocation or national usage of the such values. >>>=20 >>> The UAC or UAS SHALL include the location parameter in a request or = response >>> when setting up the Reason header field with a [Q.850] cause when = the >>> ISUP [Q.850] location is available. >>>=20 >>>=20 >>>> On Mar 19, 2019, at 10:20 PM, Ben Campbell wrote: >>>>=20 >>>> Signed PGP part >>>> Hi Roland. >>>>=20 >>>> Benjamin tells me the remaining changes are small. Let me see if I = can put them in the form of an RFC Editor note, so we can hopefully = avoid a new revision. >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>>=20 >>>>> On Mar 19, 2019, at 9:30 PM, Ben Campbell wrote: >>>>>=20 >>>>> Hi Roland, >>>>>=20 >>>>> Am I correct to understand that changes based on this discussion = have not yet made it into a draft? If so, when do you think that could = happen? >>>>>=20 >>>>> Please note that the Plenary in Prague is sort of a deadline for = this; if I am not able approve it before then it will have to transition = to another AD, which could add delays while they come up to speed on it. >>>>>=20 >>>>> Thanks! >>>>>=20 >>>>> Ben. >>>>>=20 >>>>>> On Mar 18, 2019, at 9:03 AM, Benjamin Kaduk = wrote: >>>>>>=20 >>>>>> On Mon, Mar 11, 2019 at 08:20:34AM +0000, R.Jesske@telekom.de = wrote: >>>>>>> Hi, >>>>>>> Thank you for your comments. I went through the comments and >>>>>>> here are my answers and proposals to the comments made. >>>>>>> Sorry If some of you get the mail twice, since I answered in = another way already. >>>>>>=20 >>>>>> I do not mind the extra mail, and I must apologize myself for the = slowness >>>>>> of the reply. >>>>>>=20 >>>>>>>=20 >>>>>>> Discuss on Section 4 >>>>>>> Do you want to see something beyond the Note I put in? >>>>>>> Note: These are the values defined within as location. Thus other values are not within the = scope of this document. >>>>>>=20 >>>>>> The main thing I wanted to be clarified was that the string name = is the >>>>>> actual codepoint used on the wire (as opposed to some encoding of = the >>>>>> four-bit value). Changing to use ABNF for the specification os >>>>>> isup-location-value is sufficient to clarify that point; the only = remaining >>>>>> potential issue would be regarding potential future = changes/allocations... >>>>>>=20 >>>>>>> The last try to change these values in ITU-T was around = 2001/2002 for some mobile network code points. This was rejected since = operators said that there is willingness to change ISUP for such coding = points. The values are stable since 20 years so there will be no change = of these values in future, since invest will go into IP based networks = like IMS. >>>>>>=20 >>>>>> .... and it sounds like the expected chances of any such changes = are very >>>>>> low. I would still ask you to consider adding a note to the = effect of >>>>>> "Note that the 'LOC=3D*' names are the wire codepoints for the = values >>>>>> currently left as 'spare' or 'reserved' in [Q.850]; these will = continue to >>>>>> be the wire codepoints in the case of future allocation or = national >>>>>> usage." I am happy to listen to some reasoning about why even = that >>>>>> statement is not needed, though. >>>>>>=20 >>>>>> (BTW, given the presence of all 16 possible 4-bit values, I don't = think the >>>>>> current Note about "other values are not within the scope" is = adding much >>>>>> value, and potentially could be replaced by my suggested note = above.) >>>>>>=20 >>>>>>> Comments on Section 1,3 and 4 >>>>>>> Nits on Section 1+3 corrected. >>>>>>>=20 >>>>>>> Section 4: >>>>>>> I try to reformulate the sentence. >>>>>>> Proposal: >>>>>>>=20 >>>>>>> UAC or UAS SHALL include the location parameter in a request or = response when setting up the Reason header field with a [Q.850] cause. = This approach is only possible in cases when the ISUP [Q.850] location = is available. >>>>>>=20 >>>>>> That helps a lot, thank you. >>>>>>=20 >>>>>>> If you are OK with these changes I will produce a new draft and = upload it. >>>>>>=20 >>>>>> That would work, but it's also fine if you want to wait until the = issue >>>>>> Adam raised comes to a complete resolution on the list. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Benjamin >>>>>>=20 >>>>>>> Thank you and Best Regards >>>>>>>=20 >>>>>>> Roland >>>>>>>> -----Urspr=C3=BCngliche Nachricht----- >>>>>>>> Von: sipcore Im Auftrag von = Datatracker on >>>>>>>> behalf of Benjamin Kaduk >>>>>>>> Gesendet: Donnerstag, 7. M=C3=A4rz 2019 06:22 >>>>>>>> An: The IESG >>>>>>>> Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org; = sipcore-chairs@ietf.org; >>>>>>>> sipcore@ietf.org >>>>>>>> Betreff: [sipcore] Benjamin Kaduk's Discuss on = draft-ietf-sipcore-reason- >>>>>>>> q850-loc-06: (with DISCUSS and COMMENT) >>>>>>>>=20 >>>>>>>> Benjamin Kaduk has entered the following ballot position for >>>>>>>> draft-ietf-sipcore-reason-q850-loc-06: Discuss >>>>>>>>=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-reason-q850-loc/ >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> = ---------------------------------------------------------------------- >>>>>>>> DISCUSS: >>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>=20 >>>>>>>> I support Adam's Discuss. >>>>>>>>=20 >>>>>>>> I also think that the Section 4 text: >>>>>>>>=20 >>>>>>>> The use of the location parameter is restricted to Q850 cause = values. >>>>>>>> Other values MUST be ignored if present. >>>>>>>>=20 >>>>>>>> needs to be clear about whether it is intended to limit to the = exact 16 strings >>>>>>>> listed above, or whether the intent is to update with Q850 if = new values are >>>>>>>> allocated. Are string aliases allowed for the "national-use" = codepoints if >>>>>>>> allocated within a given nation? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> = ---------------------------------------------------------------------- >>>>>>>> COMMENT: >>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>=20 >>>>>>>> Section 1 >>>>>>>>=20 >>>>>>>> the reason of release. The reason of release does indicate why = a SIP >>>>>>>> Dialog or an PSTN call, in case where the call was interworked = to the >>>>>>>>=20 >>>>>>>> nits: s/does indicate/indicates/ ; s/an PSTN/a PSTN/ >>>>>>>>=20 >>>>>>>> Section 3 >>>>>>>>=20 >>>>>>>> The primary intent of the parameter defined in this = specification is >>>>>>>> for use in IMS (IP Multimedia Subsystem) networks defined by = 3GPP but >>>>>>>> also open to be used by any other network that includes ISUP >>>>>>>>=20 >>>>>>>> nit: s/also/it is also/ >>>>>>>>=20 >>>>>>>> Section 4 >>>>>>>>=20 >>>>>>>> Depending on whether the message is a request or a response the = UAC >>>>>>>> or UAS SHALL include the location parameter when setting up the >>>>>>>> Reason header field with a [Q.850] cause. This approach is = only >>>>>>>> possible in cases when the ISUP [Q.850] location is available. >>>>>>>>=20 >>>>>>>> I don't understand what depends on whether the message is a = request or a >>>>>>>> response. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> sipcore mailing list >>>>>>>> sipcore@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_D280D559-6C99-4E9B-B6A6-FBD576E746BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = RFC editor note for Benjamin=E2=80=99s and Adam=E2=80=99s points is in = place at https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850= -loc/writeup/  

You may need to scroll down.

Thanks!

Ben.


On Mar 20, 2019, at 7:47 PM, = Ben Campbell <ben@nostrum.com> wrote:



On = Mar 20, 2019, at 7:43 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:

On Wed, Mar 20, 2019 at 07:23:24PM -0500, Ben = Campbell wrote:
Here=E2=80=99s a proposed RFC Editor note to make the changes = in section 4. I made some slight edits for clarity, and a bigger edit to = include the part about the ISUP location being available as a condition = of the SHALL, rather than a separate statement suggesting that the SHALL = is not always possible to follow.

Benjamin = and Roland, does this work for you?

Modulo typos (inline), I can clear my Discuss for that = text.

-Benjamin

Thanks!

Ben.

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

Please make the following edits to the first two paragraphs = following Figure 1 in
Section 4:

OLD:
Note: These are the values defined within = [Q.850] as location.  Thus
other values are not = within the scope of this document.

Depending = on whether the message is a request or a response the UAC
or= UAS SHALL include the location parameter when setting up the Reason
header field with a [Q.850] cause.  This approach is = only possible in cases
when the ISUP [Q.850] location is = available.

NEW:
Note: These = are the values defined within [Q.850] as location.  Thus
other values are not within the scope of this document. the = 'LOC=3D*' names

I feel like = this was probably my typo originally, but capital "The" and a
hyphen in "LOC-*" (not equals).

will fix in the actual = note.


I still am not clear that "other values are not within the = scope of this
document" is saying anything helpful, but = that's not a blocking comment.

On reflection, I agree with you. = I think it wants to say =E2=80=9Cother values are not possible=E2=80=9D = or something to that effect, but it=E2=80=99s not necessary either = way.


are the wire codepoints = for the values currently left as 'spare' or 'reserved=E2=80=99
in [Q.850]; these will continue to be the wire codepoints in = the case of future
allocation or national usage of the = such values.

The UAC or UAS SHALL include = the location parameter in a request or response
when = setting up the Reason header field with a [Q.850] cause when the
ISUP [Q.850] location is available.


On Mar = 19, 2019, at 10:20 PM, Ben Campbell <ben@nostrum.com> wrote:

Signed PGP part
Hi Roland.

Benjamin tells me the remaining changes are small. Let me see = if I can put them in the form of an RFC Editor note, so we can hopefully = avoid a new revision.

Thanks!

Ben.

On Mar 19, 2019, at 9:30 PM, Ben Campbell = <ben@nostrum.com> = wrote:

Hi Roland,

Am I correct to understand that changes based on this = discussion have not yet made it into a draft? If so, when do you think = that could happen?

Please note that the = Plenary in Prague is sort of a deadline for this; if I am not able = approve it before then it will have to transition to another AD, which = could add delays while they come up to speed on it.

Thanks!

Ben.

On Mar 18, 2019, at 9:03 = AM, Benjamin Kaduk <kaduk@mit.edu> wrote:

On = Mon, Mar 11, 2019 at 08:20:34AM +0000, R.Jesske@telekom.de = wrote:
Hi,
Thank you for your comments. I went through the comments = and
here are my answers and proposals to the comments = made.
Sorry If some of you get the mail twice, since I = answered in another way already.

I do not mind the extra mail, and I must apologize myself for = the slowness
of the reply.


Discuss = on Section 4
Do you want to see something beyond the Note = I put in?
Note: These are the values defined  within = <xref target=3D"Q.850"/> as location. Thus other values are not = within the scope of this document.

The main thing I wanted to be clarified was that the string = name is the
actual codepoint used on the wire (as opposed = to some encoding of the
four-bit value).  Changing to = use ABNF for the specification os
isup-location-value is = sufficient to clarify that point; the only remaining
potential issue would be regarding potential future = changes/allocations...

The last try to change these values in ITU-T = was around 2001/2002 for some mobile network code points. This was = rejected since operators said that there is willingness to change ISUP = for such coding points. The values are stable since 20 years so there = will be no change of these values in future, since invest will go into = IP based networks like IMS.

....= and it sounds like the expected chances of any such changes are very
low.  I would still ask you to consider adding a note to = the effect of
"Note that the 'LOC=3D*' names are the wire = codepoints for the values
currently left as 'spare' or = 'reserved' in [Q.850]; these will continue to
be the wire = codepoints in the case of future allocation or national
usage."  I am happy to listen to some reasoning about = why even that
statement is not needed, though.

(BTW, given the presence of all 16 possible = 4-bit values, I don't think the
current Note about "other = values are not within the scope" is adding much
value, and = potentially could be replaced by my suggested note above.)

Comments = on Section 1,3 and 4
Nits on Section 1+3 corrected.

Section 4:
I try to reformulate = the sentence.
Proposal:

UAC =  or UAS SHALL include the location parameter in a request or = response   when setting up the Reason header field with a = [Q.850] cause.  This approach is only  possible in cases when = the ISUP [Q.850] location is available.

That helps a lot, thank you.

If you are OK with these = changes I will produce a new draft and upload it.

That would work, but it's also = fine if you want to wait until the issue
Adam raised comes = to a complete resolution on the list.

Thanks,

Benjamin
Thank you and Best = Regards

Roland
-----Urspr=C3=BCngliche Nachricht-----
Von: sipcore <sipcore-bounces@ietf.org> Im Auftrag von Datatracker = on
behalf of Benjamin Kaduk
Gesendet: = Donnerstag, 7. M=C3=A4rz 2019 06:22
An: The IESG <iesg@ietf.org>
Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org; sipcore-chairs@ietf.org;
sipcore@ietf.org
Betreff: [sipcore] Benjamin Kaduk's Discuss on = draft-ietf-sipcore-reason-
q850-loc-06: (with DISCUSS and = COMMENT)

Benjamin Kaduk has entered the = following ballot position for
draft-ietf-sipcore-reason-q850-loc-06: 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-reason-q850= -loc/



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

I support Adam's Discuss.

I also think that the Section 4 text:

The use of the location parameter is = restricted to Q850 cause values.
Other values MUST be = ignored if present.

needs to be clear about = whether it is intended to limit to the exact 16 strings
listed above, or whether the intent is to update with Q850 if = new values are
allocated.  Are string aliases allowed = for the "national-use" codepoints if
allocated within a = given nation?


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

Section 1

the reason of release.  The reason of release does = indicate why a SIP
Dialog or an PSTN call, in case where = the call was interworked to the

nits: = s/does indicate/indicates/ ; s/an PSTN/a PSTN/

Section 3

The primary intent of = the parameter defined in this specification is
for use in = IMS (IP Multimedia Subsystem) networks defined by 3GPP but
also open to be used by any other network that includes = ISUP

nit: s/also/it is also/

Section 4

Depending= on whether the message is a request or a response the UAC
or UAS SHALL include the location parameter when setting up = the
Reason header field with a [Q.850] cause.  This = approach is only
possible in cases when the ISUP [Q.850] = location is available.

I don't understand = what depends on whether the message is a request or a
response.


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

= --Apple-Mail=_D280D559-6C99-4E9B-B6A6-FBD576E746BE-- --Apple-Mail=_BDB9E8C2-4E74-4EAC-B4E5-F30AF84DDAC0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlyS4PgACgkQgFZKbJXz 1A1g3RAAl38yAwmpxwbInCr0z88mN3el65ud7PeNtmch9RUhPYHp9ITkOpFjHQJ0 PE8AiRgTSMPq2H6zIYOQltEeF0Uppc2aidIZBIYezkY4LTcApsQq3uZZJ1taWvYU RCUjhlTxXMnFJ+Sa3DNwWo8lDN9P9YOanBVAGyRYFUfdLRuP/cThQJscVT8cl5Fv HHsqvDmPhUj0WpYxl2vqJusFTojaTy+3aSEhZ6JDqvsic0W5f+7Q44I3Y0Ojm9D6 9988yoBNyyXpu4lTHLjRF0DgeyltR6r0qe6xwc/tMtpeCF6en8bsF9jC/w1cvS0q Haex2Pxf4lvi6lmXlO8O/DPt5Nv8T8JUOZAGaj0KGau5GI7xeFaw/eCXQHYlEW4O K7ZbXtDiH4a76Y6aSv05JdZUmfdIgqdoDlUtw77vF8urhjHwm3STdj53vSb/sesd KpXPNYd7xcV4rXnPRDGpdvqwvzdnWpMeVWXkT3dFBnY8Iw5Cf3YkC2V+8cf7ReZN GA334Ch9ofbxtxl4D2mVli3MYjzp/cKHONRrhaEewXMq+Vsf5+DvG/M9IH+oapKR H+WLGJi8MfgTADEFyGV43rQa6qAKXcr3Yk0kaU7rnmNxFzRY1A/FWcBq6L3GCwnQ IgTfSf0tc4oBrMjQ1zuEspUGZH6O+dO52hC6H17OeiW2I/ZjkNs= =2whQ -----END PGP SIGNATURE----- --Apple-Mail=_BDB9E8C2-4E74-4EAC-B4E5-F30AF84DDAC0-- From nobody Wed Mar 20 19:02:32 2019 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 9C9E112B003; Wed, 20 Mar 2019 19:02:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 vntF4p5EXyu9; Wed, 20 Mar 2019 19:02:19 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B01F8129524; Wed, 20 Mar 2019 19:02:19 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2L22Eav029473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Mar 2019 22:02:17 -0400 Date: Wed, 20 Mar 2019 21:02:14 -0500 From: Benjamin Kaduk To: Ben Campbell Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org, sipcore-chairs@ietf.org, Michael =?iso-8859-1?Q?T=FCxen?= via Datatracker , SIPCORE , "" , IESG Message-ID: <20190321020214.GR80498@kduck.mit.edu> References: <155193609023.13714.4531517779875308584.idtracker@ietfa.amsl.com> <20190318140358.GB80498@kduck.mit.edu> <0446BC26-28C3-42B7-8DD6-F8D054883DAF@nostrum.com> <20190321004356.GP80498@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 02:02:22 -0000 On Wed, Mar 20, 2019 at 07:55:20PM -0500, Ben Campbell wrote: > The RFC editor note for Benjamin’s and Adam’s points is in place at https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/writeup/ > > You may need to scroll down. Thanks; I've changed my position to No Objection in the datatracker. -Benjamin From nobody Sat Mar 23 07:00:45 2019 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 EF3AF130EC1 for ; Sat, 23 Mar 2019 07:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ntlworld.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 y9k27iFtVgCw for ; Sat, 23 Mar 2019 07:00:39 -0700 (PDT) Received: from know-smtprelay-omc-8.server.virginmedia.net (know-smtprelay-omc-8.server.virginmedia.net [80.0.253.72]) (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 EF996127964 for ; Sat, 23 Mar 2019 07:00:38 -0700 (PDT) Received: from [172.17.162.168] ([88.211.126.138]) by cmsmtp with ESMTPA id 7hCNh9vXWUyim7hCNh4gTP; Sat, 23 Mar 2019 14:00:35 +0000 X-Originating-IP: [88.211.126.138] X-Authenticated-User: drageke@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=XubUx2N9 c=1 sm=1 tr=0 a=A23Of5e5ItRGPqVSphLRgg==:117 a=A23Of5e5ItRGPqVSphLRgg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=r77TgQKjGQsHNAKrUKIA:9 a=Z80JlwQ0AAAA:8 a=48vgC7mUAAAA:8 a=OqDL3lSiVSJcZpvMRRYA:9 a=QEXdDO2ut3YA:10 a=mYAOWqAtFUkA:10 a=1dbGxDndw2gA:10 a=GN2WD7rlCzEZi_iRXnwA:9 a=RM9ymXN3PPG8yVRs:21 a=_W_S_7VecoQA:10 a=Zz-tw7mMPhxMdvFcggwQ:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1553349636; bh=YWV7duXRIdHgGPb9oxHYOuVsN7kux/Rkld6Ofar+g1M=; h=Subject:To:References:From:Date:In-Reply-To; b=SO18TshAboJFz0rNAxO2ISqh+yasLzTJhXbRhrHZ5p8xnyQUJHneJV6ttkjZIQXGv t39CSBwv/QylrrRodAhB3OVuCYehf1iQD0nzpPXge6DsLqPm5dK5c+LHiEn+wVKFoL j6PjxvGczFaDVoBxcOeuvWk/xVS45i8S3Afj/OZhKr/xdoPSzWSIbQ+4Nl1It1YpG8 P9bVlKjGgm/x/0ONM3SiB7rSxbQ4fYrHgXJyHtRzsqsYFqNIuLpXa+ue3Ag8TUbB5F Ae5GOSj2C5B9gkWN5oZ9uZYRFsL6eR4Y8snBTZ8iyiZm2bmy6HB4zYdP3+Gjb4lsrh 1WmyV1eFXEbQw== To: sipcore@ietf.org References: <155193609023.13714.4531517779875308584.idtracker@ietfa.amsl.com> <20190318140358.GB80498@kduck.mit.edu> <0446BC26-28C3-42B7-8DD6-F8D054883DAF@nostrum.com> From: Keith Drage Message-ID: Date: Thu, 21 Mar 2019 22:45:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F80E142217823920996C77A3" Content-Language: en-GB X-CMAE-Envelope: MS4wfMwAS8z/x8w2xM3aSXkz62LRodO93BL1vjUpQnVfDzDId8p1kfprbfiTY0vUCeBkEbkeTpftmfYE/TTIZYKHeapXlz/CBouwin3r52PvYb3a9jZBv3Ez /kcmerj7JYsRtR3bLAbvg2MFfdzKJ6U0nlvQYyNB2Dwi6aCwef8qIFaL Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason-q850-loc-06: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2019 14:00:44 -0000 This is a multi-part message in MIME format. --------------F80E142217823920996C77A3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I know this is part of the existing text, but Q.850 values (and locations) are not just used in ISUP, but also form part of DSS1 and indeed, also QSIG. Therefore I would regard the formulation of "ISUP [Q.850] location" as a little but confusing. For example does it means only those generated by an entity supporting ISUP, or only those coming from an entity supporting ISUP but relayed from other entities, or what. Keith On 21/03/2019 00:23, Ben Campbell wrote: > Here’s a proposed RFC Editor note to make the changes in section 4. I made some slight edits for clarity, and a bigger edit to include the part about the ISUP location being available as a condition of the SHALL, rather than a separate statement suggesting that the SHALL is not always possible to follow. > > Benjamin and Roland, does this work for you? > > Thanks! > > Ben. > > --------------------------------- > > Please make the following edits to the first two paragraphs following Figure 1 in > Section 4: > > OLD: > Note: These are the values defined within [Q.850] as location. Thus > other values are not within the scope of this document. > > Depending on whether the message is a request or a response the UAC > or UAS SHALL include the location parameter when setting up the Reason > header field with a [Q.850] cause. This approach is only possible in cases > when the ISUP [Q.850] location is available. > > NEW: > Note: These are the values defined within [Q.850] as location. Thus > other values are not within the scope of this document. the 'LOC=*' names > are the wire codepoints for the values currently left as 'spare' or 'reserved’ > in [Q.850]; these will continue to be the wire codepoints in the case of future > allocation or national usage of the such values. > > The UAC or UAS SHALL include the location parameter in a request or response > when setting up the Reason header field with a [Q.850] cause when the > ISUP [Q.850] location is available. > > >> On Mar 19, 2019, at 10:20 PM, Ben Campbell wrote: >> >> Signed PGP part >> Hi Roland. >> >> Benjamin tells me the remaining changes are small. Let me see if I can put them in the form of an RFC Editor note, so we can hopefully avoid a new revision. >> >> Thanks! >> >> Ben. >> >>> On Mar 19, 2019, at 9:30 PM, Ben Campbell wrote: >>> >>> Hi Roland, >>> >>> Am I correct to understand that changes based on this discussion have not yet made it into a draft? If so, when do you think that could happen? >>> >>> Please note that the Plenary in Prague is sort of a deadline for this; if I am not able approve it before then it will have to transition to another AD, which could add delays while they come up to speed on it. >>> >>> Thanks! >>> >>> Ben. >>> >>>> On Mar 18, 2019, at 9:03 AM, Benjamin Kaduk wrote: >>>> >>>> On Mon, Mar 11, 2019 at 08:20:34AM +0000, R.Jesske@telekom.de wrote: >>>>> Hi, >>>>> Thank you for your comments. I went through the comments and >>>>> here are my answers and proposals to the comments made. >>>>> Sorry If some of you get the mail twice, since I answered in another way already. >>>> I do not mind the extra mail, and I must apologize myself for the slowness >>>> of the reply. >>>> >>>>> Discuss on Section 4 >>>>> Do you want to see something beyond the Note I put in? >>>>> Note: These are the values defined within as location. Thus other values are not within the scope of this document. >>>> The main thing I wanted to be clarified was that the string name is the >>>> actual codepoint used on the wire (as opposed to some encoding of the >>>> four-bit value). Changing to use ABNF for the specification os >>>> isup-location-value is sufficient to clarify that point; the only remaining >>>> potential issue would be regarding potential future changes/allocations... >>>> >>>>> The last try to change these values in ITU-T was around 2001/2002 for some mobile network code points. This was rejected since operators said that there is willingness to change ISUP for such coding points. The values are stable since 20 years so there will be no change of these values in future, since invest will go into IP based networks like IMS. >>>> .... and it sounds like the expected chances of any such changes are very >>>> low. I would still ask you to consider adding a note to the effect of >>>> "Note that the 'LOC=*' names are the wire codepoints for the values >>>> currently left as 'spare' or 'reserved' in [Q.850]; these will continue to >>>> be the wire codepoints in the case of future allocation or national >>>> usage." I am happy to listen to some reasoning about why even that >>>> statement is not needed, though. >>>> >>>> (BTW, given the presence of all 16 possible 4-bit values, I don't think the >>>> current Note about "other values are not within the scope" is adding much >>>> value, and potentially could be replaced by my suggested note above.) >>>> >>>>> Comments on Section 1,3 and 4 >>>>> Nits on Section 1+3 corrected. >>>>> >>>>> Section 4: >>>>> I try to reformulate the sentence. >>>>> Proposal: >>>>> >>>>> UAC or UAS SHALL include the location parameter in a request or response when setting up the Reason header field with a [Q.850] cause. This approach is only possible in cases when the ISUP [Q.850] location is available. >>>> That helps a lot, thank you. >>>> >>>>> If you are OK with these changes I will produce a new draft and upload it. >>>> That would work, but it's also fine if you want to wait until the issue >>>> Adam raised comes to a complete resolution on the list. >>>> >>>> Thanks, >>>> >>>> Benjamin >>>> >>>>> Thank you and Best Regards >>>>> >>>>> Roland >>>>>> -----Ursprüngliche Nachricht----- >>>>>> Von: sipcore Im Auftrag von Datatracker on >>>>>> behalf of Benjamin Kaduk >>>>>> Gesendet: Donnerstag, 7. März 2019 06:22 >>>>>> An: The IESG >>>>>> Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org; sipcore-chairs@ietf.org; >>>>>> sipcore@ietf.org >>>>>> Betreff: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason- >>>>>> q850-loc-06: (with DISCUSS and COMMENT) >>>>>> >>>>>> Benjamin Kaduk has entered the following ballot position for >>>>>> draft-ietf-sipcore-reason-q850-loc-06: 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-reason-q850-loc/ >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> DISCUSS: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> I support Adam's Discuss. >>>>>> >>>>>> I also think that the Section 4 text: >>>>>> >>>>>> The use of the location parameter is restricted to Q850 cause values. >>>>>> Other values MUST be ignored if present. >>>>>> >>>>>> needs to be clear about whether it is intended to limit to the exact 16 strings >>>>>> listed above, or whether the intent is to update with Q850 if new values are >>>>>> allocated. Are string aliases allowed for the "national-use" codepoints if >>>>>> allocated within a given nation? >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> COMMENT: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> Section 1 >>>>>> >>>>>> the reason of release. The reason of release does indicate why a SIP >>>>>> Dialog or an PSTN call, in case where the call was interworked to the >>>>>> >>>>>> nits: s/does indicate/indicates/ ; s/an PSTN/a PSTN/ >>>>>> >>>>>> Section 3 >>>>>> >>>>>> The primary intent of the parameter defined in this specification is >>>>>> for use in IMS (IP Multimedia Subsystem) networks defined by 3GPP but >>>>>> also open to be used by any other network that includes ISUP >>>>>> >>>>>> nit: s/also/it is also/ >>>>>> >>>>>> Section 4 >>>>>> >>>>>> Depending on whether the message is a request or a response the UAC >>>>>> or UAS SHALL include the location parameter when setting up the >>>>>> Reason header field with a [Q.850] cause. This approach is only >>>>>> possible in cases when the ISUP [Q.850] location is available. >>>>>> >>>>>> I don't understand what depends on whether the message is a request or a >>>>>> response. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >> >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --------------F80E142217823920996C77A3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I know this is part of the existing text, but Q.850 values (and locations) are not just used in ISUP, but also form part of DSS1 and indeed, also QSIG. Therefore I would regard the formulation of "ISUP [Q.850] location" as a little but confusing. For example does it means only those generated by an entity supporting ISUP, or only those coming from an entity supporting ISUP but relayed from other entities, or what.


Keith

On 21/03/2019 00:23, Ben Campbell wrote:
Here’s a proposed RFC Editor note to make the changes in section 4. I made some slight edits for clarity, and a bigger edit to include the part about the ISUP location being available as a condition of the SHALL, rather than a separate statement suggesting that the SHALL is not always possible to follow.

Benjamin and Roland, does this work for you?

Thanks!

Ben.

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

Please make the following edits to the first two paragraphs following Figure 1 in
Section 4:

OLD:
Note: These are the values defined within [Q.850] as location.  Thus
other values are not within the scope of this document.

Depending on whether the message is a request or a response the UAC
or UAS SHALL include the location parameter when setting up the Reason
header field with a [Q.850] cause.  This approach is only possible in cases
when the ISUP [Q.850] location is available.

NEW:
Note: These are the values defined within [Q.850] as location.  Thus
other values are not within the scope of this document. the 'LOC=*' names
are the wire codepoints for the values currently left as 'spare' or 'reserved’
in [Q.850]; these will continue to be the wire codepoints in the case of future
allocation or national usage of the such values.

The UAC or UAS SHALL include the location parameter in a request or response
when setting up the Reason header field with a [Q.850] cause when the
ISUP [Q.850] location is available.



On Mar 19, 2019, at 10:20 PM, Ben Campbell <ben@nostrum.com> wrote:

Signed PGP part
Hi Roland.

Benjamin tells me the remaining changes are small. Let me see if I can put them in the form of an RFC Editor note, so we can hopefully avoid a new revision.

Thanks!

Ben.


On Mar 19, 2019, at 9:30 PM, Ben Campbell <ben@nostrum.com> wrote:

Hi Roland,

Am I correct to understand that changes based on this discussion have not yet made it into a draft? If so, when do you think that could happen?

Please note that the Plenary in Prague is sort of a deadline for this; if I am not able approve it before then it will have to transition to another AD, which could add delays while they come up to speed on it.

Thanks!

Ben.


On Mar 18, 2019, at 9:03 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:

On Mon, Mar 11, 2019 at 08:20:34AM +0000, R.Jesske@telekom.de wrote:

Hi,
Thank you for your comments. I went through the comments and
here are my answers and proposals to the comments made.
Sorry If some of you get the mail twice, since I answered in another way already.

I do not mind the extra mail, and I must apologize myself for the slowness
of the reply.


Discuss on Section 4
Do you want to see something beyond the Note I put in?
Note: These are the values defined  within <xref target="Q.850"/> as location. Thus other values are not within the scope of this document.

The main thing I wanted to be clarified was that the string name is the
actual codepoint used on the wire (as opposed to some encoding of the
four-bit value).  Changing to use ABNF for the specification os
isup-location-value is sufficient to clarify that point; the only remaining
potential issue would be regarding potential future changes/allocations...


The last try to change these values in ITU-T was around 2001/2002 for some mobile network code points. This was rejected since operators said that there is willingness to change ISUP for such coding points. The values are stable since 20 years so there will be no change of these values in future, since invest will go into IP based networks like IMS.

.... and it sounds like the expected chances of any such changes are very
low.  I would still ask you to consider adding a note to the effect of
"Note that the 'LOC=*' names are the wire codepoints for the values
currently left as 'spare' or 'reserved' in [Q.850]; these will continue to
be the wire codepoints in the case of future allocation or national
usage."  I am happy to listen to some reasoning about why even that
statement is not needed, though.

(BTW, given the presence of all 16 possible 4-bit values, I don't think the
current Note about "other values are not within the scope" is adding much
value, and potentially could be replaced by my suggested note above.)


Comments on Section 1,3 and 4
Nits on Section 1+3 corrected.

Section 4:
I try to reformulate the sentence.
Proposal:

UAC  or UAS SHALL include the location parameter in a request or response   when setting up the Reason header field with a [Q.850] cause.  This approach is only  possible in cases when the ISUP [Q.850] location is available.

That helps a lot, thank you.


If you are OK with these changes I will produce a new draft and upload it.

That would work, but it's also fine if you want to wait until the issue
Adam raised comes to a complete resolution on the list.

Thanks,

Benjamin


Thank you and Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: sipcore <sipcore-bounces@ietf.org> Im Auftrag von Datatracker on
behalf of Benjamin Kaduk
Gesendet: Donnerstag, 7. März 2019 06:22
An: The IESG <iesg@ietf.org>
Cc: draft-ietf-sipcore-reason-q850-loc@ietf.org; sipcore-chairs@ietf.org;
sipcore@ietf.org
Betreff: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-reason-
q850-loc-06: (with DISCUSS and COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sipcore-reason-q850-loc-06: 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-reason-q850-loc/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Adam's Discuss.

I also think that the Section 4 text:

The use of the location parameter is restricted to Q850 cause values.
Other values MUST be ignored if present.

needs to be clear about whether it is intended to limit to the exact 16 strings
listed above, or whether the intent is to update with Q850 if new values are
allocated.  Are string aliases allowed for the "national-use" codepoints if
allocated within a given nation?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1

the reason of release.  The reason of release does indicate why a SIP
Dialog or an PSTN call, in case where the call was interworked to the

nits: s/does indicate/indicates/ ; s/an PSTN/a PSTN/

Section 3

The primary intent of the parameter defined in this specification is
for use in IMS (IP Multimedia Subsystem) networks defined by 3GPP but
also open to be used by any other network that includes ISUP

nit: s/also/it is also/

Section 4

Depending on whether the message is a request or a response the UAC
or UAS SHALL include the location parameter when setting up the
Reason header field with a [Q.850] cause.  This approach is only
possible in cases when the ISUP [Q.850] location is available.

I don't understand what depends on whether the message is a request or a
response.


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


            

            

          

          

        

        




      

      

      

      

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


    

  


--------------F80E142217823920996C77A3--


From nobody Mon Mar 25 01:44:11 2019
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 1C6FF12037E; Mon, 25 Mar 2019 01:44:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Cc: ben@nostrum.com, draft-ietf-sipcore-reason-q850-loc@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, br@brianrosen.net, The IESG , Brian Rosen , rfc-editor@rfc-editor.org
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Message-ID: <155350345010.22387.6939300066276932947.idtracker@ietfa.amsl.com>
Date: Mon, 25 Mar 2019 01:44:10 -0700
Archived-At: 
Subject: [sipcore] Protocol Action: 'ISUP Cause Location Parameter for the SIP Reason Header Field' to Proposed Standard (draft-ietf-sipcore-reason-q850-loc-07.txt)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 08:44:10 -0000

The IESG has approved the following document:
- 'ISUP Cause Location Parameter for the SIP Reason Header Field'
  (draft-ietf-sipcore-reason-q850-loc-07.txt) as Proposed Standard

This document is the product of the Session Initiation Protocol Core Working
Group.

The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/




Working Group Summary:

This document has struggled to get adequate reviews.  Chairs (which in include the shepherd) believe review is barely adequate, but the mechanism is so simple, and needed by 3GPP, that we feel advancing the document is appropriate

Document Quality:

3GPP has indicated they will incorporate this document in their documents and some implementations very likely.  One of the significant sip experts has reviewed the document and provided minor comments which have been incorporated.  No special reviews have been conducted or are needed.  

Personnel:

Brian Rosen is the Document Shepherd, Ben Campbell is the Area Director



RFC Editor Note

Please change the first sentence of the first paragraph in section 1 as follows:

OLD:
   The SIP Reason header field specification [RFC3326] describes a SIP
   header field that is used to indicate that a SIP request is carrying
   the reason of release. 
NEW:
   Section 3.4 of [RFC3326] describes a SIP message flow for canceling an
   INVITE request when a REL (release) message is received from the ISUP
   side. That document specifies the SIP Reason header field [RFC3326]
   that is used to indicate the reason of release.
END.

 Please replace Figure 1 in it's entirety, as follows. (Please make the column alignment pretty; the RFC editor note tool is resisting my attempts to do so).

OLD:
reason-extension =/ isup-cause-location
isup-cause-location =  "location" EQUAL isup-location-value

   isup-location-value =
      %s"U" /      ; for 0 0 0 0 user
      %s"LPN" /    ; for 0 0 0 1 private network serving the local user
      %s"LN" /     ; for 0 0 1 0 public network serving the local user
      %s"TN" /     ; for 0 0 1 1 transit network
      %s"RLN" /    ; for 0 1 0 0 public network serving the remote user
      %s"RPN" /    ; for 0 1 0 1 private network serving the remote user
      %s"LOC-6" /  ; for 0 1 1 0 spare
      %s"INTL" /   ; for 0 1 1 1 international network
      %s"LOC-8" /  ; for 1 0 0 0 spare
      %s"LOC-9" /  ; for 1 0 0 1 spare
      %s"BI" /     ; for 1 0 1 0 network beyond interworking point
      %s"LOC-11" / ; for 1 0 1 1 spare
      %s"LOC-12" / ; for 1 1 0 0 reserved for national use
      %s"LOC-13" / ; for 1 1 0 1 reserved for national use
      %s"LOC-14" / ; for 1 1 1 0 reserved for national use
      %s"LOC-15"   ; for 1 1 1 1 reserved for national use

                       Figure 1: isup-cause-location
NEW:
reason-extension =/ isup-cause-location
isup-cause-location =  "location" EQUAL isup-location-value

   isup-location-value =
      "U" /      ; for 0 0 0 0 user
      "LPN" /    ; for 0 0 0 1 private network serving the local user
      "LN" /     ; for 0 0 1 0 public network serving the local user
      "TN" /     ; for 0 0 1 1 transit network
      "RLN" /    ; for 0 1 0 0 public network serving the remote user
      "RPN" /    ; for 0 1 0 1 private network serving the remote user
      "LOC-6" /  ; for 0 1 1 0 spare
      "INTL" /   ; for 0 1 1 1 international network
      "LOC-8" /  ; for 1 0 0 0 spare
      "LOC-9" /  ; for 1 0 0 1 spare
      "BI" /     ; for 1 0 1 0 network beyond interworking point
      "LOC-11" / ; for 1 0 1 1 spare
      "LOC-12" / ; for 1 1 0 0 reserved for national use
      "LOC-13" / ; for 1 1 0 1 reserved for national use
      "LOC-14" / ; for 1 1 1 0 reserved for national use
      "LOC-15"   ; for 1 1 1 1 reserved for national use

                       Figure 1: isup-cause-location
END.

Please replace the two paragraphs following figure 1 in section 4 as follows:

OLD:
Note: These are the values defined within [Q.850] as location.  Thus
other values are not within the scope of this document.

Depending on whether the message is a request or a response the UAC
or UAS SHALL include the location parameter when setting up the Reason
header field with a [Q.850] cause.  This approach is only possible in cases
when the ISUP [Q.850] location is available.

NEW:
Note: These are the values defined within [Q.850] as location. The 'LOC-*' names
are the wire codepoints for the values currently left as 'spare' or 'reserved’
in [Q.850]; these will continue to be the wire codepoints in the case of future
allocation or national usage of the such values.

The UAC or UAS SHALL include the location parameter in a request or response
when setting up the Reason header field with a [Q.850] cause when the
ISUP [Q.850] location is available.
END.

Finally, please change the date for the [Q850] reference to October 2018. 

Thanks!

Ben.


From nobody Tue Mar 26 01:01:10 2019
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 2CEA1120047; Tue, 26 Mar 2019 01:01:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: sipcore@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: sipcore@ietf.org
Message-ID: <155358726309.20729.2664514406123016941@ietfa.amsl.com>
Date: Tue, 26 Mar 2019 01:01:03 -0700
Archived-At: 
Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-29.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 08:01:04 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core WG of the IETF.

        Title           : Push Notification with the Session Initiation Protocol (SIP)
        Authors         : Christer Holmberg
                          Michael Arnold
	Filename        : draft-ietf-sipcore-sip-push-29.txt
	Pages           : 40
	Date            : 2019-03-26

Abstract:
   This document describes how a Push Notification Service (PNS) can be
   used to wake a suspended Session Initiation Protocol (SIP) User Agent
   (UA) with push notifications, and also describes how the UA can send
   binding-refresh REGISTER requests and receive incoming SIP requests
   in an environment in which the UA may be suspended.  The document
   defines new SIP URI parameters to exchange PNS information between
   the UA and the SIP entity that will then request that push
   notifications be sent to the UA, and to trigger such push
   notification requests.  The document also defines new feature-
   capability indicators that can be used to indicate support of this
   mechanism.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-29
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-29

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-push-29


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Mar 26 01:04:44 2019
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 EFE7A12028B; Tue, 26 Mar 2019 01:04:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 JPtL3Kz-Cth7; Tue, 26 Mar 2019 01:04:38 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80073.outbound.protection.outlook.com [40.107.8.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0C6120047; Tue, 26 Mar 2019 01:04:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=js5OgKCkHiv3pbSQo7bNJYTUCDAe/ZM3rRuqjWBdJKM=; b=QbwynxtUmtTdr87IEB5m5kp445yPUVUTO7vc9fwVdxwWFttgycqVQFeSzj8fPX5u3Ux2MEdkhIKhFA+faotxZP8rvX4wNF6X/1DlcYJ8l2CRafgj+ya+2VIQrRtPiolpGzmID3hpHQ2ijFa1ECcUZWtVUbI8IQ3Z/IvNzUSJn68=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4426.eurprd07.prod.outlook.com (20.176.167.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.14; Tue, 26 Mar 2019 08:04:35 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1750.014; Tue, 26 Mar 2019 08:04:35 +0000
From: Christer Holmberg 
To: "sipcore@ietf.org" 
CC: "draft-ietf-sipcore-sip-push.all@ietf.org" , "sipcore-chairs@ietf.org" , Eric Rescorla , "adam@nostrum.com" , Ben Campbell 
Thread-Topic: Draft new version: PUSH-29
Thread-Index: AQHU46qNNeBAymLgG02HYoW/0P8DkQ==
Date: Tue, 26 Mar 2019 08:04:35 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 846814a1-a593-464f-1602-08d6b1c1afd7
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4426; 
x-ms-traffictypediagnostic: HE1PR07MB4426:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(366004)(346002)(39860400002)(136003)(189003)(199004)(99286004)(7736002)(36756003)(2906002)(81156014)(1730700003)(606006)(8676002)(558084003)(106356001)(2351001)(6436002)(486006)(81166006)(476003)(66066001)(105586002)(97736004)(44832011)(8936002)(6916009)(53936002)(58126008)(4326008)(83716004)(54906003)(71190400001)(236005)(82746002)(6512007)(54896002)(71200400001)(6306002)(5640700003)(33656002)(5660300002)(6486002)(256004)(316002)(14444005)(6116002)(3846002)(102836004)(86362001)(6506007)(6346003)(26005)(966005)(186003)(478600001)(68736007)(2501003)(25786009)(14454004)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4426; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: QfvMjlPMLcwQgNhBtsIe5+ZVheujkixhiX4WybjGvsdRRtn/xYz4Yk0ryzca5pvvKhVTs6X8R8ph0vcipDoYA2UB/v5uZaiHLVB7yvj1lG2SbZ56DRS+x6YL/NI66eqm9CAAeI00Wwip5LI2YizflN+2PwQs38ZGiCXrcErgox3jwh50qGZAZxA6umyPDQH1zVenXQxpi63O/H5L+DJtT99zy26CGtGStygySlDz3YtfZWpBwoy0SAob8LC45qUawH9LAt1Wx9VrxpNkW0ZDI94cM3I/sF9Qi8pCsUMTVgOF7MDGc+iVRlmZuQZNqW6GQUvjKuBeVNjIxX243r+Zz7dJaiPYRvvRLlQ9kgJme99U1jdB+oth3C0xCCaW5FZDz/pQSzNc0rvkwo/HWSkm8z0AmksS+AdiWuNaVw2Cpcc=
Content-Type: multipart/alternative; boundary="_000_D3C1EF084227405EBF2D1B134CC993D6ericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 846814a1-a593-464f-1602-08d6b1c1afd7
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 08:04:35.4515 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4426
Archived-At: 
Subject: [sipcore] Draft new version: PUSH-29
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 08:04:42 -0000

--_000_D3C1EF084227405EBF2D1B134CC993D6ericssoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCkJhc2VkIG9uIEVrcuKAmXMgY29tbWVudCBvbiB2ZXJzaW9uIC0yOCwgSSBoYXZlIHN1
Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uICgtMjkpIG9mIFNJUCBQdXNoLg0KDQpUaGUgZm9sbG93aW5n
IHB1bGwgcmVxdWVzdCB3YXMgY3JlYXRlZCBhbmQgbWVyZ2VkIGZvciB0aGUgbmV3IHZlcnNpb246
DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1zaXAtcHVzaC9wdWxsLzQxDQoNClJl
Z2FyZHMsDQoNCkNocmlzdGVyDQo=

--_000_D3C1EF084227405EBF2D1B134CC993D6ericssoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz
cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw
dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2Lldv
cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K
PGJvZHkgbGFuZz0iRkkiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xh
c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+QmFzZWQgb24gRWty4oCZcyBjb21tZW50IG9uIHZlcnNpb24gLTI4
LCBJIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gKC0yOSkgb2YgU0lQIFB1c2guPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPlRoZSBmb2xsb3dpbmcgcHVsbCByZXF1ZXN0IHdhcyBjcmVhdGVkIGFuZCBtZXJnZWQg
Zm9yIHRoZSBuZXcgdmVyc2lvbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIu
Y29tL2NkaDR1L2RyYWZ0LXNpcC1wdXNoL3B1bGwvNDEiPmh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0
dS9kcmFmdC1zaXAtcHVzaC9wdWxsLzQxPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzLDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_D3C1EF084227405EBF2D1B134CC993D6ericssoncom_--


From nobody Tue Mar 26 01:42:44 2019
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 80A2F120284; Tue, 26 Mar 2019 01:42:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla via Datatracker 
To: "The IESG" 
Cc: draft-ietf-sipcore-sip-push@ietf.org, Brian Rosen , sipcore-chairs@ietf.org, br@brianrosen.net, sipcore@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Eric Rescorla 
Message-ID: <155358974748.20696.16575109533111315348.idtracker@ietfa.amsl.com>
Date: Tue, 26 Mar 2019 01:42:27 -0700
Archived-At: 
Subject: [sipcore] Eric Rescorla's No Objection on draft-ietf-sipcore-sip-push-29: (with COMMENT)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 08:42:28 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-sipcore-sip-push-29: 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-sip-push/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my DISCUSS and the extensive editorial rework.



From nobody Tue Mar 26 02:33:21 2019
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 D81DA120282; Tue, 26 Mar 2019 02:33:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Cc: ben@nostrum.com, sipcore-chairs@ietf.org, sipcore@ietf.org, br@brianrosen.net, The IESG , Brian Rosen ,  draft-ietf-sipcore-sip-push@ietf.org, rfc-editor@rfc-editor.org
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Message-ID: <155359279980.20725.4259064962077309462.idtracker@ietfa.amsl.com>
Date: Tue, 26 Mar 2019 02:33:19 -0700
Archived-At: 
Subject: [sipcore] Protocol Action: 'Push Notification with the Session Initiation Protocol (SIP)' to Proposed Standard (draft-ietf-sipcore-sip-push-29.txt)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 09:33:20 -0000

The IESG has approved the following document:
- 'Push Notification with the Session Initiation Protocol (SIP)'
  (draft-ietf-sipcore-sip-push-29.txt) as Proposed Standard

This document is the product of the Session Initiation Protocol Core Working
Group.

The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/





Technical Summary:

   This document describes how a Push Notification Service (PNS) can be
   used to wake suspended Session Initiation Protocol (SIP) User Agents
   (UAs), using push notifications, for the UA to be able to send
   binding refresh REGISTER requests and to receive receive incoming SIP
   requests.  The document defines new SIP URI parameters and new
   feature-capability indicators that can be used in SIP messages to
   indicate support of the mechanism defined in this document, to
   exchange PNS information between the SIP User Agent (UA) and the SIP
   entity that will request push notifications towards the UA, and to
   trigger such push notification requests.

Working Group Summary:

This document has had extensive discussion and review by a significant number of sip experts.  The mechanism has been revised several times in response to substantive comments.  There was controversy on the wisdom of providing mechanisms for proprietary push notification protocols to use, but the work group has a solid rough consensus that this document solves a real problem in an appropriate way and does not favor any proprietary push notification system over a standard one (RFC8030)

Document Quality:

There are many reports of implementations of proprietary solutions to the problem this document addresses, and discussion indicates this mechanism will replace those mechanisms in many cases.  We expect quite a few implementations, but there have not been reports of actual implementations at this time.  Many sipcore "regulars" have reviewed drafts of this document and made substantive comments which has resulted in many versions of the document. All comments have been addressed.  

Personnel:

Brian Rosen is the Document Shepherd, Ben Campbell is the Area Director


From nobody Wed Mar 27 05:31:36 2019
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 935001202AF for ; Wed, 27 Mar 2019 05:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 9Fd0QPhfYOEr for ; Wed, 27 Mar 2019 05:31:30 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on060c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::60c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9CB1202AA for ; Wed, 27 Mar 2019 05:31:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3thjzepBy+csz6H1NiLAcbEGMT3LlMmwTgoHf/szXIM=; b=UjtSJ7KxrVyEAZVgOr4ATiOpj01F9cqD8k310332W/Ixo79Jefj9lXARWBOBe7zslZTChdekNuhldQthPNZa0p3I37AgNvpvK+xzttavVeBNvRBNyRZWmxYSBdwuZ3h7F0o1gb10u0xwvhxIX+q5jolm5fpiduEVFC9BvHCMOEc=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3066.eurprd07.prod.outlook.com (10.170.244.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Wed, 27 Mar 2019 12:31:27 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1750.014; Wed, 27 Mar 2019 12:31:27 +0000
From: Christer Holmberg 
To: "sipcore@ietf.org" 
CC: "adam@nostrum.com" , Ben Campbell 
Thread-Topic: reg-event issue with multi-identity/multi-device
Thread-Index: AQHU5Jj/Nwtdx+7wP0OSgkyGhayhmw==
Date: Wed, 27 Mar 2019 12:31:27 +0000
Message-ID: <97159F5B-8C69-4B89-A25F-39F95ED57027@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 60a280fe-655e-4b03-67c7-08d6b2b021de
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3066; 
x-ms-traffictypediagnostic: HE1PR07MB3066:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0989A7979C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(396003)(136003)(346002)(39860400002)(189003)(199004)(6486002)(81156014)(8676002)(1730700003)(81166006)(33656002)(476003)(486006)(102836004)(6506007)(8936002)(26005)(82746002)(71200400001)(83716004)(71190400001)(44832011)(68736007)(2616005)(4326008)(6916009)(186003)(99286004)(305945005)(6306002)(7736002)(53936002)(6512007)(5640700003)(256004)(6436002)(14444005)(5660300002)(478600001)(14454004)(25786009)(36756003)(58126008)(54906003)(2906002)(86362001)(316002)(97736004)(66066001)(2351001)(3846002)(2501003)(105586002)(106356001)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3066; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 25ikfwzuy0wJVWQr4W5FLaH6tuR3vNDNtX6oxtzRUJ0TkceRZCPEzt/2CCc0KjS8mAs8Ql2/qakxKTnUetB0WnPjLrDY4BwyPz2R+Fj9dezJBB5FJMM1HNps1hUvoNdzi1jIjxUp8HIrV75gwwHhJhPTyli/L459RDIfQFipyfQiFXWcPNA99GT/KU+nJ+ta5sT9hze/uX9DveQE4b4RZ4aReG8X6WczC4JAsk990r7C/KLTaSVbgUHFi3o+eDqzwAtcDwr0NwMx0ZAciBTDXbhM3jfihznOFktcd3hzYdw/Mf13WoHvikIcDbsv8EFgGHm2cTfGTsaTkZEDvMTR9UdqUMuhPa8WxgIU8GEhTw17J36hUXt+ouOtjiDcLqqXvls9G1oa++cXgD1P3T7z3ykEve6cu5z74nFtJe1CbDM=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 60a280fe-655e-4b03-67c7-08d6b2b021de
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2019 12:31:27.0825 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3066
Archived-At: 
Subject: [sipcore] reg-event issue with multi-identity/multi-device
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Mar 2019 12:31:35 -0000

wqDCoMKgwqDCoMKgSGksDQrCoMKgwqDCoMKgwqDCoMKgDQrCoMKgwqDCoMKgwqDCoMKgM0dQUCBk
ZWZpbmVzIOKAnW11bHRpIGlkZW50aXR54oCdIGFuZCDigJ1tdWx0aSBkZXZpY2Vz4oCdIGNvbmNl
cHRzLCB3aGljaCBtZWFucyB0aGF0Og0KwqDCoMKgwqDCoMKgwqDCoA0KwqDCoMKgwqDCoMKgwqDC
oDEpIEEgdXNlciBjYW4gaGF2ZSBtdWx0aXBsZSBwaG9uZSBudW1iZXJzOyBhbmQNCsKgwqDCoMKg
wqDCoMKgwqAyKSBBIHVzZXIgY2FuIGhhdmUgbXVsdGlwbGUgZGV2aWNlcywgZWFjaCBvZiB3aGlj
aCBjYW4gYmUgcmVhY2hlZCB3aXRoIGFueSBvZiB0aG9zZSBwaG9uZSBudW1iZXJzDQrCoMKgwqDC
oMKgwqDCoMKgDQrCoMKgwqDCoMKgwqDCoMKgQXNzdW1lIGEgdXNlciBoYXM6DQrCoMKgwqDCoMKg
wqDCoMKgDQrCoMKgwqDCoMKgwqDCoMKgMSkgMiBwaG9uZSBudW1iZXJzLCBlYWNoIHdpdGggYSBT
SVAgVVJJIGFuZCBhIHRlbCBVUkkgcmVwcmVzZW50YXRpb24gKCJwaG9uZV9udW1iZXIxL1NJUCIs
ICJwaG9uZV9udW1iZXIxL1RFTCIsICJwaG9uZV9udW1iZXIyL1NJUCIgYW5kICJwaG9uZV9udW1i
ZXIyL1RFTCIpDQrCoMKgwqDCoMKgwqDCoMKgMikgRGlmZmVyZW50IGRldmljZXMsIGVhY2ggd2l0
aCBhIGRpZmZlcmVudCBjb250YWN0IElQIGFkZHJlc3MgKCJJUC1BZGRyZXNzMSIsICJJUC1BZGRy
ZXNzMiIgYW5kICJJUC1BZGRyZXNzMyIpDQrCoMKgwqDCoMKgwqDCoMKgDQrCoMKgwqDCoMKgwqDC
oMKgQSBzaW1wbGlmaWVkIHJlZy1ldmVudCBub3RpZmljYXRpb24gd291bGQgbG9vayBsaWtlIHRo
aXM6DQrCoMKgwqDCoMKgwqDCoMKgDQrCoMKgwqDCoMKgwqDCoMKgPHJlZ2lzdHJhdGlvbiBhb3I9
c2lwOnBob25lX251bWJlcjEvU0lQIGlkPSIxIiBzdGF0ZT0iYWN0aXZlIj4NCsKgwqDCoMKgwqDC
oMKgwqDCoAk8Y29udGFjdD4gPHVyaT5JUC1BZGRyZXNzMTwvdXJpPjwvY29udGFjdD4NCsKgwqDC
oMKgwqDCoMKgwqDCoAk8Y29udGFjdD4gPHVyaT5JUC1BZGRyZXNzMjwvdXJpPjwvY29udGFjdD4N
CsKgwqDCoMKgwqDCoMKgwqDCoAk8Y29udGFjdD4gPHVyaT5JUC1BZGRyZXNzMzwvdXJpPjwvY29u
dGFjdD4NCsKgwqDCoMKgwqDCoMKgwqA8cmVnaXN0cmF0aW9uIGFvcj10ZWw6cGhvbmVfbnVtYmVy
MS9URUwgaWQ9IjIiIHN0YXRlPSJhY3RpdmUiPg0KwqDCoMKgwqDCoMKgwqDCoMKgCTxjb250YWN0
PiA8dXJpPklQLUFkZHJlc3MxPC91cmk+PC9jb250YWN0Pg0KwqDCoMKgwqDCoMKgwqDCoMKgCTxj
b250YWN0PiA8dXJpPklQLUFkZHJlc3MyPC91cmk+PC9jb250YWN0Pg0KwqDCoMKgwqDCoMKgwqDC
oMKgCTxjb250YWN0PiA8dXJpPklQLUFkZHJlc3MzPC91cmk+PC9jb250YWN0Pg0KwqDCoMKgwqDC
oMKgwqDCoDxyZWdpc3RyYXRpb24gYW9yPXNpcDpwaG9uZV9udW1iZXIyL1NJUCBpZD0iMSIgc3Rh
dGU9ImFjdGl2ZSI+DQrCoMKgwqDCoMKgwqDCoMKgwqAJPGNvbnRhY3Q+IDx1cmk+SVAtQWRkcmVz
czE8L3VyaT48L2NvbnRhY3Q+DQrCoMKgwqDCoMKgwqDCoMKgwqAJPGNvbnRhY3Q+IDx1cmk+SVAt
QWRkcmVzczI8L3VyaT48L2NvbnRhY3Q+DQrCoMKgwqDCoMKgwqDCoMKgwqAJPGNvbnRhY3Q+IDx1
cmk+SVAtQWRkcmVzczM8L3VyaT48L2NvbnRhY3Q+DQrCoMKgwqDCoMKgwqDCoMKgPHJlZ2lzdHJh
dGlvbiBhb3I9dGVsOnBob25lX251bWJlcjIvVEVMIGlkPSIyIiBzdGF0ZT0iYWN0aXZlIj4NCsKg
wqDCoMKgwqDCoMKgwqDCoAk8Y29udGFjdD4gPHVyaT5JUC1BZGRyZXNzMTwvdXJpPjwvY29udGFj
dD4NCsKgwqDCoMKgwqDCoMKgwqDCoAk8Y29udGFjdD4gPHVyaT5JUC1BZGRyZXNzMjwvdXJpPjwv
Y29udGFjdD4NCsKgwqDCoMKgwqDCoMKgwqDCoAk8Y29udGFjdD4gPHVyaT5JUC1BZGRyZXNzMzwv
dXJpPjwvY29udGFjdD4NCsKgwqDCoMKgwqDCoMKgwqANCsKgwqDCoMKgwqDCoMKgwqBBcyB5b3Ug
Y2FuIHNlZSwgdGhlIGNvbnRhY3QgaW5mb3JtYXRpb24gaXMgZHVwbGljYXRlZCBtYW55IHRpbWVz
Lg0KwqDCoMKgwqDCoMKgwqDCoA0KwqDCoMKgwqDCoMKgwqDCoFVzaW5nIGFuIGV4YW1wbGUgYmFz
ZWQgb24gdGhlIFhNTCBzY2hlbWEgaW4gUkZDIDM2ODAgc2hvd3MgdGhhdCB0aGUgcGF5bG9hZCBj
YW4gZ2V0IHZlcnkgYmlnIChJIGFtIHVzaW5nIGVtcHR5IGxpbmVzIGZvciByZWFkYWJpbGl0eSk6
DQrCoMKgwqDCoMKgwqDCoMKgDQrCoMKgwqDCoMKgwqDCoMKgPD94bWwgdmVyc2lvbj0iMS4wIiBl
bmNvZGluZz0iVVRGLTgiPz4NCsKgwqDCoMKgwqDCoMKgwqA8IS0tU2FtcGxlIFhNTCBmaWxlIGdl
bmVyYXRlZCBieSBYTUxTcHkgdjIwMDggKGh0dHA6Ly93d3cuYWx0b3ZhLmNvbSktLT4NCsKgwqDC
oMKgwqDCoMKgwqA8dG5zOnJlZ2luZm8gc3RhdGU9ImZ1bGwiIHZlcnNpb249IjAiIHhzaTpzY2hl
bWFMb2NhdGlvbj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpyZWdpbmZvIFVudGl0bGVkMS54c2Qi
IHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHht
bG5zOnRucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpyZWdpbmZvIj4NCsKgwqDCoMKgwqDCoMKg
wqANCsKgwqDCoMKgwqDCoMKgwqA8dG5zOnJlZ2lzdHJhdGlvbiBpZD0iMTIzNDU2Nzg5MCIgYW9y
PSJzaXA6bWFpbHRvOisxNTU1NjY2Nzc3N0BpbXMubW5jMDAxLm1jYzAwMS4zZ3BwbmV0d29ya3Mu
b3JnIj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDx0bnM6Y29udGFjdCBldmVudD0icmVnaXN0
ZXJlZCIgaWQ9IjIzNDU2Nzg5MDEiIGR1cmF0aW9uLXJlZ2lzdGVyZWQ9IjQyOTQ5NjcyOTUiDQrC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjc2VxPSI0Mjk0OTY3Mjk1IiByZXRyeS1h
ZnRlcj0iNDI5NDk2NzI5NSIgcT0iMCIgc3RhdGU9ImFjdGl2ZSINCsKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgIGNhbGxpZD0iU3RyaW5nIiBleHBpcmVzPSI0Mjk0OTY3Mjk1Ij4NCsKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8dG5zOnVyaT5zaXA6KzE1NTU2NjY3Nzc3QFsyMDAx
OjBkYjg6ODVhMzowMDAwOjAwMDA6OGEyZTowMzcwOmFhYWFdPC90bnM6dXJpPg0KwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoDx0bnM6ZGlzcGxheS1uYW1lIHhtbDpsYW5nPSJlbi11cyI+U3Ry
aW5nPC90bnM6ZGlzcGxheS1uYW1lPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDx0bnM6
dW5rbm93bi1wYXJhbSBuYW1lPSJTdHJpbmciPlN0cmluZzwvdG5zOnVua25vd24tcGFyYW0+DQrC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8L3Ruczpjb250YWN0Pg0KwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgPHRuczpjb250YWN0IGV2ZW50PSJyZWdpc3RlcmVkIiBpZD0iMjM0NTY3ODkwMSIgZHVy
YXRpb24tcmVnaXN0ZXJlZD0iNDI5NDk2NzI5NSINCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIGNzZXE9IjQyOTQ5NjcyOTUiIHJldHJ5LWFmdGVyPSI0Mjk0OTY3Mjk1IiBxPSIwIiBz
dGF0ZT0iYWN0aXZlIg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY2FsbGlkPSJT
dHJpbmciIGV4cGlyZXM9IjQyOTQ5NjcyOTUiPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oDx0bnM6dXJpPnNpcDorMTU1NTY2Njc3NzdAWzIwMDE6MGRiODo4NWEzOjAwMDA6MDAwMDo4YTJl
OjAzNzA6YmJiYl08L3Ruczp1cmk+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHRuczpk
aXNwbGF5LW5hbWUgeG1sOmxhbmc9ImVuLXVzIj5TdHJpbmc8L3RuczpkaXNwbGF5LW5hbWU+DQrC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHRuczp1bmtub3duLXBhcmFtIG5hbWU9IlN0cmlu
ZyI+U3RyaW5nPC90bnM6dW5rbm93bi1wYXJhbT4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDwv
dG5zOmNvbnRhY3Q+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8dG5zOmNvbnRhY3QgZXZlbnQ9
InJlZ2lzdGVyZWQiIGlkPSIyMzQ1Njc4OTAxIiBkdXJhdGlvbi1yZWdpc3RlcmVkPSI0Mjk0OTY3
Mjk1Ig0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY3NlcT0iNDI5NDk2NzI5NSIg
cmV0cnktYWZ0ZXI9IjQyOTQ5NjcyOTUiIHE9IjAiIHN0YXRlPSJhY3RpdmUiDQrCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjYWxsaWQ9IlN0cmluZyIgZXhwaXJlcz0iNDI5NDk2NzI5
NSI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHRuczp1cmk+c2lwOisxNTU1NjY2Nzc3
N0BbMjAwMTowZGI4Ojg1YTM6MDAwMDowMDAwOjhhMmU6MDM3MDpjY2NjXTwvdG5zOnVyaT4NCsKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8dG5zOmRpc3BsYXktbmFtZSB4bWw6bGFuZz0iZW4t
dXMiPlN0cmluZzwvdG5zOmRpc3BsYXktbmFtZT4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqA8dG5zOnVua25vd24tcGFyYW0gbmFtZT0iU3RyaW5nIj5TdHJpbmc8L3Ruczp1bmtub3duLXBh
cmFtPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPC90bnM6Y29udGFjdD4NCsKgwqDCoMKgwqDC
oMKgwqA8L3RuczpyZWdpc3RyYXRpb24+DQrCoMKgwqDCoMKgwqDCoMKgwqANCsKgwqDCoMKgwqDC
oMKgwqA8dG5zOnJlZ2lzdHJhdGlvbiBpZD0iMTIzNDU2Nzg5MCIgYW9yPSJ0ZWw6KzE1NTU2NjY3
Nzc3Ij4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDx0bnM6Y29udGFjdCBldmVudD0icmVnaXN0
ZXJlZCIgaWQ9IjIzNDU2Nzg5MDEiIGR1cmF0aW9uLXJlZ2lzdGVyZWQ9IjQyOTQ5NjcyOTUiDQrC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjc2VxPSI0Mjk0OTY3Mjk1IiByZXRyeS1h
ZnRlcj0iNDI5NDk2NzI5NSIgcT0iMCIgc3RhdGU9ImFjdGl2ZSINCsKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgIGNhbGxpZD0iU3RyaW5nIiBleHBpcmVzPSI0Mjk0OTY3Mjk1Ij4NCsKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8dG5zOnVyaT5zaXA6KzE1NTU2NjY3Nzc3QFsyMDAx
OjBkYjg6ODVhMzowMDAwOjAwMDA6OGEyZTowMzcwOmFhYWFdPC90bnM6dXJpPg0KwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoDx0bnM6ZGlzcGxheS1uYW1lIHhtbDpsYW5nPSJlbi11cyI+U3Ry
aW5nPC90bnM6ZGlzcGxheS1uYW1lPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDx0bnM6
dW5rbm93bi1wYXJhbSBuYW1lPSJTdHJpbmciPlN0cmluZzwvdG5zOnVua25vd24tcGFyYW0+DQrC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8L3Ruczpjb250YWN0Pg0KwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgPHRuczpjb250YWN0IGV2ZW50PSJyZWdpc3RlcmVkIiBpZD0iMjM0NTY3ODkwMSIgZHVy
YXRpb24tcmVnaXN0ZXJlZD0iNDI5NDk2NzI5NSINCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIGNzZXE9IjQyOTQ5NjcyOTUiIHJldHJ5LWFmdGVyPSI0Mjk0OTY3Mjk1IiBxPSIwIiBz
dGF0ZT0iYWN0aXZlIg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY2FsbGlkPSJT
dHJpbmciIGV4cGlyZXM9IjQyOTQ5NjcyOTUiPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oDx0bnM6dXJpPnNpcDorMTU1NTY2Njc3NzdAWzIwMDE6MGRiODo4NWEzOjAwMDA6MDAwMDo4YTJl
OjAzNzA6YmJiYl08L3Ruczp1cmk+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHRuczpk
aXNwbGF5LW5hbWUgeG1sOmxhbmc9ImVuLXVzIj5TdHJpbmc8L3RuczpkaXNwbGF5LW5hbWU+DQrC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHRuczp1bmtub3duLXBhcmFtIG5hbWU9IlN0cmlu
ZyI+U3RyaW5nPC90bnM6dW5rbm93bi1wYXJhbT4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDwv
dG5zOmNvbnRhY3Q+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8dG5zOmNvbnRhY3QgZXZlbnQ9
InJlZ2lzdGVyZWQiIGlkPSIyMzQ1Njc4OTAxIiBkdXJhdGlvbi1yZWdpc3RlcmVkPSI0Mjk0OTY3
Mjk1Ig0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY3NlcT0iNDI5NDk2NzI5NSIg
cmV0cnktYWZ0ZXI9IjQyOTQ5NjcyOTUiIHE9IjAiIHN0YXRlPSJhY3RpdmUiDQrCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjYWxsaWQ9IlN0cmluZyIgZXhwaXJlcz0iNDI5NDk2NzI5
NSI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHRuczp1cmk+c2lwOisxNTU1NjY2Nzc3
N0BbMjAwMTowZGI4Ojg1YTM6MDAwMDowMDAwOjhhMmU6MDM3MDpjY2NjXTwvdG5zOnVyaT4NCsKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8dG5zOmRpc3BsYXktbmFtZSB4bWw6bGFuZz0iZW4t
dXMiPlN0cmluZzwvdG5zOmRpc3BsYXktbmFtZT4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqA8dG5zOnVua25vd24tcGFyYW0gbmFtZT0iU3RyaW5nIj5TdHJpbmc8L3Ruczp1bmtub3duLXBh
cmFtPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPC90bnM6Y29udGFjdD4NCsKgwqDCoMKgwqDC
oMKgwqA8L3RuczpyZWdpc3RyYXRpb24+DQrCoMKgwqDCoMKgwqDCoMKgDQrCoMKgwqDCoMKgwqDC
oMKgPHRuczpyZWdpc3RyYXRpb24gaWQ9IjEyMzQ1Njc4OTAiIGFvcj0ic2lwOm1haWx0bzorMTY2
Njc3Nzg4ODhAaW1zLm1uYzAwMS5tY2MwMDEuM2dwcG5ldHdvcmtzLm9yZyI+DQrCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqA8dG5zOmNvbnRhY3QgZXZlbnQ9InJlZ2lzdGVyZWQiIGlkPSIyMzQ1Njc4
OTAxIiBkdXJhdGlvbi1yZWdpc3RlcmVkPSI0Mjk0OTY3Mjk1Ig0KwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgY3NlcT0iNDI5NDk2NzI5NSIgcmV0cnktYWZ0ZXI9IjQyOTQ5NjcyOTUi
IHE9IjAiIHN0YXRlPSJhY3RpdmUiDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBj
YWxsaWQ9IlN0cmluZyIgZXhwaXJlcz0iNDI5NDk2NzI5NSI+DQrCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgPHRuczp1cmk+c2lwOisxNTU1NjY2Nzc3N0BbMjAwMTowZGI4Ojg1YTM6MDAwMDow
MDAwOjhhMmU6MDM3MDphYWFhXTwvdG5zOnVyaT4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqA8dG5zOmRpc3BsYXktbmFtZSB4bWw6bGFuZz0iZW4tdXMiPlN0cmluZzwvdG5zOmRpc3BsYXkt
bmFtZT4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8dG5zOnVua25vd24tcGFyYW0gbmFt
ZT0iU3RyaW5nIj5TdHJpbmc8L3Ruczp1bmtub3duLXBhcmFtPg0KwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgPC90bnM6Y29udGFjdD4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDx0bnM6Y29udGFj
dCBldmVudD0icmVnaXN0ZXJlZCIgaWQ9IjIzNDU2Nzg5MDEiIGR1cmF0aW9uLXJlZ2lzdGVyZWQ9
IjQyOTQ5NjcyOTUiDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjc2VxPSI0Mjk0
OTY3Mjk1IiByZXRyeS1hZnRlcj0iNDI5NDk2NzI5NSIgcT0iMCIgc3RhdGU9ImFjdGl2ZSINCsKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGNhbGxpZD0iU3RyaW5nIiBleHBpcmVzPSI0
Mjk0OTY3Mjk1Ij4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8dG5zOnVyaT5zaXA6KzE1
NTU2NjY3Nzc3QFsyMDAxOjBkYjg6ODVhMzowMDAwOjAwMDA6OGEyZTowMzcwOmJiYmJdPC90bnM6
dXJpPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDx0bnM6ZGlzcGxheS1uYW1lIHhtbDps
YW5nPSJlbi11cyI+U3RyaW5nPC90bnM6ZGlzcGxheS1uYW1lPg0KwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoDx0bnM6dW5rbm93bi1wYXJhbSBuYW1lPSJTdHJpbmciPlN0cmluZzwvdG5zOnVu
a25vd24tcGFyYW0+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8L3Ruczpjb250YWN0Pg0KwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgPHRuczpjb250YWN0IGV2ZW50PSJyZWdpc3RlcmVkIiBpZD0i
MjM0NTY3ODkwMSIgZHVyYXRpb24tcmVnaXN0ZXJlZD0iNDI5NDk2NzI5NSINCsKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgIGNzZXE9IjQyOTQ5NjcyOTUiIHJldHJ5LWFmdGVyPSI0Mjk0
OTY3Mjk1IiBxPSIwIiBzdGF0ZT0iYWN0aXZlIg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqAgY2FsbGlkPSJTdHJpbmciIGV4cGlyZXM9IjQyOTQ5NjcyOTUiPg0KwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoDx0bnM6dXJpPnNpcDorMTU1NTY2Njc3NzdAWzIwMDE6MGRiODo4NWEz
OjAwMDA6MDAwMDo4YTJlOjAzNzA6Y2NjY108L3Ruczp1cmk+DQrCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgPHRuczpkaXNwbGF5LW5hbWUgeG1sOmxhbmc9ImVuLXVzIj5TdHJpbmc8L3Ruczpk
aXNwbGF5LW5hbWU+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHRuczp1bmtub3duLXBh
cmFtIG5hbWU9IlN0cmluZyI+U3RyaW5nPC90bnM6dW5rbm93bi1wYXJhbT4NCsKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoDwvdG5zOmNvbnRhY3Q+DQrCoMKgwqDCoMKgwqDCoMKgPC90bnM6cmVnaXN0
cmF0aW9uPg0KwqDCoMKgwqDCoMKgwqDCoA0KwqDCoMKgwqDCoMKgwqDCoDx0bnM6cmVnaXN0cmF0
aW9uIGlkPSIxMjM0NTY3ODkwIiBhb3I9InRlbDorMTU1NTY2Njc3NzciPg0KwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgPHRuczpjb250YWN0IGV2ZW50PSJyZWdpc3RlcmVkIiBpZD0iMjM0NTY3ODkw
MSIgZHVyYXRpb24tcmVnaXN0ZXJlZD0iNDI5NDk2NzI5NSINCsKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIGNzZXE9IjQyOTQ5NjcyOTUiIHJldHJ5LWFmdGVyPSI0Mjk0OTY3Mjk1IiBx
PSIwIiBzdGF0ZT0iYWN0aXZlIg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY2Fs
bGlkPSJTdHJpbmciIGV4cGlyZXM9IjQyOTQ5NjcyOTUiPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoDx0bnM6dXJpPnNpcDorMTU1NTY2Njc3NzdAWzIwMDE6MGRiODo4NWEzOjAwMDA6MDAw
MDo4YTJlOjAzNzA6YWFhYV08L3Ruczp1cmk+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
PHRuczpkaXNwbGF5LW5hbWUgeG1sOmxhbmc9ImVuLXVzIj5TdHJpbmc8L3RuczpkaXNwbGF5LW5h
bWU+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHRuczp1bmtub3duLXBhcmFtIG5hbWU9
IlN0cmluZyI+U3RyaW5nPC90bnM6dW5rbm93bi1wYXJhbT4NCsKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoDwvdG5zOmNvbnRhY3Q+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8dG5zOmNvbnRhY3Qg
ZXZlbnQ9InJlZ2lzdGVyZWQiIGlkPSIyMzQ1Njc4OTAxIiBkdXJhdGlvbi1yZWdpc3RlcmVkPSI0
Mjk0OTY3Mjk1Ig0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY3NlcT0iNDI5NDk2
NzI5NSIgcmV0cnktYWZ0ZXI9IjQyOTQ5NjcyOTUiIHE9IjAiIHN0YXRlPSJhY3RpdmUiDQrCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjYWxsaWQ9IlN0cmluZyIgZXhwaXJlcz0iNDI5
NDk2NzI5NSI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHRuczp1cmk+c2lwOisxNTU1
NjY2Nzc3N0BbMjAwMTowZGI4Ojg1YTM6MDAwMDowMDAwOjhhMmU6MDM3MDpiYmJiXTwvdG5zOnVy
aT4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8dG5zOmRpc3BsYXktbmFtZSB4bWw6bGFu
Zz0iZW4tdXMiPlN0cmluZzwvdG5zOmRpc3BsYXktbmFtZT4NCsKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqA8dG5zOnVua25vd24tcGFyYW0gbmFtZT0iU3RyaW5nIj5TdHJpbmc8L3Ruczp1bmtu
b3duLXBhcmFtPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPC90bnM6Y29udGFjdD4NCsKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoDx0bnM6Y29udGFjdCBldmVudD0icmVnaXN0ZXJlZCIgaWQ9IjIz
NDU2Nzg5MDEiIGR1cmF0aW9uLXJlZ2lzdGVyZWQ9IjQyOTQ5NjcyOTUiDQrCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoCBjc2VxPSI0Mjk0OTY3Mjk1IiByZXRyeS1hZnRlcj0iNDI5NDk2
NzI5NSIgcT0iMCIgc3RhdGU9ImFjdGl2ZSINCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgIGNhbGxpZD0iU3RyaW5nIiBleHBpcmVzPSI0Mjk0OTY3Mjk1Ij4NCsKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqA8dG5zOnVyaT5zaXA6KzE1NTU2NjY3Nzc3QFsyMDAxOjBkYjg6ODVhMzow
MDAwOjAwMDA6OGEyZTowMzcwOmNjY2NdPC90bnM6dXJpPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoDx0bnM6ZGlzcGxheS1uYW1lIHhtbDpsYW5nPSJlbi11cyI+U3RyaW5nPC90bnM6ZGlz
cGxheS1uYW1lPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDx0bnM6dW5rbm93bi1wYXJh
bSBuYW1lPSJTdHJpbmciPlN0cmluZzwvdG5zOnVua25vd24tcGFyYW0+DQrCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqA8L3Ruczpjb250YWN0Pg0KwqDCoMKgwqDCoMKgwqDCoDwvdG5zOnJlZ2lzdHJh
dGlvbj4NCsKgwqDCoMKgwqDCoMKgwqA8L3RuczpyZWdpbmZvPg0KwqDCoMKgwqDCoMKgwqDCoA0K
wqDCoMKgwqDCoMKgwqDCoElmIHRoZSBudW1iZXIgb2YgcGhvbmUgbnVtYmVycyBhbmQvb3IgZGV2
aWNlcyBpbmNyZWFzZSwgdGhlIHBheWxvYWQgc2l6ZSB3aWxsIGdyb3cgcmF0aGVyIHJhcGlkbHku
DQrCoMKgwqDCoMKgwqDCoMKgDQrCoMKgwqDCoMKgwqDCoMKgT25lIGNhbiBvZiBjb3Vyc2UgZS5n
LiwgdXNlIG1lc3NhZ2UgY29tcHJlc3Npb24gdG8gcmVkdWNlIHRoZSBzaXplIG9mIHRoZSBwYXls
b2FkLCBidXQgaW4gbXkgb3BpbmlvbiB0aGUgcmVhbCBwcm9ibGVtIGlzIHRoZSBmYWN0IHRoYXQg
aW5mb3JtYXRpb24gaXMgZHVwbGljYXRlZC4NCsKgwqDCoMKgwqDCoMKgwqANCsKgwqDCoMKgwqDC
oMKgwqBXaGVuIGRpc2N1c3NpbmcgdGhpcyB3aXRoIHNvbWUgY29sbGVhZ3Vlcywgb25lIGlkZWEg
dGhhdCBjYW1lIHVwIHdhcyB0byB1c2UgcmVmZXJlbmNlczogc2VwYXJhdGUgdGhlICdjb250YWN0
IGVsZW1lbnRzJyBmcm9tIHRoZSAncmVnaXN0cmF0aW9uIGVsZW1lbnRzJywgYW5kIHRoZW4gc2lt
cGx5IHJlZmVyZW5jZSB0aGUgJ2NvbnRhY3QgZWxlbWVudHMnIGZyb20gd2l0aGluIHRoZSAncmVn
aXN0cmF0aW9uIGVsZW1lbnRzJy4NCsKgwqDCoMKgwqDCoMKgwqANCsKgwqDCoMKgwqDCoMKgwqBB
IHNpbXBsaWZpZWQgZXhhbXBsZSB3b3VsZCBsb29rIHNvbWV0aGluZyBsaWtlIChub3RlIHRoZSBu
ZXcgYW5jaG9yIGFuZCB0YXJnZXQgYXR0cmlidXRlcyk6DQrCoMKgwqDCoMKgwqDCoMKgDQrCoMKg
wqDCoMKgwqDCoMKgPGNvbnRhY3Q+IDx1cmk+SVAtQWRkcmVzczEgYW5jaG9yPSIxIjwvdXJpPjwv
Y29udGFjdD4NCsKgwqDCoMKgwqDCoMKgwqA8Y29udGFjdD4gPHVyaT5JUC1BZGRyZXNzMiBhbmNo
b3I9IjIiPC91cmk+PC9jb250YWN0Pg0KwqDCoMKgwqDCoMKgwqDCoDxjb250YWN0PiA8dXJpPklQ
LUFkZHJlc3MzIGFuY2hvcj0iMyI8L3VyaT48L2NvbnRhY3Q+DQrCoMKgwqDCoMKgwqDCoMKgPHJl
Z2lzdHJhdGlvbiBhb3I9c2lwOnBob25lX251bWJlcjEvU0lQIGlkPSIxIiBzdGF0ZT0iYWN0aXZl
Ij7CoA0KwqDCoMKgwqDCoMKgwqDCoAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIxIiAvPg0KwqDCoMKg
wqDCoMKgwqDCoAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIyIiAvPg0KwqDCoMKgwqDCoMKgwqDCoAk8
Y29udGFjdC1yZWYgdGFyZ2V0PSIzIiAvPg0KwqDCoMKgwqDCoMKgwqDCoDxyZWdpc3RyYXRpb24g
YW9yPXRlbDpwaG9uZV9udW1iZXIxL1RFTCBpZD0iMiIgc3RhdGU9ImFjdGl2ZSI+DQrCoMKgwqDC
oMKgwqDCoMKgCTxjb250YWN0LXJlZiB0YXJnZXQ9IjEiIC8+DQrCoMKgwqDCoMKgwqDCoMKgCTxj
b250YWN0LXJlZiB0YXJnZXQ9IjIiIC8+DQrCoMKgwqDCoMKgwqDCoMKgCTxjb250YWN0LXJlZiB0
YXJnZXQ9IjMiIC8+DQrCoMKgwqDCoMKgwqDCoMKgPHJlZ2lzdHJhdGlvbiBhb3I9c2lwOnBob25l
X251bWJlcjIvU0lQIGlkPSIxIiBzdGF0ZT0iYWN0aXZlIj4NCsKgwqDCoMKgwqDCoMKgwqAJPGNv
bnRhY3QtcmVmIHRhcmdldD0iMSIgLz4NCsKgwqDCoMKgwqDCoMKgwqAJPGNvbnRhY3QtcmVmIHRh
cmdldD0iMiIgLz4NCsKgwqDCoMKgwqDCoMKgwqAJPGNvbnRhY3QtcmVmIHRhcmdldD0iMyIgLz4N
CsKgwqDCoMKgwqDCoMKgwqA8cmVnaXN0cmF0aW9uIGFvcj10ZWw6cGhvbmVfbnVtYmVyMi9URUwg
aWQ9IjIiIHN0YXRlPSJhY3RpdmUiPg0KwqDCoMKgwqDCoMKgwqDCoAk8Y29udGFjdC1yZWYgdGFy
Z2V0PSIxIiAvPg0KwqDCoMKgwqDCoMKgwqDCoAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIyIiAvPg0K
wqDCoMKgwqDCoMKgwqDCoAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIzIiAvPg0KwqDCoMKgwqDCoMKg
wqDCoA0KwqDCoMKgwqDCoMKgwqDCoElmIHlvdSBhcHBseSB0aGlzIG9uIHRoZSBleGFtcGxlIGJh
c2VkIG9uIHRoZSBYTUwgc2NoZW1hIGluIFJGQyAzNjgwIHlvdSB3aWxsIHNlZSBhIHNpZ25pZmlj
YW50IHJlZHVjdGlvbiBpbiBzaXplOg0KwqDCoMKgwqDCoMKgwqDCoA0KwqDCoMKgwqDCoMKgwqDC
oDw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+DQrCoMKgwqDCoMKgwqDCoMKg
PCEtLVNhbXBsZSBYTUwgZmlsZSBnZW5lcmF0ZWQgYnkgWE1MU3B5IHYyMDA4IChodHRwOi8vd3d3
LmFsdG92YS5jb20pLS0+DQrCoMKgwqDCoMKgwqDCoMKgPHRuczpyZWdpbmZvIHN0YXRlPSJmdWxs
IiB2ZXJzaW9uPSIwIiB4c2k6c2NoZW1hTG9jYXRpb249InVybjppZXRmOnBhcmFtczp4bWw6bnM6
cmVnaW5mbyBVbnRpdGxlZDEueHNkIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEv
WE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp0bnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6cmVn
aW5mbyI+DQrCoMKgwqDCoMKgwqDCoMKgDQrCoMKgwqDCoMKgwqDCoMKgPHRuczpjb250YWN0IGV2
ZW50PSJyZWdpc3RlcmVkIiBhbmNob3I9IjEiIGlkPSIyMzQ1Njc4OTAxIiBkdXJhdGlvbi1yZWdp
c3RlcmVkPSI0Mjk0OTY3Mjk1Ig0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY3Nl
cT0iNDI5NDk2NzI5NSIgcmV0cnktYWZ0ZXI9IjQyOTQ5NjcyOTUiIHE9IjAiIHN0YXRlPSJhY3Rp
dmUiDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjYWxsaWQ9IlN0cmluZyIgZXhw
aXJlcz0iNDI5NDk2NzI5NSI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHRuczp1cmk+
c2lwOisxNTU1NjY2Nzc3N0BbMjAwMTowZGI4Ojg1YTM6MDAwMDowMDAwOjhhMmU6MDM3MDphYWFh
XTwvdG5zOnVyaT4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8dG5zOmRpc3BsYXktbmFt
ZSB4bWw6bGFuZz0iZW4tdXMiPlN0cmluZzwvdG5zOmRpc3BsYXktbmFtZT4NCsKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqA8dG5zOnVua25vd24tcGFyYW0gbmFtZT0iU3RyaW5nIj5TdHJpbmc8
L3Ruczp1bmtub3duLXBhcmFtPg0KwqDCoMKgwqDCoMKgwqDCoDwvdG5zOmNvbnRhY3Q+DQrCoMKg
wqDCoMKgwqDCoMKgPHRuczpjb250YWN0IGV2ZW50PSJyZWdpc3RlcmVkIiBhbmNob3I9IjIiIGlk
PSIyMzQ1Njc4OTAxIiBkdXJhdGlvbi1yZWdpc3RlcmVkPSI0Mjk0OTY3Mjk1Ig0KwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY3NlcT0iNDI5NDk2NzI5NSIgcmV0cnktYWZ0ZXI9IjQy
OTQ5NjcyOTUiIHE9IjAiIHN0YXRlPSJhY3RpdmUiDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCBjYWxsaWQ9IlN0cmluZyIgZXhwaXJlcz0iNDI5NDk2NzI5NSI+DQrCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgPHRuczp1cmk+c2lwOisxNTU1NjY2Nzc3N0BbMjAwMTowZGI4Ojg1
YTM6MDAwMDowMDAwOjhhMmU6MDM3MDpiYmJiXTwvdG5zOnVyaT4NCsKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqA8dG5zOmRpc3BsYXktbmFtZSB4bWw6bGFuZz0iZW4tdXMiPlN0cmluZzwvdG5z
OmRpc3BsYXktbmFtZT4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8dG5zOnVua25vd24t
cGFyYW0gbmFtZT0iU3RyaW5nIj5TdHJpbmc8L3Ruczp1bmtub3duLXBhcmFtPg0KwqDCoMKgwqDC
oMKgwqDCoDwvdG5zOmNvbnRhY3Q+DQrCoMKgwqDCoMKgwqDCoMKgPHRuczpjb250YWN0IGV2ZW50
PSJyZWdpc3RlcmVkIiBhbmNob3I9IjMiIGlkPSIyMzQ1Njc4OTAxIiBkdXJhdGlvbi1yZWdpc3Rl
cmVkPSI0Mjk0OTY3Mjk1Ig0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY3NlcT0i
NDI5NDk2NzI5NSIgcmV0cnktYWZ0ZXI9IjQyOTQ5NjcyOTUiIHE9IjAiIHN0YXRlPSJhY3RpdmUi
DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjYWxsaWQ9IlN0cmluZyIgZXhwaXJl
cz0iNDI5NDk2NzI5NSI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHRuczp1cmk+c2lw
OisxNTU1NjY2Nzc3N0BbMjAwMTowZGI4Ojg1YTM6MDAwMDowMDAwOjhhMmU6MDM3MDpjY2NjXTwv
dG5zOnVyaT4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8dG5zOmRpc3BsYXktbmFtZSB4
bWw6bGFuZz0iZW4tdXMiPlN0cmluZzwvdG5zOmRpc3BsYXktbmFtZT4NCsKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqA8dG5zOnVua25vd24tcGFyYW0gbmFtZT0iU3RyaW5nIj5TdHJpbmc8L3Ru
czp1bmtub3duLXBhcmFtPg0KwqDCoMKgwqDCoMKgwqDCoDwvdG5zOmNvbnRhY3Q+DQrCoMKgwqDC
oMKgwqDCoMKgDQrCoMKgwqDCoMKgwqDCoMKgPHRuczpyZWdpc3RyYXRpb24gaWQ9IjEyMzQ1Njc4
OTAiIGFvcj0ic2lwOm1haWx0bzorMTU1NTY2Njc3NzdAaW1zLm1uYzAwMS5tY2MwMDEuM2dwcG5l
dHdvcmtzLm9yZyI+DQrCoMKgwqDCoMKgwqDCoMKgCTxjb250YWN0LXJlZiB0YXJnZXQ9IjEiIC8+
DQrCoMKgwqDCoMKgwqDCoMKgCTxjb250YWN0LXJlZiB0YXJnZXQ9IjIiIC8+DQrCoMKgwqDCoMKg
wqDCoMKgCTxjb250YWN0LXJlZiB0YXJnZXQ9IjMiIC8+DQrCoMKgwqDCoMKgwqDCoMKgPC90bnM6
cmVnaXN0cmF0aW9uPsKgDQrCoMKgwqDCoMKgwqDCoMKgPHRuczpyZWdpc3RyYXRpb24gaWQ9IjEy
MzQ1Njc4OTAiIGFvcj0idGVsOisxNTU1NjY2Nzc3NyI+DQrCoMKgwqDCoMKgwqDCoMKgCTxjb250
YWN0LXJlZiB0YXJnZXQ9IjEiIC8+DQrCoMKgwqDCoMKgwqDCoMKgCTxjb250YWN0LXJlZiB0YXJn
ZXQ9IjIiIC8+DQrCoMKgwqDCoMKgwqDCoMKgCTxjb250YWN0LXJlZiB0YXJnZXQ9IjMiIC8+DQrC
oMKgwqDCoMKgwqDCoMKgPC90bnM6cmVnaXN0cmF0aW9uPg0KwqDCoMKgwqDCoMKgwqDCoDx0bnM6
cmVnaXN0cmF0aW9uIGlkPSIxMjM0NTY3ODkwIiBhb3I9InNpcDptYWlsdG86KzE2NjY3Nzc4ODg4
QGltcy5tbmMwMDEubWNjMDAxLjNncHBuZXR3b3Jrcy5vcmciPg0KwqDCoMKgwqDCoMKgwqDCoAk8
Y29udGFjdC1yZWYgdGFyZ2V0PSIxIiAvPg0KwqDCoMKgwqDCoMKgwqDCoAk8Y29udGFjdC1yZWYg
dGFyZ2V0PSIyIiAvPg0KwqDCoMKgwqDCoMKgwqDCoAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIzIiAv
Pg0KwqDCoMKgwqDCoMKgwqDCoDwvdG5zOnJlZ2lzdHJhdGlvbj4NCsKgwqDCoMKgwqDCoMKgwqA8
dG5zOnJlZ2lzdHJhdGlvbiBpZD0iMTIzNDU2Nzg5MCIgYW9yPSJ0ZWw6KzE1NTU2NjY3Nzc3Ij4N
CsKgwqDCoMKgwqDCoMKgwqAJPGNvbnRhY3QtcmVmIHRhcmdldD0iMSIgLz4NCsKgwqDCoMKgwqDC
oMKgwqAJPGNvbnRhY3QtcmVmIHRhcmdldD0iMiIgLz4NCsKgwqDCoMKgwqDCoMKgwqAJPGNvbnRh
Y3QtcmVmIHRhcmdldD0iMyIgLz4NCsKgwqDCoMKgwqDCoMKgwqA8L3RuczpyZWdpc3RyYXRpb24+
DQrCoMKgwqDCoMKgwqDCoMKgPC90bnM6cmVnaW5mbz4NCsKgwqDCoMKgwqDCoMKgwqANCg0KICAg
ICAgIEFzIGZhciBhcyBzdGFuZGFyZGl6YXRpb24gaXMgY29uY2VybmVkLCBJIGd1ZXNzIHRoaXMg
Y291bGQgYmUgZG9uZSBhcyBhbiBSRkMgMzY4MCB1cGRhdGUsIGJ5IGVpdGhlciBkZWZpbmluZyBh
biBhZGRpdGlvbmFsIHJlZy1ldmVudCBwYWNrYWdlIHdpdGggYSBuZXcgWE1MIHNjaGVtYSwgT1Ig
ZGVmaW5pbmcgYW4gYWRkaXRpb25hbCBYTUwgc2NoZW1hIGZvciB0aGUgZXhpc3RpbmcgcmVnLWV2
ZW50IHBhY2thZ2UgKGlmIHRoYXQgaXMgYWxsb3dlZCkuIEluIGVpdGhlciBjYXNlLCB0aGUgVUEg
b2J2aW91c2x5IG5lZWQgdG8gYmUgYWJsZSB0byBpbmRpY2F0ZSBzdXBwb3J0IG9mIHRoZSBuZXcg
c2NoZW1hLg0KDQrCoMKgwqDCoMKgwqDCoMKgQ29tbWVudHM/DQrCoMKgwqDCoMKgwqDCoMKgDQrC
oMKgwqDCoMKgwqDCoMKgUmVnYXJkcywNCsKgwqDCoMKgwqDCoMKgwqANCsKgwqDCoMKgwqDCoMKg
wqBDaHJpc3Rlcg0KwqDCoMKgwqDCoMKgwqDCoA0KDQoNCg==


From nobody Wed Mar 27 08:39:36 2019
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 2836A120003; Wed, 27 Mar 2019 08:39:27 -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.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: sipcore@ietf.org
Message-ID: <155370116706.10357.8194869788737081319@ietfa.amsl.com>
Date: Wed, 27 Mar 2019 08:39:27 -0700
Archived-At: 
Subject: [sipcore] I-D Action: draft-ietf-sipcore-rejected-04.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Mar 2019 15:39:27 -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 WG of the IETF.

        Title           : A Session Initiation Protocol (SIP) Response Code for Rejected Calls
        Authors         : Eric W. Burger
                          Bhavik Nagda
	Filename        : draft-ietf-sipcore-rejected-04.txt
	Pages           : 22
	Date            : 2019-03-27

Abstract:
   This document defines the 608 (Rejected) SIP response code.  This
   response code enables calling parties to learn that an intermediary
   rejected their call attempt.  The call will not be answered.  As a
   6xx code, the caller will be aware that future attempts to contact
   the same UAS will likely fail.  The present use case driving the need
   for the 608 response code is when the intermediary is an analytics
   engine.  In this case, the rejection is by a machine or other
   process.  This contrasts with the 607 (Unwanted) SIP response code,
   which a human at the target UAS indicated the call was not wanted.
   In some jurisdictions this distinction is important.  This document
   also defines the use of the Call-Info header in 608 responses to
   enable rejected callers to contact entities that blocked their calls
   in error.  This provides a remediation mechanism for legal callers
   that find their calls blocked.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-rejected-04
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rejected-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Mar 27 08:41:35 2019
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 2862D12000E for ; Wed, 27 Mar 2019 08:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Level: 
X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.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 jYyFbRO5blDJ for ; Wed, 27 Mar 2019 08:41:32 -0700 (PDT)
Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [198.46.93.79]) (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 D774812025D for ; Wed, 27 Mar 2019 08:41:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Message-Id:In-Reply-To:To:References:Date: Subject:Mime-Version:Content-Type:From:Sender:Reply-To:Cc: Content-Transfer-Encoding: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=JPpuYQUuq/5s30o68N+62X2ikcZn10ZYwsJggI66n2w=; b=nXnZ+YgfXrXLhigJnl3eEeYN0 6F3JeaSFo+h0Koxd/0pS5Z4qUQKDn79cFa7PtOolqf6gsD5aqDMFc6yASU3REaqO5KoeFfhDuV8To rzGhjBvN779nASjzF2Or0nz8DBNtZMbG0XrCXpdu+3a00cwnyhTf6l/1bWlDAkiZ9fd50=;
Received: from [174.204.14.136] (port=2512 helo=[192.168.43.104]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h9Ag5-000E1v-Dv for sipcore@ietf.org; Wed, 27 Mar 2019 08:41:31 -0700
From: Eric Burger 
Content-Type: multipart/signed; boundary="Apple-Mail=_A547433D-1858-4501-8650-9B78F1878BA1"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Wed, 27 Mar 2019 11:41:19 -0400
References: <155370116735.10357.14550485597454442062.idtracker@ietfa.amsl.com>
To: SIPCORE 
In-Reply-To: <155370116735.10357.14550485597454442062.idtracker@ietfa.amsl.com>
Message-Id: <6FADC6F0-A88A-43B8-90B2-2143834B5879@standardstrack.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [sipcore] New Version Notification for draft-ietf-sipcore-rejected-04.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Mar 2019 15:41:34 -0000

--Apple-Mail=_A547433D-1858-4501-8650-9B78F1878BA1
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D3A051DF-D88E-4E26-8A3C-6DF6385D5653"


--Apple-Mail=_D3A051DF-D88E-4E26-8A3C-6DF6385D5653
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Updated all instances of SHOULD xxx UNLESS yyy language to IF NOT yyy =
MUST xxx and took out my annual screed against SHOULD without UNLESS.

> On Mar 27, 2019, at 11:39 AM, internet-drafts@ietf.org wrote:
>=20
>=20
> A new version of I-D, draft-ietf-sipcore-rejected-04.txt
> has been successfully submitted by Eric W. Burger and posted to the
> IETF repository.
>=20
> Name:		draft-ietf-sipcore-rejected
> Revision:	04
> Title:		A Session Initiation Protocol (SIP) Response =
Code for Rejected Calls
> Document date:	2019-03-27
> Group:		sipcore
> Pages:		22
> URL:            =
https://www.ietf.org/internet-drafts/draft-ietf-sipcore-rejected-04.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/
> Htmlized:       =
https://tools.ietf.org/html/draft-ietf-sipcore-rejected-04
> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rejected-04
>=20
> Abstract:
>   This document defines the 608 (Rejected) SIP response code.  This
>   response code enables calling parties to learn that an intermediary
>   rejected their call attempt.  The call will not be answered.  As a
>   6xx code, the caller will be aware that future attempts to contact
>   the same UAS will likely fail.  The present use case driving the =
need
>   for the 608 response code is when the intermediary is an analytics
>   engine.  In this case, the rejection is by a machine or other
>   process.  This contrasts with the 607 (Unwanted) SIP response code,
>   which a human at the target UAS indicated the call was not wanted.
>   In some jurisdictions this distinction is important.  This document
>   also defines the use of the Call-Info header in 608 responses to
>   enable rejected callers to contact entities that blocked their calls
>   in error.  This provides a remediation mechanism for legal callers
>   that find their calls blocked.
>=20
>=20
>=20
>=20
> 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.
>=20
> The IETF Secretariat
>=20


--Apple-Mail=_D3A051DF-D88E-4E26-8A3C-6DF6385D5653
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Updated all instances of SHOULD xxx UNLESS yyy language to IF NOT =
yyy MUST xxx and took out my =
annual screed against SHOULD without UNLESS.

On Mar =
27, 2019, at 11:39 AM, internet-drafts@ietf.org wrote:


A new version of I-D, draft-ietf-sipcore-rejected-04.txt
has been successfully submitted by Eric W. Burger and posted =
to the
IETF repository.

Name:	=
	=
draft-ietf-sipcore-rejected
Revision:	04
Title:=
		=
A Session Initiation Protocol (SIP) Response Code for Rejected =
Calls
Document date:	2019-03-27
Group:=
		=
sipcore
Pages:		22
URL: =
           https://www.ietf.org/internet-drafts/draft-ietf-sipcore-rejecte=
d-04.txt
Status: =
        https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/
Htmlized:       https://tools.ietf.org/html/draft-ietf-sipcore-rejected-04<=
br class=3D"">Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-reject=
ed
Diff: =
          https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rejected=
-04

Abstract:
 =
  This document defines the 608 (Rejected) SIP response code. =
 This
   response code enables calling =
parties to learn that an intermediary
 =
  rejected their call attempt.  The call will not be =
answered.  As a
   6xx code, the caller =
will be aware that future attempts to contact
 =
  the same UAS will likely fail.  The present use case =
driving the need
   for the 608 response code is =
when the intermediary is an analytics
   engine. =
 In this case, the rejection is by a machine or other
 =
  process.  This contrasts with the 607 (Unwanted) SIP =
response code,
   which a human at the target =
UAS indicated the call was not wanted.
   In =
some jurisdictions this distinction is important.  This document
   also defines the use of the Call-Info header in =
608 responses to
   enable rejected callers to =
contact entities that blocked their calls
   in =
error.  This provides a remediation mechanism for legal callers
   that find their calls blocked.




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.

The IETF Secretariat


=

--Apple-Mail=_D3A051DF-D88E-4E26-8A3C-6DF6385D5653--

--Apple-Mail=_A547433D-1858-4501-8650-9B78F1878BA1
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEfEc/N7T7IfiAuDEHDDCGh758rskFAlybmZ8ACgkQDDCGh758
rslsug/9FE6l72z+1XEYXmhSfud9B0vLJCbJKzlIZadQo7BXGn4SytFTRRs3Dqk4
D91Gov2pnxf4oBIvoQTKywUhiiCvhYXQ+EZW5/b673a/2ghyA829rvVwX15vKlez
TDup5VU5TUs58HqbVbtgGWI1YuPsRJXMxGtHRLxzyUjRsJ4I/VdYcCefztuidn8f
0pJCTWJQ804i4aYUYOntVEWitogG2dXA8J80DdBm3txNmkVWTHCND3RuRLm2Hpn0
dPBSW1Oq7N9ZVTc48N/ta5HLq2XuJy8RZIabq4Nf2d6kInOsA67Ch0Y+NxNxwT9B
6EueM/c5/decIqJtBwIDgXCjUJdwPW6jtFfah0SBHR2V0hzx2Nb/Q7MgaZC3JV6t
TmTInXnisvZAFU/ydo8X3etBQqZcd6IE5SVIf6Ki/BKB+dz3SDUb7gwsWPv96TD2
O6dgdoxA3NOmX8vtNowHieyJB4yYL/CFPT1LhCp9GnxWZweAGALYiT+6J8ODNtIv
PJxksfNYX3mHy9jp4okHnvy3tb4bNOVjvzVH5l95mlYiiE3fVUCl7IfpooWg6CgQ
OK5+xzET1J7ZarmWoCv+Qjp2NvY9lMaAnKHewJ0aA71NWSp+dbJTsbFmNZj2v9ve
VzljULOydnXOvm24dHtecr+l5pat2lhPnqvhxEVsFsVAlIbwGnk=
=RuIk
-----END PGP SIGNATURE-----

--Apple-Mail=_A547433D-1858-4501-8650-9B78F1878BA1--


From nobody Wed Mar 27 09:18:39 2019
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 18DCA1202E5 for ; Wed, 27 Mar 2019 09:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 U23nKxOSc5VH for ; Wed, 27 Mar 2019 09:18:33 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70074.outbound.protection.outlook.com [40.107.7.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCE21202E4 for ; Wed, 27 Mar 2019 09:18:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2HyQgeKQp2WUSKZ4hRGwYsMEdkA//yD2flKEItKWsIM=; b=RVw6BdtxJwjXBSy5fdJxQSWmE1NcBl80rhztOkjL5m3rOOOVlRVW+8SBy7DLjCLyoKkGFMqI5eRu2xepluge6PWpx0psmiuNGC8dKUnkV76qLquTGfpn8F6LnXZejgo/q5MJlE6UYQh3nVk1x9HRbPPsi9HCT9eV0YXs9K4f+sc=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3228.eurprd07.prod.outlook.com (10.170.246.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.14; Wed, 27 Mar 2019 16:18:30 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1750.014; Wed, 27 Mar 2019 16:18:29 +0000
From: Christer Holmberg 
To: Eric Burger , SIPCORE 
Thread-Topic: [sipcore] New Version Notification for draft-ietf-sipcore-rejected-04.txt
Thread-Index: AQHU5LOVYpwqVzcj/kqOAsFHInHdFKYfyY2A
Date: Wed, 27 Mar 2019 16:18:29 +0000
Message-ID: <223874A0-4F48-4684-BC96-2F4B84F82C0E@ericsson.com>
References: <155370116735.10357.14550485597454442062.idtracker@ietfa.amsl.com> <6FADC6F0-A88A-43B8-90B2-2143834B5879@standardstrack.com>
In-Reply-To: <6FADC6F0-A88A-43B8-90B2-2143834B5879@standardstrack.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cc1203c6-0e45-499b-e034-08d6b2cfd9b1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3228; 
x-ms-traffictypediagnostic: HE1PR07MB3228:
x-ms-exchange-purlcount: 6
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0989A7979C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(39860400002)(366004)(346002)(136003)(189003)(199004)(58126008)(86362001)(106356001)(44832011)(6246003)(476003)(71190400001)(33656002)(6116002)(5660300002)(71200400001)(478600001)(105586002)(6306002)(53386004)(53936002)(2906002)(54896002)(25786009)(486006)(110136005)(7736002)(316002)(83716004)(2616005)(236005)(446003)(36756003)(76176011)(15650500001)(11346002)(2420400007)(6512007)(8676002)(68736007)(99286004)(14444005)(256004)(102836004)(229853002)(7110500001)(26005)(606006)(8936002)(6486002)(66066001)(6506007)(10710500007)(14454004)(186003)(81156014)(6436002)(81166006)(3846002)(97736004)(53546011)(966005)(66574012)(82746002)(21314003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3228; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 0X38S60iPN+1Wf6puQu5fZduF0MvZQ6/5uiSBMIJ+vchC7xHUoTWPpYb6KzvQTqC/mwKLJsroyQDGCVObYNi+3iwP7Cv3/zt7lYzwzi/H/TZkBkDQl9uWVYZG4WAJcQknX1j0LRSdlHYbh11QfwxDBNF2SI0FJBr81nwI1mM9H1FE5jE2s//OIMh26HG05RrmUlyU4g8P1mhV/ObQzCaYdbVF+9W0LGFZoS+HIdcpk2nt9Kbq1YLuFRUn870GZN66arJDIWiXS4e4dg1fiN8og6IEGG2yKnX85vg0Y55iXtEa8nWS6am3qqjI+hSQjnJAeXLcz8o7/Q+OVKAM4lzx7Hwx1Umh3PEA4pa/06VwkWatSDIi+ZQPGfWXJoLPoXOt5Ko7w4zQp2elfEtQkjsspDV3dQQj+vE+jfAQNXLAVo=
Content-Type: multipart/alternative; boundary="_000_223874A04F484684BC962F4B84F82C0Eericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cc1203c6-0e45-499b-e034-08d6b2cfd9b1
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2019 16:18:29.7950 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3228
Archived-At: 
Subject: Re: [sipcore] New Version Notification for draft-ietf-sipcore-rejected-04.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Mar 2019 16:18:37 -0000

--_000_223874A04F484684BC962F4B84F82C0Eericssoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgRXJpYywNCg0KSXQgc2VlbXMgbGlrZSB5b3UgaGF2ZW7igJl0IGZpeGVkIHRoZSBGZWF0dXJl
LUNhcHMgZXhhbXBsZXMsIGJhc2VkIG9uIHRoZSBlYXJsaWVyIGRpc2N1c3Npb24gKHRoZSBuYW1l
IG9mIHRoZSB0aHJlYWQgd2FzIOKAmFN5bnRheCBvZiBGZWF0dXJlLUNhcHMgaGVhZGVy4oCZLCBi
dXQgSSBndWVzcyB5b3Ugd2VyZSBub3QgbWFkZSBhd2FyZSB0aGF0IGl0IGFmZmVjdGVkIHRoZSBz
aXBjb3JlLXJlamVjdGVkIGRyYWZ0KS4NCg0KVGhlIGNvcnJlY3Qgd2F5IGlzOiBGZWF0dXJlLUNh
cHM6ICo7K3NpcC42MDgNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogc2lwY29yZSA8
c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgImVidXJnZXJAc3RhbmRhcmRz
dHJhY2suY29tIiA8ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20+DQpEYXRlOiBXZWRuZXNkYXks
IDI3IE1hcmNoIDIwMTkgYXQgMTcuNDENClRvOiAic2lwY29yZUBpZXRmLm9yZyIgPHNpcGNvcmVA
aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv
biBmb3IgZHJhZnQtaWV0Zi1zaXBjb3JlLXJlamVjdGVkLTA0LnR4dA0KDQpVcGRhdGVkIGFsbCBp
bnN0YW5jZXMgb2YgU0hPVUxEIHh4eCBVTkxFU1MgeXl5IGxhbmd1YWdlIHRvIElGIE5PVCB5eXkg
TVVTVCB4eHggYW5kIHRvb2sgb3V0IG15IGFubnVhbCBzY3JlZWQgYWdhaW5zdCBTSE9VTEQgd2l0
aG91dCBVTkxFU1MuDQoNCg0KT24gTWFyIDI3LCAyMDE5LCBhdCAxMTozOSBBTSwgaW50ZXJuZXQt
ZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0K
DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXNpcGNvcmUtcmVqZWN0ZWQtMDQu
dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEVyaWMgVy4gQnVyZ2VyIGFu
ZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6IGRyYWZ0LWlldGYtc2lw
Y29yZS1yZWplY3RlZA0KUmV2aXNpb246IDA0DQpUaXRsZTogQSBTZXNzaW9uIEluaXRpYXRpb24g
UHJvdG9jb2wgKFNJUCkgUmVzcG9uc2UgQ29kZSBmb3IgUmVqZWN0ZWQgQ2FsbHMNCkRvY3VtZW50
IGRhdGU6IDIwMTktMDMtMjcNCkdyb3VwOiBzaXBjb3JlDQpQYWdlczogMjINClVSTDogICAgICAg
ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1zaXBj
b3JlLXJlamVjdGVkLTA0LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2lwY29yZS1yZWplY3RlZC8NCkh0bWxpemVkOiAgICAg
ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zaXBjb3JlLXJlamVjdGVk
LTA0DQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt
bC9kcmFmdC1pZXRmLXNpcGNvcmUtcmVqZWN0ZWQNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3
dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zaXBjb3JlLXJlamVjdGVkLTA0DQoN
CkFic3RyYWN0Og0KICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIDYwOCAoUmVqZWN0ZWQpIFNJ
UCByZXNwb25zZSBjb2RlLiAgVGhpcw0KICByZXNwb25zZSBjb2RlIGVuYWJsZXMgY2FsbGluZyBw
YXJ0aWVzIHRvIGxlYXJuIHRoYXQgYW4gaW50ZXJtZWRpYXJ5DQogIHJlamVjdGVkIHRoZWlyIGNh
bGwgYXR0ZW1wdC4gIFRoZSBjYWxsIHdpbGwgbm90IGJlIGFuc3dlcmVkLiAgQXMgYQ0KICA2eHgg
Y29kZSwgdGhlIGNhbGxlciB3aWxsIGJlIGF3YXJlIHRoYXQgZnV0dXJlIGF0dGVtcHRzIHRvIGNv
bnRhY3QNCiAgdGhlIHNhbWUgVUFTIHdpbGwgbGlrZWx5IGZhaWwuICBUaGUgcHJlc2VudCB1c2Ug
Y2FzZSBkcml2aW5nIHRoZSBuZWVkDQogIGZvciB0aGUgNjA4IHJlc3BvbnNlIGNvZGUgaXMgd2hl
biB0aGUgaW50ZXJtZWRpYXJ5IGlzIGFuIGFuYWx5dGljcw0KICBlbmdpbmUuICBJbiB0aGlzIGNh
c2UsIHRoZSByZWplY3Rpb24gaXMgYnkgYSBtYWNoaW5lIG9yIG90aGVyDQogIHByb2Nlc3MuICBU
aGlzIGNvbnRyYXN0cyB3aXRoIHRoZSA2MDcgKFVud2FudGVkKSBTSVAgcmVzcG9uc2UgY29kZSwN
CiAgd2hpY2ggYSBodW1hbiBhdCB0aGUgdGFyZ2V0IFVBUyBpbmRpY2F0ZWQgdGhlIGNhbGwgd2Fz
IG5vdCB3YW50ZWQuDQogIEluIHNvbWUganVyaXNkaWN0aW9ucyB0aGlzIGRpc3RpbmN0aW9uIGlz
IGltcG9ydGFudC4gIFRoaXMgZG9jdW1lbnQNCiAgYWxzbyBkZWZpbmVzIHRoZSB1c2Ugb2YgdGhl
IENhbGwtSW5mbyBoZWFkZXIgaW4gNjA4IHJlc3BvbnNlcyB0bw0KICBlbmFibGUgcmVqZWN0ZWQg
Y2FsbGVycyB0byBjb250YWN0IGVudGl0aWVzIHRoYXQgYmxvY2tlZCB0aGVpciBjYWxscw0KICBp
biBlcnJvci4gIFRoaXMgcHJvdmlkZXMgYSByZW1lZGlhdGlvbiBtZWNoYW5pc20gZm9yIGxlZ2Fs
IGNhbGxlcnMNCiAgdGhhdCBmaW5kIHRoZWlyIGNhbGxzIGJsb2NrZWQuDQoNCg0KDQoNClBsZWFz
ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l
IG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh
dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KVGhl
IElFVEYgU2VjcmV0YXJpYXQNCg0KDQo=

--_000_223874A04F484684BC962F4B84F82C0Eericssoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv
bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6
bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207
DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt
c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5h
cHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkVt
YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh
dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44
NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT
ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkkiIGxpbms9ImJs
dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkhpIEVyaWMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIj5JdCBzZWVtcyBsaWtlIHlvdSBoYXZlbuKAmXQgZml4ZWQgdGhlIEZlYXR1cmUtQ2Fw
cyBleGFtcGxlcywgYmFzZWQgb24gdGhlIGVhcmxpZXIgZGlzY3Vzc2lvbiAodGhlIG5hbWUgb2Yg
dGhlIHRocmVhZCB3YXMg4oCYU3ludGF4IG9mIEZlYXR1cmUtQ2FwcyBoZWFkZXLigJksIGJ1dCBJ
IGd1ZXNzIHlvdSB3ZXJlIG5vdCBtYWRlIGF3YXJlIHRoYXQgaXQgYWZmZWN0ZWQgdGhlIHNpcGNv
cmUtcmVqZWN0ZWQNCiBkcmFmdCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgY29ycmVjdCB3YXkg
aXM6IEZlYXR1cmUtQ2FwczogKjsmIzQzO3NpcC42MDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2Fy
ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0
REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9z
cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+c2lwY29y
ZSAmbHQ7c2lwY29yZS1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7ZWJ1
cmdlckBzdGFuZGFyZHN0cmFjay5jb20mcXVvdDsgJmx0O2VidXJnZXJAc3RhbmRhcmRzdHJhY2su
Y29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIDI3IE1hcmNoIDIwMTkgYXQgMTcu
NDE8YnI+DQo8Yj5UbzogPC9iPiZxdW90O3NpcGNvcmVAaWV0Zi5vcmcmcXVvdDsgJmx0O3NpcGNv
cmVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc2lwY29yZV0gTmV3IFZl
cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXNpcGNvcmUtcmVqZWN0ZWQtMDQudHh0
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVw
ZGF0ZWQgYWxsIGluc3RhbmNlcyBvZiBTSE9VTEQgPGk+eHh4PC9pPiZuYnNwO1VOTEVTUyA8aT55
eXk8L2k+Jm5ic3A7bGFuZ3VhZ2UgdG8gSUYgTk9UDQo8aT55eXk8L2k+Jm5ic3A7TVVTVCA8aT54
eHg8L2k+IGFuZCB0b29rIG91dCBteSBhbm51YWwgc2NyZWVkIGFnYWluc3QgU0hPVUxEIHdpdGhv
dXQgVU5MRVNTLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
T24gTWFyIDI3LCAyMDE5LCBhdCAxMTozOSBBTSwgPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRy
YWZ0c0BpZXRmLm9yZyI+DQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0Ij48YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1zaXBj
b3JlLXJlamVjdGVkLTA0LnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg
YnkgRXJpYyBXLiBCdXJnZXIgYW5kIHBvc3RlZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnku
PGJyPg0KPGJyPg0KTmFtZTo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiA8L3NwYW4+ZHJh
ZnQtaWV0Zi1zaXBjb3JlLXJlamVjdGVkPGJyPg0KUmV2aXNpb246PHNwYW4gY2xhc3M9ImFwcGxl
LXRhYi1zcGFuIj4gPC9zcGFuPjA0PGJyPg0KVGl0bGU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1z
cGFuIj4gPC9zcGFuPkEgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIFJlc3BvbnNl
IENvZGUgZm9yIFJlamVjdGVkIENhbGxzPGJyPg0KRG9jdW1lbnQgZGF0ZTo8c3BhbiBjbGFzcz0i
YXBwbGUtdGFiLXNwYW4iPiA8L3NwYW4+MjAxOS0wMy0yNzxicj4NCkdyb3VwOjxzcGFuIGNsYXNz
PSJhcHBsZS10YWItc3BhbiI+IDwvc3Bhbj5zaXBjb3JlPGJyPg0KUGFnZXM6PHNwYW4gY2xhc3M9
ImFwcGxlLXRhYi1zcGFuIj4gPC9zcGFuPjIyPGJyPg0KVVJMOiAmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1zaXBjb3JlLXJl
amVjdGVkLTA0LnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0
LWlldGYtc2lwY29yZS1yZWplY3RlZC0wNC50eHQ8L2E+PGJyPg0KU3RhdHVzOiAmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL2Rh
dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNpcGNvcmUtcmVqZWN0ZWQvIj5odHRw
czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNpcGNvcmUtcmVqZWN0ZWQv
PC9hPjxicj4NCkh0bWxpemVkOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8
YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zaXBjb3JlLXJl
amVjdGVkLTA0Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zaXBjb3Jl
LXJlamVjdGVkLTA0PC9hPjxicj4NCkh0bWxpemVkOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s
L2RyYWZ0LWlldGYtc2lwY29yZS1yZWplY3RlZCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNpcGNvcmUtcmVqZWN0ZWQ8L2E+PGJyPg0KRGlmZjogJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc2lw
Y29yZS1yZWplY3RlZC0wNCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0
LWlldGYtc2lwY29yZS1yZWplY3RlZC0wNDwvYT48YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQom
bmJzcDsmbmJzcDtUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIDYwOCAoUmVqZWN0ZWQpIFNJUCBy
ZXNwb25zZSBjb2RlLiAmbmJzcDtUaGlzPGJyPg0KJm5ic3A7Jm5ic3A7cmVzcG9uc2UgY29kZSBl
bmFibGVzIGNhbGxpbmcgcGFydGllcyB0byBsZWFybiB0aGF0IGFuIGludGVybWVkaWFyeTxicj4N
CiZuYnNwOyZuYnNwO3JlamVjdGVkIHRoZWlyIGNhbGwgYXR0ZW1wdC4gJm5ic3A7VGhlIGNhbGwg
d2lsbCBub3QgYmUgYW5zd2VyZWQuICZuYnNwO0FzIGE8YnI+DQombmJzcDsmbmJzcDs2eHggY29k
ZSwgdGhlIGNhbGxlciB3aWxsIGJlIGF3YXJlIHRoYXQgZnV0dXJlIGF0dGVtcHRzIHRvIGNvbnRh
Y3Q8YnI+DQombmJzcDsmbmJzcDt0aGUgc2FtZSBVQVMgd2lsbCBsaWtlbHkgZmFpbC4gJm5ic3A7
VGhlIHByZXNlbnQgdXNlIGNhc2UgZHJpdmluZyB0aGUgbmVlZDxicj4NCiZuYnNwOyZuYnNwO2Zv
ciB0aGUgNjA4IHJlc3BvbnNlIGNvZGUgaXMgd2hlbiB0aGUgaW50ZXJtZWRpYXJ5IGlzIGFuIGFu
YWx5dGljczxicj4NCiZuYnNwOyZuYnNwO2VuZ2luZS4gJm5ic3A7SW4gdGhpcyBjYXNlLCB0aGUg
cmVqZWN0aW9uIGlzIGJ5IGEgbWFjaGluZSBvciBvdGhlcjxicj4NCiZuYnNwOyZuYnNwO3Byb2Nl
c3MuICZuYnNwO1RoaXMgY29udHJhc3RzIHdpdGggdGhlIDYwNyAoVW53YW50ZWQpIFNJUCByZXNw
b25zZSBjb2RlLDxicj4NCiZuYnNwOyZuYnNwO3doaWNoIGEgaHVtYW4gYXQgdGhlIHRhcmdldCBV
QVMgaW5kaWNhdGVkIHRoZSBjYWxsIHdhcyBub3Qgd2FudGVkLjxicj4NCiZuYnNwOyZuYnNwO0lu
IHNvbWUganVyaXNkaWN0aW9ucyB0aGlzIGRpc3RpbmN0aW9uIGlzIGltcG9ydGFudC4gJm5ic3A7
VGhpcyBkb2N1bWVudDxicj4NCiZuYnNwOyZuYnNwO2Fsc28gZGVmaW5lcyB0aGUgdXNlIG9mIHRo
ZSBDYWxsLUluZm8gaGVhZGVyIGluIDYwOCByZXNwb25zZXMgdG88YnI+DQombmJzcDsmbmJzcDtl
bmFibGUgcmVqZWN0ZWQgY2FsbGVycyB0byBjb250YWN0IGVudGl0aWVzIHRoYXQgYmxvY2tlZCB0
aGVpciBjYWxsczxicj4NCiZuYnNwOyZuYnNwO2luIGVycm9yLiAmbmJzcDtUaGlzIHByb3ZpZGVz
IGEgcmVtZWRpYXRpb24gbWVjaGFuaXNtIGZvciBsZWdhbCBjYWxsZXJzPGJyPg0KJm5ic3A7Jm5i
c3A7dGhhdCBmaW5kIHRoZWlyIGNhbGxzIGJsb2NrZWQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K
PGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy
b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u
IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn
Ij4NCnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
Ym9keT4NCjwvaHRtbD4NCg==

--_000_223874A04F484684BC962F4B84F82C0Eericssoncom_--


From nobody Wed Mar 27 09:34:47 2019
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 3ED97120370 for ; Wed, 27 Mar 2019 09:34:34 -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, 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 qgrCKsZ3xz5q for ; Wed, 27 Mar 2019 09:34:30 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4117A120302 for ; Wed, 27 Mar 2019 09:34:30 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (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.14.7/8.12.4) with ESMTP id x2RGYRPO007931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 27 Mar 2019 12:34:28 -0400
To: sipcore@ietf.org
References: <97159F5B-8C69-4B89-A25F-39F95ED57027@ericsson.com>
From: Paul Kyzivat 
Message-ID: 
Date: Wed, 27 Mar 2019 12:34:27 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <97159F5B-8C69-4B89-A25F-39F95ED57027@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [sipcore] reg-event issue with multi-identity/multi-device
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Mar 2019 16:34:41 -0000

Hi Christer,

I understand the problem. But I think we need to assess whether the 
problem is severe enough to justify the effort of deploying a solution. 
In any case I guess a solution would have to include backward 
compatibility, so it would only be applied if both client and server 
support it as an extension.

The solution you outline is straightforward. But if doing something it 
might be better to just do general compression. I think there are 
already MIME types for carrying compressed data. I don't know whether 
they are suitable here, but if so it might mean off-the-shelf code is 
available.

	Thanks,
	Paul

On 3/27/19 8:31 AM, Christer Holmberg wrote:
>        Hi,
>          
>          3GPP defines ”multi identity” and ”multi devices” concepts, which means that:
>          
>          1) A user can have multiple phone numbers; and
>          2) A user can have multiple devices, each of which can be reached with any of those phone numbers
>          
>          Assume a user has:
>          
>          1) 2 phone numbers, each with a SIP URI and a tel URI representation ("phone_number1/SIP", "phone_number1/TEL", "phone_number2/SIP" and "phone_number2/TEL")
>          2) Different devices, each with a different contact IP address ("IP-Address1", "IP-Address2" and "IP-Address3")
>          
>          A simplified reg-event notification would look like this:
>          
>          
>           	 IP-Address1
>           	 IP-Address2
>           	 IP-Address3
>          
>           	 IP-Address1
>           	 IP-Address2
>           	 IP-Address3
>          
>           	 IP-Address1
>           	 IP-Address2
>           	 IP-Address3
>          
>           	 IP-Address1
>           	 IP-Address2
>           	 IP-Address3
>          
>          As you can see, the contact information is duplicated many times.
>          
>          Using an example based on the XML schema in RFC 3680 shows that the payload can get very big (I am using empty lines for readability):
>          
>          
>          
>          
>          
>          
>                                 cseq="4294967295" retry-after="4294967295" q="0" state="active"
>                   callid="String" expires="4294967295">
>                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:aaaa]
>                String
>                String
>              
>                                 cseq="4294967295" retry-after="4294967295" q="0" state="active"
>                   callid="String" expires="4294967295">
>                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:bbbb]
>                String
>                String
>              
>                                 cseq="4294967295" retry-after="4294967295" q="0" state="active"
>                   callid="String" expires="4294967295">
>                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:cccc]
>                String
>                String
>              
>          
>           
>          
>                                 cseq="4294967295" retry-after="4294967295" q="0" state="active"
>                   callid="String" expires="4294967295">
>                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:aaaa]
>                String
>                String
>              
>                                 cseq="4294967295" retry-after="4294967295" q="0" state="active"
>                   callid="String" expires="4294967295">
>                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:bbbb]
>                String
>                String
>              
>                                 cseq="4294967295" retry-after="4294967295" q="0" state="active"
>                   callid="String" expires="4294967295">
>                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:cccc]
>                String
>                String
>              
>          
>          
>          
>                                 cseq="4294967295" retry-after="4294967295" q="0" state="active"
>                   callid="String" expires="4294967295">
>                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:aaaa]
>                String
>                String
>              
>                                 cseq="4294967295" retry-after="4294967295" q="0" state="active"
>                   callid="String" expires="4294967295">
>                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:bbbb]
>                String
>                String
>              
>                                 cseq="4294967295" retry-after="4294967295" q="0" state="active"
>                   callid="String" expires="4294967295">
>                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:cccc]
>                String
>                String
>              
>          
>          
>          
>                                 cseq="4294967295" retry-after="4294967295" q="0" state="active"
>                   callid="String" expires="4294967295">
>                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:aaaa]
>                String
>                String
>              
>                                 cseq="4294967295" retry-after="4294967295" q="0" state="active"
>                   callid="String" expires="4294967295">
>                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:bbbb]
>                String
>                String
>              
>                                 cseq="4294967295" retry-after="4294967295" q="0" state="active"
>                   callid="String" expires="4294967295">
>                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:cccc]
>                String
>                String
>              
>          
>          
>          
>          If the number of phone numbers and/or devices increase, the payload size will grow rather rapidly.
>          
>          One can of course e.g., use message compression to reduce the size of the payload, but in my opinion the real problem is the fact that information is duplicated.
>          
>          When discussing this with some colleagues, one idea that came up was to use references: separate the 'contact elements' from the 'registration elements', and then simply reference the 'contact elements' from within the 'registration elements'.
>          
>          A simplified example would look something like (note the new anchor and target attributes):
>          
>           IP-Address1 anchor="1"
>           IP-Address2 anchor="2"
>           IP-Address3 anchor="3"
>          
>          	
>          	
>          	
>          
>          	
>          	
>          	
>          
>          	
>          	
>          	
>          
>          	
>          	
>          	
>          
>          If you apply this on the example based on the XML schema in RFC 3680 you will see a significant reduction in size:
>          
>          
>          
>          
>          
>                             cseq="4294967295" retry-after="4294967295" q="0" state="active"
>                   callid="String" expires="4294967295">
>                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:aaaa]
>                String
>                String
>          
>                             cseq="4294967295" retry-after="4294967295" q="0" state="active"
>                   callid="String" expires="4294967295">
>                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:bbbb]
>                String
>                String
>          
>                             cseq="4294967295" retry-after="4294967295" q="0" state="active"
>                   callid="String" expires="4294967295">
>                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:cccc]
>                String
>                String
>          
>          
>          
>          	
>          	
>          	
>          
>          
>          	
>          	
>          	
>          
>          
>          	
>          	
>          	
>          
>          
>          	
>          	
>          	
>          
>          
>          
> 
>         As far as standardization is concerned, I guess this could be done as an RFC 3680 update, by either defining an additional reg-event package with a new XML schema, OR defining an additional XML schema for the existing reg-event package (if that is allowed). In either case, the UA obviously need to be able to indicate support of the new schema.
> 
>          Comments?
>          
>          Regards,
>          
>          Christer
>          
> 
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 


From nobody Wed Mar 27 14:07:29 2019
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 14393120045 for ; Wed, 27 Mar 2019 14:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 tYhgDXOJ14FR for ; Wed, 27 Mar 2019 14:07:23 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70043.outbound.protection.outlook.com [40.107.7.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525DF120033 for ; Wed, 27 Mar 2019 14:07:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pJZ+t7LvipckvNJrM3fGg+LZMMxNnQW85xF/uwYHs8U=; b=H5MUrEBgwkbvpq4lLCyMfmWoKKfCgemPfU1xCn0luumDuE34Jshiiuaa/RiaQS7K87aiaWmM6NozYNKG2emilS+w9kmwoUTtviuWGbO8pOs8D32lJOPzOdq1s1saM674v5pDUEYjjaR2Pk+RSf5Fyw1ITxoDiDDHXCDgAmoENG8=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4252.eurprd07.prod.outlook.com (20.176.166.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Wed, 27 Mar 2019 21:07:20 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1750.014; Wed, 27 Mar 2019 21:07:20 +0000
From: Christer Holmberg 
To: Paul Kyzivat , "sipcore@ietf.org" 
Thread-Topic: [sipcore] reg-event issue with multi-identity/multi-device
Thread-Index: AQHU5Jj/Nwtdx+7wP0OSgkyGhayhm6YfrLGAgABtxIA=
Date: Wed, 27 Mar 2019 21:07:20 +0000
Message-ID: <678C20F0-8D1E-44A5-897F-70B521036B63@ericsson.com>
References: <97159F5B-8C69-4B89-A25F-39F95ED57027@ericsson.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
x-originating-ip: [87.93.95.44]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7fc61f37-6897-4eb0-fb35-08d6b2f83380
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4252; 
x-ms-traffictypediagnostic: HE1PR07MB4252:
x-ms-exchange-purlcount: 3
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0989A7979C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(366004)(136003)(396003)(189003)(199004)(5660300002)(86362001)(36756003)(81156014)(106356001)(6512007)(6436002)(8936002)(486006)(3846002)(71200400001)(6116002)(8676002)(2501003)(44832011)(105586002)(102836004)(81166006)(58126008)(11346002)(446003)(25786009)(33656002)(14454004)(6306002)(66066001)(76176011)(53546011)(2616005)(305945005)(476003)(6506007)(68736007)(53936002)(26005)(316002)(83716004)(966005)(186003)(71190400001)(7736002)(6246003)(110136005)(14444005)(229853002)(2171002)(99286004)(53946003)(2906002)(478600001)(256004)(97736004)(82746002)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4252; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: VTS2aCsp/tlTR/KHmJ7YoipAf/Yz+vgxzYeC3hYelUyHBiKF0vBP2nRePCYHxrsrmzdBIesYNOKzfs8ylH12vf0zA8mjfv+ZkPiagwBxsm+eWlI2Xkgq5a+41QR70nMUMka/5WZeRGQ8EG1f7HP0Cr2y3iRcaIGV+Itukb5cI2T22DelTJ+IrgWS5a+anv8NdTDEMw0LlsJQX4Zy35a6hCATo5jBKOxCHbC4RxtWmixeKzSPwTk1VNAjerr7KAUkjVQ36r3B0zrqQ3X+S8dRc+LglSrm9soU04tc1dVUBBiQHHkAFp7Mxbir0Ftx6WgEVr1m+NHOcuIMWYl0OoKE8Mfh8RhCg0TOxh5CdsK5R/fhpKIpH3hLQszt18HkTOBRcJpf5iezGWSrCj6w4r3og+ewoN/XZgHwsw72fHbl9jQ=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7fc61f37-6897-4eb0-fb35-08d6b2f83380
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2019 21:07:20.4838 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4252
Archived-At: 
Subject: Re: [sipcore] reg-event issue with multi-identity/multi-device
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Mar 2019 21:07:28 -0000

SGksDQogICAgDQo+ICAgIEkgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbS4gQnV0IEkgdGhpbmsgd2Ug
bmVlZCB0byBhc3Nlc3Mgd2hldGhlciB0aGUgDQo+ICAgIHByb2JsZW0gaXMgc2V2ZXJlIGVub3Vn
aCB0byBqdXN0aWZ5IHRoZSBlZmZvcnQgb2YgZGVwbG95aW5nIGEgc29sdXRpb24uIA0KDQpJdCBp
cyBjYXVzaW5nIHByb2JsZW1zLCBhbmQgcGVvcGxlIGhhdmUgYmVlbiBhc2tlZCB0byBmaW5kIGEg
c29sdXRpb24uIA0KDQo+ICAgIEluIGFueSBjYXNlIEkgZ3Vlc3MgYSBzb2x1dGlvbiB3b3VsZCBo
YXZlIHRvIGluY2x1ZGUgYmFja3dhcmQgDQo+ICAgIGNvbXBhdGliaWxpdHksIHNvIGl0IHdvdWxk
IG9ubHkgYmUgYXBwbGllZCBpZiBib3RoIGNsaWVudCBhbmQgc2VydmVyIA0KPiAgICBzdXBwb3J0
IGl0IGFzIGFuIGV4dGVuc2lvbi4NCiAgDQpTdXJlLiANCg0KPiAgICBUaGUgc29sdXRpb24geW91
IG91dGxpbmUgaXMgc3RyYWlnaHRmb3J3YXJkLiBCdXQgaWYgZG9pbmcgc29tZXRoaW5nIGl0IA0K
PiAgICBtaWdodCBiZSBiZXR0ZXIgdG8ganVzdCBkbyBnZW5lcmFsIGNvbXByZXNzaW9uLiBJIHRo
aW5rIHRoZXJlIGFyZSANCj4gICAgYWxyZWFkeSBNSU1FIHR5cGVzIGZvciBjYXJyeWluZyBjb21w
cmVzc2VkIGRhdGEuIEkgZG9uJ3Qga25vdyB3aGV0aGVyIA0KPiAgICB0aGV5IGFyZSBzdWl0YWJs
ZSBoZXJlLCBidXQgaWYgc28gaXQgbWlnaHQgbWVhbiBvZmYtdGhlLXNoZWxmIGNvZGUgaXMgDQo+
ICAgIGF2YWlsYWJsZS4NCiAgDQpFdmVuIGlmIHlvdSBjb21wcmVzcywgdGhlIHJlY2VpdmVyIHdp
bGwgc3RpbGwgaGF2ZSB0byBkZS1jb21wcmVzcywgcGFyc2UgYW5kIHByb2Nlc3MgZXZlcnl0aGlu
ZyBldGMsIHNvIGl0IHdhcyBub3Qgc2VlbiBhcyBhIGdvb2Qgc29sdXRpb24uDQoNClJlZ2FyZHMs
DQoNCkNocmlzdGVyDQoNCg0KDQogICAgDQogICAgT24gMy8yNy8xOSA4OjMxIEFNLCBDaHJpc3Rl
ciBIb2xtYmVyZyB3cm90ZToNCiAgICA+ICAgICAgICBIaSwNCiAgICA+ICAgICAgICAgIA0KICAg
ID4gICAgICAgICAgM0dQUCBkZWZpbmVzIOKAnW11bHRpIGlkZW50aXR54oCdIGFuZCDigJ1tdWx0
aSBkZXZpY2Vz4oCdIGNvbmNlcHRzLCB3aGljaCBtZWFucyB0aGF0Og0KICAgID4gICAgICAgICAg
DQogICAgPiAgICAgICAgICAxKSBBIHVzZXIgY2FuIGhhdmUgbXVsdGlwbGUgcGhvbmUgbnVtYmVy
czsgYW5kDQogICAgPiAgICAgICAgICAyKSBBIHVzZXIgY2FuIGhhdmUgbXVsdGlwbGUgZGV2aWNl
cywgZWFjaCBvZiB3aGljaCBjYW4gYmUgcmVhY2hlZCB3aXRoIGFueSBvZiB0aG9zZSBwaG9uZSBu
dW1iZXJzDQogICAgPiAgICAgICAgICANCiAgICA+ICAgICAgICAgIEFzc3VtZSBhIHVzZXIgaGFz
Og0KICAgID4gICAgICAgICAgDQogICAgPiAgICAgICAgICAxKSAyIHBob25lIG51bWJlcnMsIGVh
Y2ggd2l0aCBhIFNJUCBVUkkgYW5kIGEgdGVsIFVSSSByZXByZXNlbnRhdGlvbiAoInBob25lX251
bWJlcjEvU0lQIiwgInBob25lX251bWJlcjEvVEVMIiwgInBob25lX251bWJlcjIvU0lQIiBhbmQg
InBob25lX251bWJlcjIvVEVMIikNCiAgICA+ICAgICAgICAgIDIpIERpZmZlcmVudCBkZXZpY2Vz
LCBlYWNoIHdpdGggYSBkaWZmZXJlbnQgY29udGFjdCBJUCBhZGRyZXNzICgiSVAtQWRkcmVzczEi
LCAiSVAtQWRkcmVzczIiIGFuZCAiSVAtQWRkcmVzczMiKQ0KICAgID4gICAgICAgICAgDQogICAg
PiAgICAgICAgICBBIHNpbXBsaWZpZWQgcmVnLWV2ZW50IG5vdGlmaWNhdGlvbiB3b3VsZCBsb29r
IGxpa2UgdGhpczoNCiAgICA+ICAgICAgICAgIA0KICAgID4gICAgICAgICAgPHJlZ2lzdHJhdGlv
biBhb3I9c2lwOnBob25lX251bWJlcjEvU0lQIGlkPSIxIiBzdGF0ZT0iYWN0aXZlIj4NCiAgICA+
ICAgICAgICAgICAJPGNvbnRhY3Q+IDx1cmk+SVAtQWRkcmVzczE8L3VyaT48L2NvbnRhY3Q+DQog
ICAgPiAgICAgICAgICAgCTxjb250YWN0PiA8dXJpPklQLUFkZHJlc3MyPC91cmk+PC9jb250YWN0
Pg0KICAgID4gICAgICAgICAgIAk8Y29udGFjdD4gPHVyaT5JUC1BZGRyZXNzMzwvdXJpPjwvY29u
dGFjdD4NCiAgICA+ICAgICAgICAgIDxyZWdpc3RyYXRpb24gYW9yPXRlbDpwaG9uZV9udW1iZXIx
L1RFTCBpZD0iMiIgc3RhdGU9ImFjdGl2ZSI+DQogICAgPiAgICAgICAgICAgCTxjb250YWN0PiA8
dXJpPklQLUFkZHJlc3MxPC91cmk+PC9jb250YWN0Pg0KICAgID4gICAgICAgICAgIAk8Y29udGFj
dD4gPHVyaT5JUC1BZGRyZXNzMjwvdXJpPjwvY29udGFjdD4NCiAgICA+ICAgICAgICAgICAJPGNv
bnRhY3Q+IDx1cmk+SVAtQWRkcmVzczM8L3VyaT48L2NvbnRhY3Q+DQogICAgPiAgICAgICAgICA8
cmVnaXN0cmF0aW9uIGFvcj1zaXA6cGhvbmVfbnVtYmVyMi9TSVAgaWQ9IjEiIHN0YXRlPSJhY3Rp
dmUiPg0KICAgID4gICAgICAgICAgIAk8Y29udGFjdD4gPHVyaT5JUC1BZGRyZXNzMTwvdXJpPjwv
Y29udGFjdD4NCiAgICA+ICAgICAgICAgICAJPGNvbnRhY3Q+IDx1cmk+SVAtQWRkcmVzczI8L3Vy
aT48L2NvbnRhY3Q+DQogICAgPiAgICAgICAgICAgCTxjb250YWN0PiA8dXJpPklQLUFkZHJlc3Mz
PC91cmk+PC9jb250YWN0Pg0KICAgID4gICAgICAgICAgPHJlZ2lzdHJhdGlvbiBhb3I9dGVsOnBo
b25lX251bWJlcjIvVEVMIGlkPSIyIiBzdGF0ZT0iYWN0aXZlIj4NCiAgICA+ICAgICAgICAgICAJ
PGNvbnRhY3Q+IDx1cmk+SVAtQWRkcmVzczE8L3VyaT48L2NvbnRhY3Q+DQogICAgPiAgICAgICAg
ICAgCTxjb250YWN0PiA8dXJpPklQLUFkZHJlc3MyPC91cmk+PC9jb250YWN0Pg0KICAgID4gICAg
ICAgICAgIAk8Y29udGFjdD4gPHVyaT5JUC1BZGRyZXNzMzwvdXJpPjwvY29udGFjdD4NCiAgICA+
ICAgICAgICAgIA0KICAgID4gICAgICAgICAgQXMgeW91IGNhbiBzZWUsIHRoZSBjb250YWN0IGlu
Zm9ybWF0aW9uIGlzIGR1cGxpY2F0ZWQgbWFueSB0aW1lcy4NCiAgICA+ICAgICAgICAgIA0KICAg
ID4gICAgICAgICAgVXNpbmcgYW4gZXhhbXBsZSBiYXNlZCBvbiB0aGUgWE1MIHNjaGVtYSBpbiBS
RkMgMzY4MCBzaG93cyB0aGF0IHRoZSBwYXlsb2FkIGNhbiBnZXQgdmVyeSBiaWcgKEkgYW0gdXNp
bmcgZW1wdHkgbGluZXMgZm9yIHJlYWRhYmlsaXR5KToNCiAgICA+ICAgICAgICAgIA0KICAgID4g
ICAgICAgICAgPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCiAgICA+ICAg
ICAgICAgIDwhLS1TYW1wbGUgWE1MIGZpbGUgZ2VuZXJhdGVkIGJ5IFhNTFNweSB2MjAwOCAoaHR0
cDovL3d3dy5hbHRvdmEuY29tKS0tPg0KICAgID4gICAgICAgICAgPHRuczpyZWdpbmZvIHN0YXRl
PSJmdWxsIiB2ZXJzaW9uPSIwIiB4c2k6c2NoZW1hTG9jYXRpb249InVybjppZXRmOnBhcmFtczp4
bWw6bnM6cmVnaW5mbyBVbnRpdGxlZDEueHNkIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3Jn
LzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp0bnM9InVybjppZXRmOnBhcmFtczp4bWw6
bnM6cmVnaW5mbyI+DQogICAgPiAgICAgICAgICANCiAgICA+ICAgICAgICAgIDx0bnM6cmVnaXN0
cmF0aW9uIGlkPSIxMjM0NTY3ODkwIiBhb3I9InNpcDptYWlsdG86KzE1NTU2NjY3Nzc3QGltcy5t
bmMwMDEubWNjMDAxLjNncHBuZXR3b3Jrcy5vcmciPg0KICAgID4gICAgICAgICAgICAgIDx0bnM6
Y29udGFjdCBldmVudD0icmVnaXN0ZXJlZCIgaWQ9IjIzNDU2Nzg5MDEiIGR1cmF0aW9uLXJlZ2lz
dGVyZWQ9IjQyOTQ5NjcyOTUiDQogICAgPiAgICAgICAgICAgICAgICAgICBjc2VxPSI0Mjk0OTY3
Mjk1IiByZXRyeS1hZnRlcj0iNDI5NDk2NzI5NSIgcT0iMCIgc3RhdGU9ImFjdGl2ZSINCiAgICA+
ICAgICAgICAgICAgICAgICAgIGNhbGxpZD0iU3RyaW5nIiBleHBpcmVzPSI0Mjk0OTY3Mjk1Ij4N
CiAgICA+ICAgICAgICAgICAgICAgIDx0bnM6dXJpPnNpcDorMTU1NTY2Njc3NzdAWzIwMDE6MGRi
ODo4NWEzOjAwMDA6MDAwMDo4YTJlOjAzNzA6YWFhYV08L3Ruczp1cmk+DQogICAgPiAgICAgICAg
ICAgICAgICA8dG5zOmRpc3BsYXktbmFtZSB4bWw6bGFuZz0iZW4tdXMiPlN0cmluZzwvdG5zOmRp
c3BsYXktbmFtZT4NCiAgICA+ICAgICAgICAgICAgICAgIDx0bnM6dW5rbm93bi1wYXJhbSBuYW1l
PSJTdHJpbmciPlN0cmluZzwvdG5zOnVua25vd24tcGFyYW0+DQogICAgPiAgICAgICAgICAgICAg
PC90bnM6Y29udGFjdD4NCiAgICA+ICAgICAgICAgICAgICA8dG5zOmNvbnRhY3QgZXZlbnQ9InJl
Z2lzdGVyZWQiIGlkPSIyMzQ1Njc4OTAxIiBkdXJhdGlvbi1yZWdpc3RlcmVkPSI0Mjk0OTY3Mjk1
Ig0KICAgID4gICAgICAgICAgICAgICAgICAgY3NlcT0iNDI5NDk2NzI5NSIgcmV0cnktYWZ0ZXI9
IjQyOTQ5NjcyOTUiIHE9IjAiIHN0YXRlPSJhY3RpdmUiDQogICAgPiAgICAgICAgICAgICAgICAg
ICBjYWxsaWQ9IlN0cmluZyIgZXhwaXJlcz0iNDI5NDk2NzI5NSI+DQogICAgPiAgICAgICAgICAg
ICAgICA8dG5zOnVyaT5zaXA6KzE1NTU2NjY3Nzc3QFsyMDAxOjBkYjg6ODVhMzowMDAwOjAwMDA6
OGEyZTowMzcwOmJiYmJdPC90bnM6dXJpPg0KICAgID4gICAgICAgICAgICAgICAgPHRuczpkaXNw
bGF5LW5hbWUgeG1sOmxhbmc9ImVuLXVzIj5TdHJpbmc8L3RuczpkaXNwbGF5LW5hbWU+DQogICAg
PiAgICAgICAgICAgICAgICA8dG5zOnVua25vd24tcGFyYW0gbmFtZT0iU3RyaW5nIj5TdHJpbmc8
L3Ruczp1bmtub3duLXBhcmFtPg0KICAgID4gICAgICAgICAgICAgIDwvdG5zOmNvbnRhY3Q+DQog
ICAgPiAgICAgICAgICAgICAgPHRuczpjb250YWN0IGV2ZW50PSJyZWdpc3RlcmVkIiBpZD0iMjM0
NTY3ODkwMSIgZHVyYXRpb24tcmVnaXN0ZXJlZD0iNDI5NDk2NzI5NSINCiAgICA+ICAgICAgICAg
ICAgICAgICAgIGNzZXE9IjQyOTQ5NjcyOTUiIHJldHJ5LWFmdGVyPSI0Mjk0OTY3Mjk1IiBxPSIw
IiBzdGF0ZT0iYWN0aXZlIg0KICAgID4gICAgICAgICAgICAgICAgICAgY2FsbGlkPSJTdHJpbmci
IGV4cGlyZXM9IjQyOTQ5NjcyOTUiPg0KICAgID4gICAgICAgICAgICAgICAgPHRuczp1cmk+c2lw
OisxNTU1NjY2Nzc3N0BbMjAwMTowZGI4Ojg1YTM6MDAwMDowMDAwOjhhMmU6MDM3MDpjY2NjXTwv
dG5zOnVyaT4NCiAgICA+ICAgICAgICAgICAgICAgIDx0bnM6ZGlzcGxheS1uYW1lIHhtbDpsYW5n
PSJlbi11cyI+U3RyaW5nPC90bnM6ZGlzcGxheS1uYW1lPg0KICAgID4gICAgICAgICAgICAgICAg
PHRuczp1bmtub3duLXBhcmFtIG5hbWU9IlN0cmluZyI+U3RyaW5nPC90bnM6dW5rbm93bi1wYXJh
bT4NCiAgICA+ICAgICAgICAgICAgICA8L3Ruczpjb250YWN0Pg0KICAgID4gICAgICAgICAgPC90
bnM6cmVnaXN0cmF0aW9uPg0KICAgID4gICAgICAgICAgIA0KICAgID4gICAgICAgICAgPHRuczpy
ZWdpc3RyYXRpb24gaWQ9IjEyMzQ1Njc4OTAiIGFvcj0idGVsOisxNTU1NjY2Nzc3NyI+DQogICAg
PiAgICAgICAgICAgICAgPHRuczpjb250YWN0IGV2ZW50PSJyZWdpc3RlcmVkIiBpZD0iMjM0NTY3
ODkwMSIgZHVyYXRpb24tcmVnaXN0ZXJlZD0iNDI5NDk2NzI5NSINCiAgICA+ICAgICAgICAgICAg
ICAgICAgIGNzZXE9IjQyOTQ5NjcyOTUiIHJldHJ5LWFmdGVyPSI0Mjk0OTY3Mjk1IiBxPSIwIiBz
dGF0ZT0iYWN0aXZlIg0KICAgID4gICAgICAgICAgICAgICAgICAgY2FsbGlkPSJTdHJpbmciIGV4
cGlyZXM9IjQyOTQ5NjcyOTUiPg0KICAgID4gICAgICAgICAgICAgICAgPHRuczp1cmk+c2lwOisx
NTU1NjY2Nzc3N0BbMjAwMTowZGI4Ojg1YTM6MDAwMDowMDAwOjhhMmU6MDM3MDphYWFhXTwvdG5z
OnVyaT4NCiAgICA+ICAgICAgICAgICAgICAgIDx0bnM6ZGlzcGxheS1uYW1lIHhtbDpsYW5nPSJl
bi11cyI+U3RyaW5nPC90bnM6ZGlzcGxheS1uYW1lPg0KICAgID4gICAgICAgICAgICAgICAgPHRu
czp1bmtub3duLXBhcmFtIG5hbWU9IlN0cmluZyI+U3RyaW5nPC90bnM6dW5rbm93bi1wYXJhbT4N
CiAgICA+ICAgICAgICAgICAgICA8L3Ruczpjb250YWN0Pg0KICAgID4gICAgICAgICAgICAgIDx0
bnM6Y29udGFjdCBldmVudD0icmVnaXN0ZXJlZCIgaWQ9IjIzNDU2Nzg5MDEiIGR1cmF0aW9uLXJl
Z2lzdGVyZWQ9IjQyOTQ5NjcyOTUiDQogICAgPiAgICAgICAgICAgICAgICAgICBjc2VxPSI0Mjk0
OTY3Mjk1IiByZXRyeS1hZnRlcj0iNDI5NDk2NzI5NSIgcT0iMCIgc3RhdGU9ImFjdGl2ZSINCiAg
ICA+ICAgICAgICAgICAgICAgICAgIGNhbGxpZD0iU3RyaW5nIiBleHBpcmVzPSI0Mjk0OTY3Mjk1
Ij4NCiAgICA+ICAgICAgICAgICAgICAgIDx0bnM6dXJpPnNpcDorMTU1NTY2Njc3NzdAWzIwMDE6
MGRiODo4NWEzOjAwMDA6MDAwMDo4YTJlOjAzNzA6YmJiYl08L3Ruczp1cmk+DQogICAgPiAgICAg
ICAgICAgICAgICA8dG5zOmRpc3BsYXktbmFtZSB4bWw6bGFuZz0iZW4tdXMiPlN0cmluZzwvdG5z
OmRpc3BsYXktbmFtZT4NCiAgICA+ICAgICAgICAgICAgICAgIDx0bnM6dW5rbm93bi1wYXJhbSBu
YW1lPSJTdHJpbmciPlN0cmluZzwvdG5zOnVua25vd24tcGFyYW0+DQogICAgPiAgICAgICAgICAg
ICAgPC90bnM6Y29udGFjdD4NCiAgICA+ICAgICAgICAgICAgICA8dG5zOmNvbnRhY3QgZXZlbnQ9
InJlZ2lzdGVyZWQiIGlkPSIyMzQ1Njc4OTAxIiBkdXJhdGlvbi1yZWdpc3RlcmVkPSI0Mjk0OTY3
Mjk1Ig0KICAgID4gICAgICAgICAgICAgICAgICAgY3NlcT0iNDI5NDk2NzI5NSIgcmV0cnktYWZ0
ZXI9IjQyOTQ5NjcyOTUiIHE9IjAiIHN0YXRlPSJhY3RpdmUiDQogICAgPiAgICAgICAgICAgICAg
ICAgICBjYWxsaWQ9IlN0cmluZyIgZXhwaXJlcz0iNDI5NDk2NzI5NSI+DQogICAgPiAgICAgICAg
ICAgICAgICA8dG5zOnVyaT5zaXA6KzE1NTU2NjY3Nzc3QFsyMDAxOjBkYjg6ODVhMzowMDAwOjAw
MDA6OGEyZTowMzcwOmNjY2NdPC90bnM6dXJpPg0KICAgID4gICAgICAgICAgICAgICAgPHRuczpk
aXNwbGF5LW5hbWUgeG1sOmxhbmc9ImVuLXVzIj5TdHJpbmc8L3RuczpkaXNwbGF5LW5hbWU+DQog
ICAgPiAgICAgICAgICAgICAgICA8dG5zOnVua25vd24tcGFyYW0gbmFtZT0iU3RyaW5nIj5TdHJp
bmc8L3Ruczp1bmtub3duLXBhcmFtPg0KICAgID4gICAgICAgICAgICAgIDwvdG5zOmNvbnRhY3Q+
DQogICAgPiAgICAgICAgICA8L3RuczpyZWdpc3RyYXRpb24+DQogICAgPiAgICAgICAgICANCiAg
ICA+ICAgICAgICAgIDx0bnM6cmVnaXN0cmF0aW9uIGlkPSIxMjM0NTY3ODkwIiBhb3I9InNpcDpt
YWlsdG86KzE2NjY3Nzc4ODg4QGltcy5tbmMwMDEubWNjMDAxLjNncHBuZXR3b3Jrcy5vcmciPg0K
ICAgID4gICAgICAgICAgICAgIDx0bnM6Y29udGFjdCBldmVudD0icmVnaXN0ZXJlZCIgaWQ9IjIz
NDU2Nzg5MDEiIGR1cmF0aW9uLXJlZ2lzdGVyZWQ9IjQyOTQ5NjcyOTUiDQogICAgPiAgICAgICAg
ICAgICAgICAgICBjc2VxPSI0Mjk0OTY3Mjk1IiByZXRyeS1hZnRlcj0iNDI5NDk2NzI5NSIgcT0i
MCIgc3RhdGU9ImFjdGl2ZSINCiAgICA+ICAgICAgICAgICAgICAgICAgIGNhbGxpZD0iU3RyaW5n
IiBleHBpcmVzPSI0Mjk0OTY3Mjk1Ij4NCiAgICA+ICAgICAgICAgICAgICAgIDx0bnM6dXJpPnNp
cDorMTU1NTY2Njc3NzdAWzIwMDE6MGRiODo4NWEzOjAwMDA6MDAwMDo4YTJlOjAzNzA6YWFhYV08
L3Ruczp1cmk+DQogICAgPiAgICAgICAgICAgICAgICA8dG5zOmRpc3BsYXktbmFtZSB4bWw6bGFu
Zz0iZW4tdXMiPlN0cmluZzwvdG5zOmRpc3BsYXktbmFtZT4NCiAgICA+ICAgICAgICAgICAgICAg
IDx0bnM6dW5rbm93bi1wYXJhbSBuYW1lPSJTdHJpbmciPlN0cmluZzwvdG5zOnVua25vd24tcGFy
YW0+DQogICAgPiAgICAgICAgICAgICAgPC90bnM6Y29udGFjdD4NCiAgICA+ICAgICAgICAgICAg
ICA8dG5zOmNvbnRhY3QgZXZlbnQ9InJlZ2lzdGVyZWQiIGlkPSIyMzQ1Njc4OTAxIiBkdXJhdGlv
bi1yZWdpc3RlcmVkPSI0Mjk0OTY3Mjk1Ig0KICAgID4gICAgICAgICAgICAgICAgICAgY3NlcT0i
NDI5NDk2NzI5NSIgcmV0cnktYWZ0ZXI9IjQyOTQ5NjcyOTUiIHE9IjAiIHN0YXRlPSJhY3RpdmUi
DQogICAgPiAgICAgICAgICAgICAgICAgICBjYWxsaWQ9IlN0cmluZyIgZXhwaXJlcz0iNDI5NDk2
NzI5NSI+DQogICAgPiAgICAgICAgICAgICAgICA8dG5zOnVyaT5zaXA6KzE1NTU2NjY3Nzc3QFsy
MDAxOjBkYjg6ODVhMzowMDAwOjAwMDA6OGEyZTowMzcwOmJiYmJdPC90bnM6dXJpPg0KICAgID4g
ICAgICAgICAgICAgICAgPHRuczpkaXNwbGF5LW5hbWUgeG1sOmxhbmc9ImVuLXVzIj5TdHJpbmc8
L3RuczpkaXNwbGF5LW5hbWU+DQogICAgPiAgICAgICAgICAgICAgICA8dG5zOnVua25vd24tcGFy
YW0gbmFtZT0iU3RyaW5nIj5TdHJpbmc8L3Ruczp1bmtub3duLXBhcmFtPg0KICAgID4gICAgICAg
ICAgICAgIDwvdG5zOmNvbnRhY3Q+DQogICAgPiAgICAgICAgICAgICAgPHRuczpjb250YWN0IGV2
ZW50PSJyZWdpc3RlcmVkIiBpZD0iMjM0NTY3ODkwMSIgZHVyYXRpb24tcmVnaXN0ZXJlZD0iNDI5
NDk2NzI5NSINCiAgICA+ICAgICAgICAgICAgICAgICAgIGNzZXE9IjQyOTQ5NjcyOTUiIHJldHJ5
LWFmdGVyPSI0Mjk0OTY3Mjk1IiBxPSIwIiBzdGF0ZT0iYWN0aXZlIg0KICAgID4gICAgICAgICAg
ICAgICAgICAgY2FsbGlkPSJTdHJpbmciIGV4cGlyZXM9IjQyOTQ5NjcyOTUiPg0KICAgID4gICAg
ICAgICAgICAgICAgPHRuczp1cmk+c2lwOisxNTU1NjY2Nzc3N0BbMjAwMTowZGI4Ojg1YTM6MDAw
MDowMDAwOjhhMmU6MDM3MDpjY2NjXTwvdG5zOnVyaT4NCiAgICA+ICAgICAgICAgICAgICAgIDx0
bnM6ZGlzcGxheS1uYW1lIHhtbDpsYW5nPSJlbi11cyI+U3RyaW5nPC90bnM6ZGlzcGxheS1uYW1l
Pg0KICAgID4gICAgICAgICAgICAgICAgPHRuczp1bmtub3duLXBhcmFtIG5hbWU9IlN0cmluZyI+
U3RyaW5nPC90bnM6dW5rbm93bi1wYXJhbT4NCiAgICA+ICAgICAgICAgICAgICA8L3Ruczpjb250
YWN0Pg0KICAgID4gICAgICAgICAgPC90bnM6cmVnaXN0cmF0aW9uPg0KICAgID4gICAgICAgICAg
DQogICAgPiAgICAgICAgICA8dG5zOnJlZ2lzdHJhdGlvbiBpZD0iMTIzNDU2Nzg5MCIgYW9yPSJ0
ZWw6KzE1NTU2NjY3Nzc3Ij4NCiAgICA+ICAgICAgICAgICAgICA8dG5zOmNvbnRhY3QgZXZlbnQ9
InJlZ2lzdGVyZWQiIGlkPSIyMzQ1Njc4OTAxIiBkdXJhdGlvbi1yZWdpc3RlcmVkPSI0Mjk0OTY3
Mjk1Ig0KICAgID4gICAgICAgICAgICAgICAgICAgY3NlcT0iNDI5NDk2NzI5NSIgcmV0cnktYWZ0
ZXI9IjQyOTQ5NjcyOTUiIHE9IjAiIHN0YXRlPSJhY3RpdmUiDQogICAgPiAgICAgICAgICAgICAg
ICAgICBjYWxsaWQ9IlN0cmluZyIgZXhwaXJlcz0iNDI5NDk2NzI5NSI+DQogICAgPiAgICAgICAg
ICAgICAgICA8dG5zOnVyaT5zaXA6KzE1NTU2NjY3Nzc3QFsyMDAxOjBkYjg6ODVhMzowMDAwOjAw
MDA6OGEyZTowMzcwOmFhYWFdPC90bnM6dXJpPg0KICAgID4gICAgICAgICAgICAgICAgPHRuczpk
aXNwbGF5LW5hbWUgeG1sOmxhbmc9ImVuLXVzIj5TdHJpbmc8L3RuczpkaXNwbGF5LW5hbWU+DQog
ICAgPiAgICAgICAgICAgICAgICA8dG5zOnVua25vd24tcGFyYW0gbmFtZT0iU3RyaW5nIj5TdHJp
bmc8L3Ruczp1bmtub3duLXBhcmFtPg0KICAgID4gICAgICAgICAgICAgIDwvdG5zOmNvbnRhY3Q+
DQogICAgPiAgICAgICAgICAgICAgPHRuczpjb250YWN0IGV2ZW50PSJyZWdpc3RlcmVkIiBpZD0i
MjM0NTY3ODkwMSIgZHVyYXRpb24tcmVnaXN0ZXJlZD0iNDI5NDk2NzI5NSINCiAgICA+ICAgICAg
ICAgICAgICAgICAgIGNzZXE9IjQyOTQ5NjcyOTUiIHJldHJ5LWFmdGVyPSI0Mjk0OTY3Mjk1IiBx
PSIwIiBzdGF0ZT0iYWN0aXZlIg0KICAgID4gICAgICAgICAgICAgICAgICAgY2FsbGlkPSJTdHJp
bmciIGV4cGlyZXM9IjQyOTQ5NjcyOTUiPg0KICAgID4gICAgICAgICAgICAgICAgPHRuczp1cmk+
c2lwOisxNTU1NjY2Nzc3N0BbMjAwMTowZGI4Ojg1YTM6MDAwMDowMDAwOjhhMmU6MDM3MDpiYmJi
XTwvdG5zOnVyaT4NCiAgICA+ICAgICAgICAgICAgICAgIDx0bnM6ZGlzcGxheS1uYW1lIHhtbDps
YW5nPSJlbi11cyI+U3RyaW5nPC90bnM6ZGlzcGxheS1uYW1lPg0KICAgID4gICAgICAgICAgICAg
ICAgPHRuczp1bmtub3duLXBhcmFtIG5hbWU9IlN0cmluZyI+U3RyaW5nPC90bnM6dW5rbm93bi1w
YXJhbT4NCiAgICA+ICAgICAgICAgICAgICA8L3Ruczpjb250YWN0Pg0KICAgID4gICAgICAgICAg
ICAgIDx0bnM6Y29udGFjdCBldmVudD0icmVnaXN0ZXJlZCIgaWQ9IjIzNDU2Nzg5MDEiIGR1cmF0
aW9uLXJlZ2lzdGVyZWQ9IjQyOTQ5NjcyOTUiDQogICAgPiAgICAgICAgICAgICAgICAgICBjc2Vx
PSI0Mjk0OTY3Mjk1IiByZXRyeS1hZnRlcj0iNDI5NDk2NzI5NSIgcT0iMCIgc3RhdGU9ImFjdGl2
ZSINCiAgICA+ICAgICAgICAgICAgICAgICAgIGNhbGxpZD0iU3RyaW5nIiBleHBpcmVzPSI0Mjk0
OTY3Mjk1Ij4NCiAgICA+ICAgICAgICAgICAgICAgIDx0bnM6dXJpPnNpcDorMTU1NTY2Njc3NzdA
WzIwMDE6MGRiODo4NWEzOjAwMDA6MDAwMDo4YTJlOjAzNzA6Y2NjY108L3Ruczp1cmk+DQogICAg
PiAgICAgICAgICAgICAgICA8dG5zOmRpc3BsYXktbmFtZSB4bWw6bGFuZz0iZW4tdXMiPlN0cmlu
ZzwvdG5zOmRpc3BsYXktbmFtZT4NCiAgICA+ICAgICAgICAgICAgICAgIDx0bnM6dW5rbm93bi1w
YXJhbSBuYW1lPSJTdHJpbmciPlN0cmluZzwvdG5zOnVua25vd24tcGFyYW0+DQogICAgPiAgICAg
ICAgICAgICAgPC90bnM6Y29udGFjdD4NCiAgICA+ICAgICAgICAgIDwvdG5zOnJlZ2lzdHJhdGlv
bj4NCiAgICA+ICAgICAgICAgIDwvdG5zOnJlZ2luZm8+DQogICAgPiAgICAgICAgICANCiAgICA+
ICAgICAgICAgIElmIHRoZSBudW1iZXIgb2YgcGhvbmUgbnVtYmVycyBhbmQvb3IgZGV2aWNlcyBp
bmNyZWFzZSwgdGhlIHBheWxvYWQgc2l6ZSB3aWxsIGdyb3cgcmF0aGVyIHJhcGlkbHkuDQogICAg
PiAgICAgICAgICANCiAgICA+ICAgICAgICAgIE9uZSBjYW4gb2YgY291cnNlIGUuZy4sIHVzZSBt
ZXNzYWdlIGNvbXByZXNzaW9uIHRvIHJlZHVjZSB0aGUgc2l6ZSBvZiB0aGUgcGF5bG9hZCwgYnV0
IGluIG15IG9waW5pb24gdGhlIHJlYWwgcHJvYmxlbSBpcyB0aGUgZmFjdCB0aGF0IGluZm9ybWF0
aW9uIGlzIGR1cGxpY2F0ZWQuDQogICAgPiAgICAgICAgICANCiAgICA+ICAgICAgICAgIFdoZW4g
ZGlzY3Vzc2luZyB0aGlzIHdpdGggc29tZSBjb2xsZWFndWVzLCBvbmUgaWRlYSB0aGF0IGNhbWUg
dXAgd2FzIHRvIHVzZSByZWZlcmVuY2VzOiBzZXBhcmF0ZSB0aGUgJ2NvbnRhY3QgZWxlbWVudHMn
IGZyb20gdGhlICdyZWdpc3RyYXRpb24gZWxlbWVudHMnLCBhbmQgdGhlbiBzaW1wbHkgcmVmZXJl
bmNlIHRoZSAnY29udGFjdCBlbGVtZW50cycgZnJvbSB3aXRoaW4gdGhlICdyZWdpc3RyYXRpb24g
ZWxlbWVudHMnLg0KICAgID4gICAgICAgICAgDQogICAgPiAgICAgICAgICBBIHNpbXBsaWZpZWQg
ZXhhbXBsZSB3b3VsZCBsb29rIHNvbWV0aGluZyBsaWtlIChub3RlIHRoZSBuZXcgYW5jaG9yIGFu
ZCB0YXJnZXQgYXR0cmlidXRlcyk6DQogICAgPiAgICAgICAgICANCiAgICA+ICAgICAgICAgIDxj
b250YWN0PiA8dXJpPklQLUFkZHJlc3MxIGFuY2hvcj0iMSI8L3VyaT48L2NvbnRhY3Q+DQogICAg
PiAgICAgICAgICA8Y29udGFjdD4gPHVyaT5JUC1BZGRyZXNzMiBhbmNob3I9IjIiPC91cmk+PC9j
b250YWN0Pg0KICAgID4gICAgICAgICAgPGNvbnRhY3Q+IDx1cmk+SVAtQWRkcmVzczMgYW5jaG9y
PSIzIjwvdXJpPjwvY29udGFjdD4NCiAgICA+ICAgICAgICAgIDxyZWdpc3RyYXRpb24gYW9yPXNp
cDpwaG9uZV9udW1iZXIxL1NJUCBpZD0iMSIgc3RhdGU9ImFjdGl2ZSI+DQogICAgPiAgICAgICAg
ICAJPGNvbnRhY3QtcmVmIHRhcmdldD0iMSIgLz4NCiAgICA+ICAgICAgICAgIAk8Y29udGFjdC1y
ZWYgdGFyZ2V0PSIyIiAvPg0KICAgID4gICAgICAgICAgCTxjb250YWN0LXJlZiB0YXJnZXQ9IjMi
IC8+DQogICAgPiAgICAgICAgICA8cmVnaXN0cmF0aW9uIGFvcj10ZWw6cGhvbmVfbnVtYmVyMS9U
RUwgaWQ9IjIiIHN0YXRlPSJhY3RpdmUiPg0KICAgID4gICAgICAgICAgCTxjb250YWN0LXJlZiB0
YXJnZXQ9IjEiIC8+DQogICAgPiAgICAgICAgICAJPGNvbnRhY3QtcmVmIHRhcmdldD0iMiIgLz4N
CiAgICA+ICAgICAgICAgIAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIzIiAvPg0KICAgID4gICAgICAg
ICAgPHJlZ2lzdHJhdGlvbiBhb3I9c2lwOnBob25lX251bWJlcjIvU0lQIGlkPSIxIiBzdGF0ZT0i
YWN0aXZlIj4NCiAgICA+ICAgICAgICAgIAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIxIiAvPg0KICAg
ID4gICAgICAgICAgCTxjb250YWN0LXJlZiB0YXJnZXQ9IjIiIC8+DQogICAgPiAgICAgICAgICAJ
PGNvbnRhY3QtcmVmIHRhcmdldD0iMyIgLz4NCiAgICA+ICAgICAgICAgIDxyZWdpc3RyYXRpb24g
YW9yPXRlbDpwaG9uZV9udW1iZXIyL1RFTCBpZD0iMiIgc3RhdGU9ImFjdGl2ZSI+DQogICAgPiAg
ICAgICAgICAJPGNvbnRhY3QtcmVmIHRhcmdldD0iMSIgLz4NCiAgICA+ICAgICAgICAgIAk8Y29u
dGFjdC1yZWYgdGFyZ2V0PSIyIiAvPg0KICAgID4gICAgICAgICAgCTxjb250YWN0LXJlZiB0YXJn
ZXQ9IjMiIC8+DQogICAgPiAgICAgICAgICANCiAgICA+ICAgICAgICAgIElmIHlvdSBhcHBseSB0
aGlzIG9uIHRoZSBleGFtcGxlIGJhc2VkIG9uIHRoZSBYTUwgc2NoZW1hIGluIFJGQyAzNjgwIHlv
dSB3aWxsIHNlZSBhIHNpZ25pZmljYW50IHJlZHVjdGlvbiBpbiBzaXplOg0KICAgID4gICAgICAg
ICAgDQogICAgPiAgICAgICAgICA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/
Pg0KICAgID4gICAgICAgICAgPCEtLVNhbXBsZSBYTUwgZmlsZSBnZW5lcmF0ZWQgYnkgWE1MU3B5
IHYyMDA4IChodHRwOi8vd3d3LmFsdG92YS5jb20pLS0+DQogICAgPiAgICAgICAgICA8dG5zOnJl
Z2luZm8gc3RhdGU9ImZ1bGwiIHZlcnNpb249IjAiIHhzaTpzY2hlbWFMb2NhdGlvbj0idXJuOmll
dGY6cGFyYW1zOnhtbDpuczpyZWdpbmZvIFVudGl0bGVkMS54c2QiIHhtbG5zOnhzaT0iaHR0cDov
L3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnRucz0idXJuOmlldGY6
cGFyYW1zOnhtbDpuczpyZWdpbmZvIj4NCiAgICA+ICAgICAgICAgIA0KICAgID4gICAgICAgICAg
PHRuczpjb250YWN0IGV2ZW50PSJyZWdpc3RlcmVkIiBhbmNob3I9IjEiIGlkPSIyMzQ1Njc4OTAx
IiBkdXJhdGlvbi1yZWdpc3RlcmVkPSI0Mjk0OTY3Mjk1Ig0KICAgID4gICAgICAgICAgICAgICAg
ICAgY3NlcT0iNDI5NDk2NzI5NSIgcmV0cnktYWZ0ZXI9IjQyOTQ5NjcyOTUiIHE9IjAiIHN0YXRl
PSJhY3RpdmUiDQogICAgPiAgICAgICAgICAgICAgICAgICBjYWxsaWQ9IlN0cmluZyIgZXhwaXJl
cz0iNDI5NDk2NzI5NSI+DQogICAgPiAgICAgICAgICAgICAgICA8dG5zOnVyaT5zaXA6KzE1NTU2
NjY3Nzc3QFsyMDAxOjBkYjg6ODVhMzowMDAwOjAwMDA6OGEyZTowMzcwOmFhYWFdPC90bnM6dXJp
Pg0KICAgID4gICAgICAgICAgICAgICAgPHRuczpkaXNwbGF5LW5hbWUgeG1sOmxhbmc9ImVuLXVz
Ij5TdHJpbmc8L3RuczpkaXNwbGF5LW5hbWU+DQogICAgPiAgICAgICAgICAgICAgICA8dG5zOnVu
a25vd24tcGFyYW0gbmFtZT0iU3RyaW5nIj5TdHJpbmc8L3Ruczp1bmtub3duLXBhcmFtPg0KICAg
ID4gICAgICAgICAgPC90bnM6Y29udGFjdD4NCiAgICA+ICAgICAgICAgIDx0bnM6Y29udGFjdCBl
dmVudD0icmVnaXN0ZXJlZCIgYW5jaG9yPSIyIiBpZD0iMjM0NTY3ODkwMSIgZHVyYXRpb24tcmVn
aXN0ZXJlZD0iNDI5NDk2NzI5NSINCiAgICA+ICAgICAgICAgICAgICAgICAgIGNzZXE9IjQyOTQ5
NjcyOTUiIHJldHJ5LWFmdGVyPSI0Mjk0OTY3Mjk1IiBxPSIwIiBzdGF0ZT0iYWN0aXZlIg0KICAg
ID4gICAgICAgICAgICAgICAgICAgY2FsbGlkPSJTdHJpbmciIGV4cGlyZXM9IjQyOTQ5NjcyOTUi
Pg0KICAgID4gICAgICAgICAgICAgICAgPHRuczp1cmk+c2lwOisxNTU1NjY2Nzc3N0BbMjAwMTow
ZGI4Ojg1YTM6MDAwMDowMDAwOjhhMmU6MDM3MDpiYmJiXTwvdG5zOnVyaT4NCiAgICA+ICAgICAg
ICAgICAgICAgIDx0bnM6ZGlzcGxheS1uYW1lIHhtbDpsYW5nPSJlbi11cyI+U3RyaW5nPC90bnM6
ZGlzcGxheS1uYW1lPg0KICAgID4gICAgICAgICAgICAgICAgPHRuczp1bmtub3duLXBhcmFtIG5h
bWU9IlN0cmluZyI+U3RyaW5nPC90bnM6dW5rbm93bi1wYXJhbT4NCiAgICA+ICAgICAgICAgIDwv
dG5zOmNvbnRhY3Q+DQogICAgPiAgICAgICAgICA8dG5zOmNvbnRhY3QgZXZlbnQ9InJlZ2lzdGVy
ZWQiIGFuY2hvcj0iMyIgaWQ9IjIzNDU2Nzg5MDEiIGR1cmF0aW9uLXJlZ2lzdGVyZWQ9IjQyOTQ5
NjcyOTUiDQogICAgPiAgICAgICAgICAgICAgICAgICBjc2VxPSI0Mjk0OTY3Mjk1IiByZXRyeS1h
ZnRlcj0iNDI5NDk2NzI5NSIgcT0iMCIgc3RhdGU9ImFjdGl2ZSINCiAgICA+ICAgICAgICAgICAg
ICAgICAgIGNhbGxpZD0iU3RyaW5nIiBleHBpcmVzPSI0Mjk0OTY3Mjk1Ij4NCiAgICA+ICAgICAg
ICAgICAgICAgIDx0bnM6dXJpPnNpcDorMTU1NTY2Njc3NzdAWzIwMDE6MGRiODo4NWEzOjAwMDA6
MDAwMDo4YTJlOjAzNzA6Y2NjY108L3Ruczp1cmk+DQogICAgPiAgICAgICAgICAgICAgICA8dG5z
OmRpc3BsYXktbmFtZSB4bWw6bGFuZz0iZW4tdXMiPlN0cmluZzwvdG5zOmRpc3BsYXktbmFtZT4N
CiAgICA+ICAgICAgICAgICAgICAgIDx0bnM6dW5rbm93bi1wYXJhbSBuYW1lPSJTdHJpbmciPlN0
cmluZzwvdG5zOnVua25vd24tcGFyYW0+DQogICAgPiAgICAgICAgICA8L3Ruczpjb250YWN0Pg0K
ICAgID4gICAgICAgICAgDQogICAgPiAgICAgICAgICA8dG5zOnJlZ2lzdHJhdGlvbiBpZD0iMTIz
NDU2Nzg5MCIgYW9yPSJzaXA6bWFpbHRvOisxNTU1NjY2Nzc3N0BpbXMubW5jMDAxLm1jYzAwMS4z
Z3BwbmV0d29ya3Mub3JnIj4NCiAgICA+ICAgICAgICAgIAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIx
IiAvPg0KICAgID4gICAgICAgICAgCTxjb250YWN0LXJlZiB0YXJnZXQ9IjIiIC8+DQogICAgPiAg
ICAgICAgICAJPGNvbnRhY3QtcmVmIHRhcmdldD0iMyIgLz4NCiAgICA+ICAgICAgICAgIDwvdG5z
OnJlZ2lzdHJhdGlvbj4NCiAgICA+ICAgICAgICAgIDx0bnM6cmVnaXN0cmF0aW9uIGlkPSIxMjM0
NTY3ODkwIiBhb3I9InRlbDorMTU1NTY2Njc3NzciPg0KICAgID4gICAgICAgICAgCTxjb250YWN0
LXJlZiB0YXJnZXQ9IjEiIC8+DQogICAgPiAgICAgICAgICAJPGNvbnRhY3QtcmVmIHRhcmdldD0i
MiIgLz4NCiAgICA+ICAgICAgICAgIAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIzIiAvPg0KICAgID4g
ICAgICAgICAgPC90bnM6cmVnaXN0cmF0aW9uPg0KICAgID4gICAgICAgICAgPHRuczpyZWdpc3Ry
YXRpb24gaWQ9IjEyMzQ1Njc4OTAiIGFvcj0ic2lwOm1haWx0bzorMTY2Njc3Nzg4ODhAaW1zLm1u
YzAwMS5tY2MwMDEuM2dwcG5ldHdvcmtzLm9yZyI+DQogICAgPiAgICAgICAgICAJPGNvbnRhY3Qt
cmVmIHRhcmdldD0iMSIgLz4NCiAgICA+ICAgICAgICAgIAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIy
IiAvPg0KICAgID4gICAgICAgICAgCTxjb250YWN0LXJlZiB0YXJnZXQ9IjMiIC8+DQogICAgPiAg
ICAgICAgICA8L3RuczpyZWdpc3RyYXRpb24+DQogICAgPiAgICAgICAgICA8dG5zOnJlZ2lzdHJh
dGlvbiBpZD0iMTIzNDU2Nzg5MCIgYW9yPSJ0ZWw6KzE1NTU2NjY3Nzc3Ij4NCiAgICA+ICAgICAg
ICAgIAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIxIiAvPg0KICAgID4gICAgICAgICAgCTxjb250YWN0
LXJlZiB0YXJnZXQ9IjIiIC8+DQogICAgPiAgICAgICAgICAJPGNvbnRhY3QtcmVmIHRhcmdldD0i
MyIgLz4NCiAgICA+ICAgICAgICAgIDwvdG5zOnJlZ2lzdHJhdGlvbj4NCiAgICA+ICAgICAgICAg
IDwvdG5zOnJlZ2luZm8+DQogICAgPiAgICAgICAgICANCiAgICA+IA0KICAgID4gICAgICAgICBB
cyBmYXIgYXMgc3RhbmRhcmRpemF0aW9uIGlzIGNvbmNlcm5lZCwgSSBndWVzcyB0aGlzIGNvdWxk
IGJlIGRvbmUgYXMgYW4gUkZDIDM2ODAgdXBkYXRlLCBieSBlaXRoZXIgZGVmaW5pbmcgYW4gYWRk
aXRpb25hbCByZWctZXZlbnQgcGFja2FnZSB3aXRoIGEgbmV3IFhNTCBzY2hlbWEsIE9SIGRlZmlu
aW5nIGFuIGFkZGl0aW9uYWwgWE1MIHNjaGVtYSBmb3IgdGhlIGV4aXN0aW5nIHJlZy1ldmVudCBw
YWNrYWdlIChpZiB0aGF0IGlzIGFsbG93ZWQpLiBJbiBlaXRoZXIgY2FzZSwgdGhlIFVBIG9idmlv
dXNseSBuZWVkIHRvIGJlIGFibGUgdG8gaW5kaWNhdGUgc3VwcG9ydCBvZiB0aGUgbmV3IHNjaGVt
YS4NCiAgICA+IA0KICAgID4gICAgICAgICAgQ29tbWVudHM/DQogICAgPiAgICAgICAgICANCiAg
ICA+ICAgICAgICAgIFJlZ2FyZHMsDQogICAgPiAgICAgICAgICANCiAgICA+ICAgICAgICAgIENo
cmlzdGVyDQogICAgPiAgICAgICAgICANCiAgICA+IA0KICAgID4gDQogICAgPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gc2lwY29yZSBtYWls
aW5nIGxpc3QNCiAgICA+IHNpcGNvcmVAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KICAgID4gDQogICAgDQogICAgX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBzaXBjb3JlIG1haWxp
bmcgbGlzdA0KICAgIHNpcGNvcmVAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCiAgICANCg0K


From nobody Wed Mar 27 15:55:50 2019
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 311ED12041C for ; Wed, 27 Mar 2019 15:55: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, 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 NHX7nUhB8omo for ; Wed, 27 Mar 2019 15:55:30 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4192120421 for ; Wed, 27 Mar 2019 15:55:29 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (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.14.7/8.12.4) with ESMTP id x2RMtO3k002000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2019 18:55:25 -0400
To: Christer Holmberg , "sipcore@ietf.org" 
References: <97159F5B-8C69-4B89-A25F-39F95ED57027@ericsson.com>  <678C20F0-8D1E-44A5-897F-70B521036B63@ericsson.com>
From: Paul Kyzivat 
Message-ID: <44d66095-73c1-2ded-d70f-63057398325c@alum.mit.edu>
Date: Wed, 27 Mar 2019 18:55:23 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <678C20F0-8D1E-44A5-897F-70B521036B63@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [sipcore] reg-event issue with multi-identity/multi-device
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Mar 2019 22:55:49 -0000

On 3/27/19 5:07 PM, Christer Holmberg wrote:
> Hi,
>      
>>     I understand the problem. But I think we need to assess whether the
>>     problem is severe enough to justify the effort of deploying a solution.
> 
> It is causing problems, and people have been asked to find a solution.
> 
>>     In any case I guess a solution would have to include backward
>>     compatibility, so it would only be applied if both client and server
>>     support it as an extension.
>    
> Sure.
> 
>>     The solution you outline is straightforward. But if doing something it
>>     might be better to just do general compression. I think there are
>>     already MIME types for carrying compressed data. I don't know whether
>>     they are suitable here, but if so it might mean off-the-shelf code is
>>     available.
>    
> Even if you compress, the receiver will still have to de-compress, parse and process everything etc, so it was not seen as a good solution.

The receiver has to change their decoding of the xml response, while 
still retaining the old processing in case the server doesn't support 
this new feature.

With compression it may be no more than making a library call to 
decompress the response and then process normally. So it *could* be easier.

I'm not trying to make the case that it *is* easier - only that I think 
the pros and cons need to be discussed more fully. I have no problem 
with establishing a work item around this issue.

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> 
> 
>      
>      On 3/27/19 8:31 AM, Christer Holmberg wrote:
>      >        Hi,
>      >
>      >          3GPP defines ”multi identity” and ”multi devices” concepts, which means that:
>      >
>      >          1) A user can have multiple phone numbers; and
>      >          2) A user can have multiple devices, each of which can be reached with any of those phone numbers
>      >
>      >          Assume a user has:
>      >
>      >          1) 2 phone numbers, each with a SIP URI and a tel URI representation ("phone_number1/SIP", "phone_number1/TEL", "phone_number2/SIP" and "phone_number2/TEL")
>      >          2) Different devices, each with a different contact IP address ("IP-Address1", "IP-Address2" and "IP-Address3")
>      >
>      >          A simplified reg-event notification would look like this:
>      >
>      >          
>      >           	 IP-Address1
>      >           	 IP-Address2
>      >           	 IP-Address3
>      >          
>      >           	 IP-Address1
>      >           	 IP-Address2
>      >           	 IP-Address3
>      >          
>      >           	 IP-Address1
>      >           	 IP-Address2
>      >           	 IP-Address3
>      >          
>      >           	 IP-Address1
>      >           	 IP-Address2
>      >           	 IP-Address3
>      >
>      >          As you can see, the contact information is duplicated many times.
>      >
>      >          Using an example based on the XML schema in RFC 3680 shows that the payload can get very big (I am using empty lines for readability):
>      >
>      >          
>      >          
>      >          
>      >
>      >          
>      >                    >                   cseq="4294967295" retry-after="4294967295" q="0" state="active"
>      >                   callid="String" expires="4294967295">
>      >                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:aaaa]
>      >                String
>      >                String
>      >              
>      >                    >                   cseq="4294967295" retry-after="4294967295" q="0" state="active"
>      >                   callid="String" expires="4294967295">
>      >                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:bbbb]
>      >                String
>      >                String
>      >              
>      >                    >                   cseq="4294967295" retry-after="4294967295" q="0" state="active"
>      >                   callid="String" expires="4294967295">
>      >                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:cccc]
>      >                String
>      >                String
>      >              
>      >          
>      >
>      >          
>      >                    >                   cseq="4294967295" retry-after="4294967295" q="0" state="active"
>      >                   callid="String" expires="4294967295">
>      >                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:aaaa]
>      >                String
>      >                String
>      >              
>      >                    >                   cseq="4294967295" retry-after="4294967295" q="0" state="active"
>      >                   callid="String" expires="4294967295">
>      >                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:bbbb]
>      >                String
>      >                String
>      >              
>      >                    >                   cseq="4294967295" retry-after="4294967295" q="0" state="active"
>      >                   callid="String" expires="4294967295">
>      >                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:cccc]
>      >                String
>      >                String
>      >              
>      >          
>      >
>      >          
>      >                    >                   cseq="4294967295" retry-after="4294967295" q="0" state="active"
>      >                   callid="String" expires="4294967295">
>      >                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:aaaa]
>      >                String
>      >                String
>      >              
>      >                    >                   cseq="4294967295" retry-after="4294967295" q="0" state="active"
>      >                   callid="String" expires="4294967295">
>      >                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:bbbb]
>      >                String
>      >                String
>      >              
>      >                    >                   cseq="4294967295" retry-after="4294967295" q="0" state="active"
>      >                   callid="String" expires="4294967295">
>      >                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:cccc]
>      >                String
>      >                String
>      >              
>      >          
>      >
>      >          
>      >                    >                   cseq="4294967295" retry-after="4294967295" q="0" state="active"
>      >                   callid="String" expires="4294967295">
>      >                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:aaaa]
>      >                String
>      >                String
>      >              
>      >                    >                   cseq="4294967295" retry-after="4294967295" q="0" state="active"
>      >                   callid="String" expires="4294967295">
>      >                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:bbbb]
>      >                String
>      >                String
>      >              
>      >                    >                   cseq="4294967295" retry-after="4294967295" q="0" state="active"
>      >                   callid="String" expires="4294967295">
>      >                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:cccc]
>      >                String
>      >                String
>      >              
>      >          
>      >          
>      >
>      >          If the number of phone numbers and/or devices increase, the payload size will grow rather rapidly.
>      >
>      >          One can of course e.g., use message compression to reduce the size of the payload, but in my opinion the real problem is the fact that information is duplicated.
>      >
>      >          When discussing this with some colleagues, one idea that came up was to use references: separate the 'contact elements' from the 'registration elements', and then simply reference the 'contact elements' from within the 'registration elements'.
>      >
>      >          A simplified example would look something like (note the new anchor and target attributes):
>      >
>      >           IP-Address1 anchor="1"
>      >           IP-Address2 anchor="2"
>      >           IP-Address3 anchor="3"
>      >          
>      >          	
>      >          	
>      >          	
>      >          
>      >          	
>      >          	
>      >          	
>      >          
>      >          	
>      >          	
>      >          	
>      >          
>      >          	
>      >          	
>      >          	
>      >
>      >          If you apply this on the example based on the XML schema in RFC 3680 you will see a significant reduction in size:
>      >
>      >          
>      >          
>      >          
>      >
>      >                >                   cseq="4294967295" retry-after="4294967295" q="0" state="active"
>      >                   callid="String" expires="4294967295">
>      >                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:aaaa]
>      >                String
>      >                String
>      >          
>      >                >                   cseq="4294967295" retry-after="4294967295" q="0" state="active"
>      >                   callid="String" expires="4294967295">
>      >                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:bbbb]
>      >                String
>      >                String
>      >          
>      >                >                   cseq="4294967295" retry-after="4294967295" q="0" state="active"
>      >                   callid="String" expires="4294967295">
>      >                sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:cccc]
>      >                String
>      >                String
>      >          
>      >
>      >          
>      >          	
>      >          	
>      >          	
>      >          
>      >          
>      >          	
>      >          	
>      >          	
>      >          
>      >          
>      >          	
>      >          	
>      >          	
>      >          
>      >          
>      >          	
>      >          	
>      >          	
>      >          
>      >          
>      >
>      >
>      >         As far as standardization is concerned, I guess this could be done as an RFC 3680 update, by either defining an additional reg-event package with a new XML schema, OR defining an additional XML schema for the existing reg-event package (if that is allowed). In either case, the UA obviously need to be able to indicate support of the new schema.
>      >
>      >          Comments?
>      >
>      >          Regards,
>      >
>      >          Christer
>      >
>      >
>      >
>      > _______________________________________________
>      > sipcore mailing list
>      > sipcore@ietf.org
>      > https://www.ietf.org/mailman/listinfo/sipcore
>      >
>      
>      _______________________________________________
>      sipcore mailing list
>      sipcore@ietf.org
>      https://www.ietf.org/mailman/listinfo/sipcore
>      
> 


From nobody Wed Mar 27 18:15:41 2019
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 C28FF12013B for ; Wed, 27 Mar 2019 18:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.689
X-Spam-Level: 
X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.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 wEiNmA3Fv_Qd for ; Wed, 27 Mar 2019 18:15:35 -0700 (PDT)
Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [198.46.93.79]) (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 801F11200EA for ; Wed, 27 Mar 2019 18:15:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=References:To:Cc:In-Reply-To:Date:Subject: Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To: Content-Transfer-Encoding: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=ikPvoUHNlommNjjbGepOEiD7IL9UzgiLOU2D/KEDm4g=; b=LHORoaZldxqwgETu+IZUYrQVm kBVyDuIQld+LTYzV/vHuQ6bC5H2bvYZ+mnY10F9xBxZdlyY1RehQ5evBAIRNpZMwz6zcX6y9iBL0C x31r6bM2KaQtVVMrcetSYwo8Sk7yqP3XDnYaxhA9CqKmsqrVhZTAZbcWV0n2vX4KrFLp8=;
Received: from [68.100.196.217] (port=61299 helo=[192.168.10.26]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h9Jda-0000fc-EM; Wed, 27 Mar 2019 18:15:34 -0700
From: Eric Burger 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_13A8332A-C8CF-45B2-920F-425C8BF0DF2D"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Wed, 27 Mar 2019 21:15:21 -0400
In-Reply-To: <223874A0-4F48-4684-BC96-2F4B84F82C0E@ericsson.com>
Cc: SIPCORE 
To: Holmberg Christer 
References: <155370116735.10357.14550485597454442062.idtracker@ietfa.amsl.com> <6FADC6F0-A88A-43B8-90B2-2143834B5879@standardstrack.com> <223874A0-4F48-4684-BC96-2F4B84F82C0E@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [sipcore] New Version Notification for draft-ietf-sipcore-rejected-04.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Mar 2019 01:15:40 -0000

--Apple-Mail=_13A8332A-C8CF-45B2-920F-425C8BF0DF2D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thanks! I totally missed the thread. One question, besides updating the =
example, what should I say in the text? Since Feature-Caps is a list, =
should I say:

   Name:  sip.608

   Description:  This feature capability indicator, when included in a
      Feature-Caps header field of an INVITE request, indicates that the
      entity that inserted the sip.608 Feature-Caps value will be
      responsible for indicating to the caller any information contained
      in the 608 SIP response code, specifically the value referenced by
      the Call-Info header

or

   Name: *;+sip.608

   Description:  This feature capability indicator, when included in a
      Feature-Caps header field of an INVITE request, indicates that the
      entity that inserted the *;+sip.608 Feature-Caps value will be
      responsible for indicating to the caller any information contained
      in the 608 SIP response code, specifically the value referenced by
      the Call-Info header


> On Mar 27, 2019, at 12:18 PM, Christer Holmberg =
 wrote:
>=20
> Hi Eric,
>=20
> It seems like you haven=E2=80=99t fixed the Feature-Caps examples, =
based on the earlier discussion (the name of the thread was =E2=80=98Synta=
x of Feature-Caps header=E2=80=99, but I guess you were not made aware =
that it affected the sipcore-rejected draft).
>=20
> The correct way is: Feature-Caps: *;+sip.608
>=20
> Regards,
>=20
> Christer
>=20
> From: sipcore  on behalf of =
"eburger@standardstrack.com" 
> Date: Wednesday, 27 March 2019 at 17.41
> To: "sipcore@ietf.org" 
> Subject: Re: [sipcore] New Version Notification for =
draft-ietf-sipcore-rejected-04.txt
>=20
> Updated all instances of SHOULD xxx UNLESS yyy language to IF NOT yyy =
MUST xxx and took out my annual screed against SHOULD without UNLESS.
>=20
>=20
>> On Mar 27, 2019, at 11:39 AM, internet-drafts@ietf.org wrote:
>>=20
>>=20
>> A new version of I-D, draft-ietf-sipcore-rejected-04.txt
>> has been successfully submitted by Eric W. Burger and posted to the
>> IETF repository.
>>=20
>> Name: draft-ietf-sipcore-rejected
>> Revision: 04
>> Title: A Session Initiation Protocol (SIP) Response Code for Rejected =
Calls
>> Document date: 2019-03-27
>> Group: sipcore
>> Pages: 22
>> URL:            =
https://www.ietf.org/internet-drafts/draft-ietf-sipcore-rejected-04.txt
>> Status:         =
https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/
>> Htmlized:       =
https://tools.ietf.org/html/draft-ietf-sipcore-rejected-04
>> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected
>> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rejected-04
>>=20
>> Abstract:
>>   This document defines the 608 (Rejected) SIP response code.  This
>>   response code enables calling parties to learn that an intermediary
>>   rejected their call attempt.  The call will not be answered.  As a
>>   6xx code, the caller will be aware that future attempts to contact
>>   the same UAS will likely fail.  The present use case driving the =
need
>>   for the 608 response code is when the intermediary is an analytics
>>   engine.  In this case, the rejection is by a machine or other
>>   process.  This contrasts with the 607 (Unwanted) SIP response code,
>>   which a human at the target UAS indicated the call was not wanted.
>>   In some jurisdictions this distinction is important.  This document
>>   also defines the use of the Call-Info header in 608 responses to
>>   enable rejected callers to contact entities that blocked their =
calls
>>   in error.  This provides a remediation mechanism for legal callers
>>   that find their calls blocked.
>>=20
>>=20
>>=20
>>=20
>> 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.
>>=20
>> The IETF Secretariat
>>=20


--Apple-Mail=_13A8332A-C8CF-45B2-920F-425C8BF0DF2D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEfEc/N7T7IfiAuDEHDDCGh758rskFAlycICkACgkQDDCGh758
rsksmg//UDLdT0StR9/RnTTScV2Pp4GS2GB/1MMpnc/TOAmcBYJLqPYMBky0bsld
JPgC8z0TuD5tgndm5IO3tiFGrsycbTi1T70dXssHcx2IUcVyyIwKAftThZ/1L/gk
tkKKk0hN0qZchcZycNAGJWFIa16lJabugFgUUW58/wRK3XVr52vwVvSEiZtwITA8
fgJb0ovkPhGo30jyTTcvLTrUEJ1DtaDLnuCPuRVaEGgqCCOk1GM4KiKdS+a+wxkk
ctg54rWu0TP2GuZSa4K8uk021+ZzUqmxlm6rPL9I2L+gxgMWErXlvx1RzmB3AUmL
BUUJycfMntbGBUVVLg8bf8xEHWW/3LTDQywi/j42uqk++UvSI9KxuitidfExOBqs
/4Z/0EXm1QkHIjGqPEo0nKkbTzG34Mrk0uqbdXg0abMmP+dMXisHpf1myUt8i4hC
SJJs91kxBbvf8gYYRMwVXrqM0hEN4T4t5bjuMGR6uyvcgE2PfCzqEYofx6dsKb3y
mfJz4ZqXQz/s5nruj8kogngjgA8Kdod3arUDjrhJL4qwxg/1+0zss6yJJE+P4Jvd
sUOAmvQyS0dOjHsn5j8TVEJutggSfAoS36X3USK8B02IpXeh+5IYfzoKgeskAIFc
tsn0mHzSg/GdY1zU4o5jBu+HXGQisyhZ+IuKQCmGORpeL1mlEs8=
=dOa4
-----END PGP SIGNATURE-----

--Apple-Mail=_13A8332A-C8CF-45B2-920F-425C8BF0DF2D--


From nobody Wed Mar 27 18:46:30 2019
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 C17BA12016D for ; Wed, 27 Mar 2019 18:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.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 JHU698VuYD2i for ; Wed, 27 Mar 2019 18:46:08 -0700 (PDT)
Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079B8120173 for ; Wed, 27 Mar 2019 18:46:07 -0700 (PDT)
Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-02v.sys.comcast.net with ESMTP id 9IcYh94bG2q1K9K7KhFErh; Thu, 28 Mar 2019 01:46:06 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1553737566; bh=OvTsmObaUuphRqxFgz59IWsjL3YToyfbNMEeAFCx4hs=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=bLqnY1V+zEZWJRxjPRiYNaBJwwsEmITOk9lf7cwg8H2qTg/XmdvGTU+annwagSbEn ldK/SbJ+B9kxPQ+GsDOwtKnOKSm+VqqZUV6hosBZg2bnndH1J+6BLLLe+bMpmKrX+g G19am+7IL7OmC5JUpzXHCe4bxOvbLHezru9z5wA6OTvoN09mlyKIyIDz8CIPTwNxfA FHRzr/rP2up7FA93knt6Wsd9B7LQNr8ymkaCAUTWmVtau9mueASMIvaZv0GBfAE6J/ qgqoPdQFDGLvFWnPSqIBqX3S/ynpINxDcFOBBDCKZMvOTUj1E6cpSLtxuYUefVRKII q8qgGbInrzJ8g==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-16v.sys.comcast.net with ESMTPA id 9K7JhwJoaiROn9K7KhAFev; Thu, 28 Mar 2019 01:46:06 +0000
X-Xfinity-VMeta: sc=-100;st=legit
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id x2S1k4nu019245; Wed, 27 Mar 2019 21:46:04 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id x2S1k4e8019242; Wed, 27 Mar 2019 21:46:04 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Christer Holmberg 
Cc: sipcore@ietf.org
In-Reply-To: <97159F5B-8C69-4B89-A25F-39F95ED57027@ericsson.com> (christer.holmberg@ericsson.com)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Wed, 27 Mar 2019 21:46:04 -0400
Message-ID: <87bm1vlqjn.fsf@hobgoblin.ariadne.com>
Archived-At: 
Subject: Re: [sipcore] reg-event issue with multi-identity/multi-device
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Mar 2019 01:46:29 -0000

Certainly the complaint that the content can become large is valid, as
its size is roughly the product of the number of devices and the number
of AORs.

But using contact references is only going to help when "all the stars
line up".  One of the example contact-registrations is:

    
      sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:aaaa]
      String
      String
    

And this is repeated verbatim for each of the 4 AORs.

But if, on each device, the user has a different display-name for each
of the AORs that can reach the device, then all 12 of the 
elements have different  elements.  So you would need a
mechanism that allows more flexibility than just repeating exactly the
same  element in multiple places.

Compare:  The use of "Accept-Encoding: gzip" and "Content-Encoding:
gzip" is already permitted and standardized.  We already have a
feature-negotiation process for it.  It's true that processing pure
contact-references is faster than un-gzipping and then processing the
full reginfo.  But if your major concern is data length (bandwidth),
gzip is *much* more efficient -- in the example, using
contact-references reduces the text to 2024 characters, but gzipping the
full reginfo gives only 394 octets.

Dale


From nobody Thu Mar 28 00:05:32 2019
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 8940E120442 for ; Thu, 28 Mar 2019 00:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 cXVsgJ-x8961 for ; Thu, 28 Mar 2019 00:05:12 -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 1DFF91203EB for ; Thu, 28 Mar 2019 00:05:11 -0700 (PDT)
Received: from dhcp-99fe.meeting.ietf.org ([IPv6:2001:67c:1232:144:cc62:6814:75e8:efcf]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2S757bE058737 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 28 Mar 2019 02:05:09 -0500 (CDT) (envelope-from mahoney@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553756709; bh=7VPXEDoFIKQT2C+PTDid42z9DFtaUh0rxy/dLX2eyrs=; h=Subject:To:References:From:Date:In-Reply-To; b=tZT1P38VLv63jkrxaWg73XZPiNIdNevTK8uYiiUgxhJvXc34yNpNZwbBW3UeovAAX Pp3Elf6wMgohOGN0ah8qUt8Jk2Vh2q0BI33gvj7E7gf1ZGrTeNEddJCursAAYGskVA o0+EuBHME04QO7j7CadaP1aUfCUuUKOkkWus8zBI=
X-Authentication-Warning: raven.nostrum.com: Host [IPv6:2001:67c:1232:144:cc62:6814:75e8:efcf] claimed to be dhcp-99fe.meeting.ietf.org
To: Eric Burger , SIPCORE 
References: <155370116735.10357.14550485597454442062.idtracker@ietfa.amsl.com> <6FADC6F0-A88A-43B8-90B2-2143834B5879@standardstrack.com>
From: "A. Jean Mahoney" 
Message-ID: <0690e1f9-b4dc-a9e7-199b-30697e737bf6@nostrum.com>
Date: Thu, 28 Mar 2019 08:05:06 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <6FADC6F0-A88A-43B8-90B2-2143834B5879@standardstrack.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [sipcore] New Version Notification for draft-ietf-sipcore-rejected-04.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Mar 2019 07:05:30 -0000

Thanks for making the changes, Eric. I'll finish up my Doc Shepherd 
review when I get back from the IETF meeting.

I understand being frustrated with the normative terminology 
boilerplate. Maybe you could take the UNLESS idea to IETF General 
mailing list ;-)

Jean


On 3/27/19 4:41 PM, Eric Burger wrote:
> Updated all instances of SHOULD /xxx/UNLESS /yyy/language to IF NOT 
> /yyy/MUST /xxx/ and took out my annual screed against SHOULD without 
> UNLESS.
> 
>> On Mar 27, 2019, at 11:39 AM, internet-drafts@ietf.org 
>>  wrote:
>>
>>
>> A new version of I-D, draft-ietf-sipcore-rejected-04.txt
>> has been successfully submitted by Eric W. Burger and posted to the
>> IETF repository.
>>
>> Name:draft-ietf-sipcore-rejected
>> Revision:04
>> Title:A Session Initiation Protocol (SIP) Response Code for Rejected Calls
>> Document date:2019-03-27
>> Group:sipcore
>> Pages:22
>> URL: 
>> https://www.ietf.org/internet-drafts/draft-ietf-sipcore-rejected-04.txt
>> Status: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/
>> Htmlized: https://tools.ietf.org/html/draft-ietf-sipcore-rejected-04
>> Htmlized: 
>> https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected
>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rejected-04
>>
>> Abstract:
>> This document defines the 608 (Rejected) SIP response code. This
>> response code enables calling parties to learn that an intermediary
>> rejected their call attempt. The call will not be answered. As a
>> 6xx code, the caller will be aware that future attempts to contact
>> the same UAS will likely fail. The present use case driving the need
>> for the 608 response code is when the intermediary is an analytics
>> engine. In this case, the rejection is by a machine or other
>> process. This contrasts with the 607 (Unwanted) SIP response code,
>> which a human at the target UAS indicated the call was not wanted.
>> In some jurisdictions this distinction is important. This document
>> also defines the use of the Call-Info header in 608 responses to
>> enable rejected callers to contact entities that blocked their calls
>> in error. This provides a remediation mechanism for legal callers
>> that find their calls blocked.
>>
>>
>>
>>
>> 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 
>> .
>>
>> The IETF Secretariat
>>
> 
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 


From nobody Thu Mar 28 00:31:57 2019
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 2D18912036B for ; Thu, 28 Mar 2019 00:31:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 PaTmBkb0q6kP for ; Thu, 28 Mar 2019 00:31:50 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70072.outbound.protection.outlook.com [40.107.7.72]) (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 B1B49120144 for ; Thu, 28 Mar 2019 00:31:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YpkXt4z0OYCaZUD4yTTLqBEWZwKCJD0SxGxA9vLpXnY=; b=H1AlL/+LObdqcqFWBjo1y2xvoWzCOfeIMuc+CQrJH89BdkbsU4PUdzYnxDjZS9Zp7lJkev+Lm90TD7uhtBxK3DKY9OOnwzuRXiVvUmvmYLzH7EhOuNKvFN/cCiFIAHpaMnb+nlUHRARnVT3YnehP8pYP5cols06U0abJzSgFU8U=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB0953.eurprd07.prod.outlook.com (10.162.27.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Thu, 28 Mar 2019 07:31:46 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1750.014; Thu, 28 Mar 2019 07:31:46 +0000
From: Christer Holmberg 
To: Eric Burger 
CC: SIPCORE 
Thread-Topic: [sipcore] New Version Notification for draft-ietf-sipcore-rejected-04.txt
Thread-Index: AQHU5LOVYpwqVzcj/kqOAsFHInHdFKYfyY2AgAB0eICAAIqzAA==
Date: Thu, 28 Mar 2019 07:31:46 +0000
Message-ID: <446B9425-65D8-469F-A92E-4887EF150FAA@ericsson.com>
References: <155370116735.10357.14550485597454442062.idtracker@ietfa.amsl.com> <6FADC6F0-A88A-43B8-90B2-2143834B5879@standardstrack.com> <223874A0-4F48-4684-BC96-2F4B84F82C0E@ericsson.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 66d656cf-a6b0-4bf3-c7c5-08d6b34f6f1e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB0953; 
x-ms-traffictypediagnostic: HE1PR07MB0953:
x-ms-exchange-purlcount: 5
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0990C54589
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(136003)(366004)(39860400002)(189003)(199004)(15650500001)(476003)(25786009)(11346002)(446003)(478600001)(2616005)(966005)(486006)(76176011)(316002)(58126008)(26005)(102836004)(99286004)(186003)(53546011)(6506007)(105586002)(66066001)(36756003)(86362001)(7736002)(82746002)(106356001)(305945005)(33656002)(71200400001)(6436002)(6486002)(6916009)(14444005)(256004)(6512007)(6306002)(2906002)(53936002)(71190400001)(83716004)(97736004)(14454004)(66574012)(6246003)(6116002)(44832011)(3846002)(5660300002)(8676002)(229853002)(81156014)(81166006)(8936002)(68736007)(93886005)(4326008)(21314003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB0953; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: CoiZIYw9iHCcO3duAU4/iYU3uM2yiRXRcii9rEt8KA+jeQJ976pLRAUTO7wpE/c/1yVj5hkEt0sSrl/KrZnvLZ/002gPlcC3W9davHLkgpwTzSE/07LS2U/7vIWAQ0FzVh5dlVcGv/lzmeeD7NxwZIqNkNfwS1D47bSS2SYGyTvr8OcQ6IHH/ALUIJnmBlbhmIIl/uYM0JQHptYyUFW7cb8rQiZRzmYfPtIBpJF8kDsp8koW+TGOsPyy4OSiddDl8S5DQFfzpn+YOdESk3TpFOAT/yn6Tnr7lpLt1dNXNttpIhcvEnBoiXjw45LP21oApD+258nZBWLPi3KE9eYAp3g+oLJpArN08FPhTMprLyAIe9MCquhPZJG3AW3GYAkYFD1h78g/KFjfMmXT1ze7KHB/fz55W0dkLMPBnFnC4pE=
Content-Type: text/plain; charset="utf-8"
Content-ID: <435FAC8925B7C54A92BDE3F2769B0C91@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 66d656cf-a6b0-4bf3-c7c5-08d6b34f6f1e
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2019 07:31:46.6209 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0953
Archived-At: 
Subject: Re: [sipcore] New Version Notification for draft-ietf-sipcore-rejected-04.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Mar 2019 07:31:56 -0000

SGksDQoNCj4gIFRoYW5rcyEgSSB0b3RhbGx5IG1pc3NlZCB0aGUgdGhyZWFkLiBPbmUgcXVlc3Rp
b24sIGJlc2lkZXMgdXBkYXRpbmcgdGhlIGV4YW1wbGUsIHdoYXQgc2hvdWxkIEkgc2F5IGluIHRo
ZSB0ZXh0PyANCj4gU2luY2UgRmVhdHVyZS1DYXBzIGlzIGEgbGlzdCwgc2hvdWxkIEkgc2F5Og0K
PiAgICANCj4gICAgICAgTmFtZTogIHNpcC42MDgNCiAgDQpUaGlzIGlzIHRoZSBjb3JyZWN0IHdh
eS4NCg0KPiAgICAgICBEZXNjcmlwdGlvbjogIFRoaXMgZmVhdHVyZSBjYXBhYmlsaXR5IGluZGlj
YXRvciwgd2hlbiBpbmNsdWRlZCBpbiBhDQo+ICAgICAgICAgIEZlYXR1cmUtQ2FwcyBoZWFkZXIg
ZmllbGQgb2YgYW4gSU5WSVRFIHJlcXVlc3QsIGluZGljYXRlcyB0aGF0IHRoZQ0KPiAgICAgICAg
ICBlbnRpdHkgdGhhdCBpbnNlcnRlZCB0aGUgc2lwLjYwOCBGZWF0dXJlLUNhcHMgdmFsdWUgd2ls
bCBiZQ0KPiAgICAgICAgICByZXNwb25zaWJsZSBmb3IgaW5kaWNhdGluZyB0byB0aGUgY2FsbGVy
IGFueSBpbmZvcm1hdGlvbiBjb250YWluZWQNCj4gICAgICAgICAgaW4gdGhlIDYwOCBTSVAgcmVz
cG9uc2UgY29kZSwgc3BlY2lmaWNhbGx5IHRoZSB2YWx1ZSByZWZlcmVuY2VkIGJ5DQo+ICAgICAg
ICAgIHRoZSBDYWxsLUluZm8gaGVhZGVyDQogIA0KSSBzdWdnZXN0IHRoZSBmb2xsb3dpbmcgbW9k
aWZpZWQgdGV4dDoNCg0KICAgICAgICAgICBEZXNjcmlwdGlvbjogIFRoaXMgZmVhdHVyZSBjYXBh
YmlsaXR5IGluZGljYXRvciwgd2hlbiBpbmNsdWRlZCBpbiBhDQogICAgICAgICAgICAgRmVhdHVy
ZS1DYXBzIGhlYWRlciBmaWVsZCBvZiBhbiBJTlZJVEUgcmVxdWVzdCwgaW5kaWNhdGVzIHRoYXQg
dGhlDQogICAgICAgICAgICAgZW50aXR5IGFzc29jaWF0ZWQgd2l0aCB0aGUgaW5kaWNhdG9yLCB3
aWxsIGJlIHJlc3BvbnNpYmxlIGZvciBpbmRpY2F0aW5nIHRvDQogICAgICAgICAgICAgdGhlIGNh
bGxlciBhbnkgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoZSA2MDggU0lQIHJlc3BvbnNlIGNv
ZGUsIHNwZWNpZmljYWxseSANCiAgICAgICAgICAgICB0aGUgdmFsdWUgcmVmZXJlbmNlZCBieSB0
aGUgQ2FsbC1JbmZvIGhlYWRlcg0KICANClRoYXQgd2F5IHlvdSBkb24ndCBuZWVkIHRvIHJlcGVh
dCB0aGUgdmFsdWUgaW4gdGhlIGRlc2NyaXB0aW9uIHRleHQuDQoNClJlZ2FyZHMsDQoNCkNocmlz
dGVyDQogICAgDQogICAgDQogICAgPiBPbiBNYXIgMjcsIDIwMTksIGF0IDEyOjE4IFBNLCBDaHJp
c3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCiAg
ICA+IA0KICAgID4gSGkgRXJpYywNCiAgICA+IA0KICAgID4gSXQgc2VlbXMgbGlrZSB5b3UgaGF2
ZW7igJl0IGZpeGVkIHRoZSBGZWF0dXJlLUNhcHMgZXhhbXBsZXMsIGJhc2VkIG9uIHRoZSBlYXJs
aWVyIGRpc2N1c3Npb24gKHRoZSBuYW1lIG9mIHRoZSB0aHJlYWQgd2FzIOKAmFN5bnRheCBvZiBG
ZWF0dXJlLUNhcHMgaGVhZGVy4oCZLCBidXQgSSBndWVzcyB5b3Ugd2VyZSBub3QgbWFkZSBhd2Fy
ZSB0aGF0IGl0IGFmZmVjdGVkIHRoZSBzaXBjb3JlLXJlamVjdGVkIGRyYWZ0KS4NCiAgICA+IA0K
ICAgID4gVGhlIGNvcnJlY3Qgd2F5IGlzOiBGZWF0dXJlLUNhcHM6ICo7K3NpcC42MDgNCiAgICA+
IA0KICAgID4gUmVnYXJkcywNCiAgICA+IA0KICAgID4gQ2hyaXN0ZXINCiAgICA+IA0KICAgID4g
RnJvbTogc2lwY29yZSA8c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgImVi
dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tIiA8ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20+DQog
ICAgPiBEYXRlOiBXZWRuZXNkYXksIDI3IE1hcmNoIDIwMTkgYXQgMTcuNDENCiAgICA+IFRvOiAi
c2lwY29yZUBpZXRmLm9yZyIgPHNpcGNvcmVAaWV0Zi5vcmc+DQogICAgPiBTdWJqZWN0OiBSZTog
W3NpcGNvcmVdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zaXBjb3Jl
LXJlamVjdGVkLTA0LnR4dA0KICAgID4gDQogICAgPiBVcGRhdGVkIGFsbCBpbnN0YW5jZXMgb2Yg
U0hPVUxEIHh4eCBVTkxFU1MgeXl5IGxhbmd1YWdlIHRvIElGIE5PVCB5eXkgTVVTVCB4eHggYW5k
IHRvb2sgb3V0IG15IGFubnVhbCBzY3JlZWQgYWdhaW5zdCBTSE9VTEQgd2l0aG91dCBVTkxFU1Mu
DQogICAgPiANCiAgICA+IA0KICAgID4+IE9uIE1hciAyNywgMjAxOSwgYXQgMTE6MzkgQU0sIGlu
dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCiAgICA+PiANCiAgICA+PiANCiAgICA+PiBB
IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1zaXBjb3JlLXJlamVjdGVkLTA0LnR4dA0K
ICAgID4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRXJpYyBXLiBCdXJnZXIg
YW5kIHBvc3RlZCB0byB0aGUNCiAgICA+PiBJRVRGIHJlcG9zaXRvcnkuDQogICAgPj4gDQogICAg
Pj4gTmFtZTogZHJhZnQtaWV0Zi1zaXBjb3JlLXJlamVjdGVkDQogICAgPj4gUmV2aXNpb246IDA0
DQogICAgPj4gVGl0bGU6IEEgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIFJlc3Bv
bnNlIENvZGUgZm9yIFJlamVjdGVkIENhbGxzDQogICAgPj4gRG9jdW1lbnQgZGF0ZTogMjAxOS0w
My0yNw0KICAgID4+IEdyb3VwOiBzaXBjb3JlDQogICAgPj4gUGFnZXM6IDIyDQogICAgPj4gVVJM
OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1p
ZXRmLXNpcGNvcmUtcmVqZWN0ZWQtMDQudHh0DQogICAgPj4gU3RhdHVzOiAgICAgICAgIGh0dHBz
Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2lwY29yZS1yZWplY3RlZC8N
CiAgICA+PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWlldGYtc2lwY29yZS1yZWplY3RlZC0wNA0KICAgID4+IEh0bWxpemVkOiAgICAgICBodHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtc2lwY29yZS1yZWplY3Rl
ZA0KICAgID4+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy
bDI9ZHJhZnQtaWV0Zi1zaXBjb3JlLXJlamVjdGVkLTA0DQogICAgPj4gDQogICAgPj4gQWJzdHJh
Y3Q6DQogICAgPj4gICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIDYwOCAoUmVqZWN0ZWQpIFNJ
UCByZXNwb25zZSBjb2RlLiAgVGhpcw0KICAgID4+ICAgcmVzcG9uc2UgY29kZSBlbmFibGVzIGNh
bGxpbmcgcGFydGllcyB0byBsZWFybiB0aGF0IGFuIGludGVybWVkaWFyeQ0KICAgID4+ICAgcmVq
ZWN0ZWQgdGhlaXIgY2FsbCBhdHRlbXB0LiAgVGhlIGNhbGwgd2lsbCBub3QgYmUgYW5zd2VyZWQu
ICBBcyBhDQogICAgPj4gICA2eHggY29kZSwgdGhlIGNhbGxlciB3aWxsIGJlIGF3YXJlIHRoYXQg
ZnV0dXJlIGF0dGVtcHRzIHRvIGNvbnRhY3QNCiAgICA+PiAgIHRoZSBzYW1lIFVBUyB3aWxsIGxp
a2VseSBmYWlsLiAgVGhlIHByZXNlbnQgdXNlIGNhc2UgZHJpdmluZyB0aGUgbmVlZA0KICAgID4+
ICAgZm9yIHRoZSA2MDggcmVzcG9uc2UgY29kZSBpcyB3aGVuIHRoZSBpbnRlcm1lZGlhcnkgaXMg
YW4gYW5hbHl0aWNzDQogICAgPj4gICBlbmdpbmUuICBJbiB0aGlzIGNhc2UsIHRoZSByZWplY3Rp
b24gaXMgYnkgYSBtYWNoaW5lIG9yIG90aGVyDQogICAgPj4gICBwcm9jZXNzLiAgVGhpcyBjb250
cmFzdHMgd2l0aCB0aGUgNjA3IChVbndhbnRlZCkgU0lQIHJlc3BvbnNlIGNvZGUsDQogICAgPj4g
ICB3aGljaCBhIGh1bWFuIGF0IHRoZSB0YXJnZXQgVUFTIGluZGljYXRlZCB0aGUgY2FsbCB3YXMg
bm90IHdhbnRlZC4NCiAgICA+PiAgIEluIHNvbWUganVyaXNkaWN0aW9ucyB0aGlzIGRpc3RpbmN0
aW9uIGlzIGltcG9ydGFudC4gIFRoaXMgZG9jdW1lbnQNCiAgICA+PiAgIGFsc28gZGVmaW5lcyB0
aGUgdXNlIG9mIHRoZSBDYWxsLUluZm8gaGVhZGVyIGluIDYwOCByZXNwb25zZXMgdG8NCiAgICA+
PiAgIGVuYWJsZSByZWplY3RlZCBjYWxsZXJzIHRvIGNvbnRhY3QgZW50aXRpZXMgdGhhdCBibG9j
a2VkIHRoZWlyIGNhbGxzDQogICAgPj4gICBpbiBlcnJvci4gIFRoaXMgcHJvdmlkZXMgYSByZW1l
ZGlhdGlvbiBtZWNoYW5pc20gZm9yIGxlZ2FsIGNhbGxlcnMNCiAgICA+PiAgIHRoYXQgZmluZCB0
aGVpciBjYWxscyBibG9ja2VkLg0KICAgID4+IA0KICAgID4+IA0KICAgID4+IA0KICAgID4+IA0K
ICAgID4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm
cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICA+PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy
c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgID4+IA0K
ICAgID4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQogICAgPj4gDQogICAgDQogICAgDQoNCg==


From nobody Thu Mar 28 00:36:53 2019
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 6CE27120170 for ; Thu, 28 Mar 2019 00:36:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 eASYhOAJrEsT for ; Thu, 28 Mar 2019 00:36:49 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30081.outbound.protection.outlook.com [40.107.3.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9956E120144 for ; Thu, 28 Mar 2019 00:36:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NBSwl4fKYr43EvBVB1FDNBtdOvjmkD7YFeZ3wYOxFIo=; b=LlHXwGcMvrT3uUOn36E/sXIJ3ZgdjH+k+pJB3AYQlzhYbnkxcL8ny79DEvLbYra79CA9Z367ol2Kl8LlK8rgVCsozkOBICLcyW0pTMSTwzoYucoO98HStOq+LjOnBxATRGT/RTAm2xLe1gVXIkxHV80RENjL0I85G4ZckrlPz3k=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4170.eurprd07.prod.outlook.com (20.176.166.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Thu, 28 Mar 2019 07:36:46 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1750.014; Thu, 28 Mar 2019 07:36:46 +0000
From: Christer Holmberg 
To: Paul Kyzivat , "sipcore@ietf.org" 
Thread-Topic: [sipcore] reg-event issue with multi-identity/multi-device
Thread-Index: AQHU5Jj/Nwtdx+7wP0OSgkyGhayhm6YfrLGAgABtxID///yqgIAAszKA
Date: Thu, 28 Mar 2019 07:36:45 +0000
Message-ID: 
References: <97159F5B-8C69-4B89-A25F-39F95ED57027@ericsson.com>  <678C20F0-8D1E-44A5-897F-70B521036B63@ericsson.com> <44d66095-73c1-2ded-d70f-63057398325c@alum.mit.edu>
In-Reply-To: <44d66095-73c1-2ded-d70f-63057398325c@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b98d8743-2f71-40cb-1ff4-08d6b350218c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4170; 
x-ms-traffictypediagnostic: HE1PR07MB4170:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0990C54589
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(136003)(39860400002)(366004)(189003)(199004)(3846002)(5660300002)(66066001)(86362001)(2501003)(478600001)(7736002)(102836004)(11346002)(25786009)(93886005)(6116002)(33656002)(14454004)(966005)(446003)(8936002)(2616005)(476003)(71200400001)(58126008)(83716004)(71190400001)(68736007)(486006)(97736004)(53936002)(36756003)(229853002)(81156014)(81166006)(6512007)(76176011)(2171002)(6306002)(99286004)(26005)(110136005)(53946003)(82746002)(105586002)(6486002)(44832011)(305945005)(14444005)(6506007)(8676002)(256004)(2906002)(6436002)(53546011)(106356001)(316002)(6246003)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4170; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: hgMXtjPSI3bsGCA0xQ+B6Ex0Zn5UBm8q7I361gW+D94CpWUWBuO7Dkx8IReVcbttt4YTFdTo1llyuxYouCerVAU6i1dbiDDHXOWo2DDTg8Ta3PMAb0l6SFD2vDSKwAzNIPssArDYyArgC4JYX8jNy01IC3f+RvIyNi4SadaiINQhD4YntU/jPd3c1NLBJA10T3QTFwdLC9TlIZ1BESQuNseQIk7typvJhGRFstt913XOoNS9xghU5YqXZuxAOZjsa6iPNO/PLG4ogPS0GWVo8KlD6Xe7wv6R1CXQa2RUNUMayNWFNGQgtd5drz5sBfoQET45Zp9Eu3887VoX//RsG9wivO2QpGpI8aM9Pe8ZvTPjHEhueFlcBXFwtdbPnRckVsriIk0K+wLLLRnCeD3GNZCjlCKZA3SaLxTx4LiiF/A=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b98d8743-2f71-40cb-1ff4-08d6b350218c
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2019 07:36:45.9950 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4170
Archived-At: 
Subject: Re: [sipcore] reg-event issue with multi-identity/multi-device
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Mar 2019 07:36:52 -0000

SGksDQoNCiAgICA+Pj4gICAgIEkgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbS4gQnV0IEkgdGhpbmsg
d2UgbmVlZCB0byBhc3Nlc3Mgd2hldGhlciB0aGUNCiAgICA+Pj4gICAgIHByb2JsZW0gaXMgc2V2
ZXJlIGVub3VnaCB0byBqdXN0aWZ5IHRoZSBlZmZvcnQgb2YgZGVwbG95aW5nIGEgc29sdXRpb24u
DQogICAgPj4gDQogICAgPj4gSXQgaXMgY2F1c2luZyBwcm9ibGVtcywgYW5kIHBlb3BsZSBoYXZl
IGJlZW4gYXNrZWQgdG8gZmluZCBhIHNvbHV0aW9uLg0KICAgID4+IA0KICAgID4+PiAgICAgSW4g
YW55IGNhc2UgSSBndWVzcyBhIHNvbHV0aW9uIHdvdWxkIGhhdmUgdG8gaW5jbHVkZSBiYWNrd2Fy
ZA0KICAgID4+PiAgICAgY29tcGF0aWJpbGl0eSwgc28gaXQgd291bGQgb25seSBiZSBhcHBsaWVk
IGlmIGJvdGggY2xpZW50IGFuZCBzZXJ2ZXINCiAgICA+Pj4gICAgIHN1cHBvcnQgaXQgYXMgYW4g
ZXh0ZW5zaW9uLg0KICAgID4+ICAgIA0KICAgID4+IFN1cmUuDQogICAgPj4gDQogICAgPj4+ICAg
ICBUaGUgc29sdXRpb24geW91IG91dGxpbmUgaXMgc3RyYWlnaHRmb3J3YXJkLiBCdXQgaWYgZG9p
bmcgc29tZXRoaW5nIGl0DQogICAgPj4+ICAgICBtaWdodCBiZSBiZXR0ZXIgdG8ganVzdCBkbyBn
ZW5lcmFsIGNvbXByZXNzaW9uLiBJIHRoaW5rIHRoZXJlIGFyZQ0KICAgID4+PiAgICAgYWxyZWFk
eSBNSU1FIHR5cGVzIGZvciBjYXJyeWluZyBjb21wcmVzc2VkIGRhdGEuIEkgZG9uJ3Qga25vdyB3
aGV0aGVyDQogICAgPj4+ICAgICB0aGV5IGFyZSBzdWl0YWJsZSBoZXJlLCBidXQgaWYgc28gaXQg
bWlnaHQgbWVhbiBvZmYtdGhlLXNoZWxmIGNvZGUgaXMNCiAgICA+Pj4gICAgIGF2YWlsYWJsZS4N
CiAgICA+PiAgICANCiAgICA+PiBFdmVuIGlmIHlvdSBjb21wcmVzcywgdGhlIHJlY2VpdmVyIHdp
bGwgc3RpbGwgaGF2ZSB0byBkZS1jb21wcmVzcywgcGFyc2UgYW5kIHByb2Nlc3MgZXZlcnl0aGlu
ZyBldGMsIHNvIGl0IHdhcyBub3Qgc2VlbiBhcyBhIGdvb2Qgc29sdXRpb24uDQogICAgPg0KICAg
ID4gVGhlIHJlY2VpdmVyIGhhcyB0byBjaGFuZ2UgdGhlaXIgZGVjb2Rpbmcgb2YgdGhlIHhtbCBy
ZXNwb25zZSwgd2hpbGUgDQogICAgPiBzdGlsbCByZXRhaW5pbmcgdGhlIG9sZCBwcm9jZXNzaW5n
IGluIGNhc2UgdGhlIHNlcnZlciBkb2Vzbid0IHN1cHBvcnQgDQogICAgPiB0aGlzIG5ldyBmZWF0
dXJlLg0KICAgID4NCiAgICA+IFdpdGggY29tcHJlc3Npb24gaXQgbWF5IGJlIG5vIG1vcmUgdGhh
biBtYWtpbmcgYSBsaWJyYXJ5IGNhbGwgdG8gDQogICAgPiBkZWNvbXByZXNzIHRoZSByZXNwb25z
ZSBhbmQgdGhlbiBwcm9jZXNzIG5vcm1hbGx5LiBTbyBpdCAqY291bGQqIGJlIGVhc2llci4NCg0K
ICAgIElmIGl0IHdhcyBvbmx5IGFib3V0IGEgbGFyZ2UgYW1vdW50IG9mIGRhdGEgaW4gZ2VuZXJh
bCwgSSBhZ3JlZSBjb21wcmVzc2lvbiB3b3VsZCBiZSBhIGdvb2Qgc29sdXRpb24uDQoNCiAgICBC
dXQsIHRoZSBwcm9ibGVtIGlzIGEgbGFyZ2UgYW1vdW50IG9mICpkdXBsaWNhdGVkKiBkYXRhLCBh
bmQgdGhlIHByb2JsZW0gd2lsbCBvbmx5IGdldCB3b3JzZSB0aGUgbW9yZSBwaG9uZSBudW1iZXJz
LCBkZXZpY2VzIGFuZC9vciBjb250YWN0cyB5b3UgYWRkLiBJdCBpcyBiYWQgZGVzaWduIGFuZCBp
dCBkb2VzIG5vdCBzY2FsZS4NCiAgDQogICAgUmVnYXJkcywNCg0KICAgIENocmlzdGVyDQoNCg0K
DQoNCg0KICAgID4gICAgICANCiAgICA+ICAgICAgT24gMy8yNy8xOSA4OjMxIEFNLCBDaHJpc3Rl
ciBIb2xtYmVyZyB3cm90ZToNCiAgICA+ICAgICAgPiAgICAgICAgSGksDQogICAgPiAgICAgID4N
CiAgICA+ICAgICAgPiAgICAgICAgICAzR1BQIGRlZmluZXMg4oCdbXVsdGkgaWRlbnRpdHnigJ0g
YW5kIOKAnW11bHRpIGRldmljZXPigJ0gY29uY2VwdHMsIHdoaWNoIG1lYW5zIHRoYXQ6DQogICAg
PiAgICAgID4NCiAgICA+ICAgICAgPiAgICAgICAgICAxKSBBIHVzZXIgY2FuIGhhdmUgbXVsdGlw
bGUgcGhvbmUgbnVtYmVyczsgYW5kDQogICAgPiAgICAgID4gICAgICAgICAgMikgQSB1c2VyIGNh
biBoYXZlIG11bHRpcGxlIGRldmljZXMsIGVhY2ggb2Ygd2hpY2ggY2FuIGJlIHJlYWNoZWQgd2l0
aCBhbnkgb2YgdGhvc2UgcGhvbmUgbnVtYmVycw0KICAgID4gICAgICA+DQogICAgPiAgICAgID4g
ICAgICAgICAgQXNzdW1lIGEgdXNlciBoYXM6DQogICAgPiAgICAgID4NCiAgICA+ICAgICAgPiAg
ICAgICAgICAxKSAyIHBob25lIG51bWJlcnMsIGVhY2ggd2l0aCBhIFNJUCBVUkkgYW5kIGEgdGVs
IFVSSSByZXByZXNlbnRhdGlvbiAoInBob25lX251bWJlcjEvU0lQIiwgInBob25lX251bWJlcjEv
VEVMIiwgInBob25lX251bWJlcjIvU0lQIiBhbmQgInBob25lX251bWJlcjIvVEVMIikNCiAgICA+
ICAgICAgPiAgICAgICAgICAyKSBEaWZmZXJlbnQgZGV2aWNlcywgZWFjaCB3aXRoIGEgZGlmZmVy
ZW50IGNvbnRhY3QgSVAgYWRkcmVzcyAoIklQLUFkZHJlc3MxIiwgIklQLUFkZHJlc3MyIiBhbmQg
IklQLUFkZHJlc3MzIikNCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+ICAgICAgICAgIEEgc2lt
cGxpZmllZCByZWctZXZlbnQgbm90aWZpY2F0aW9uIHdvdWxkIGxvb2sgbGlrZSB0aGlzOg0KICAg
ID4gICAgICA+DQogICAgPiAgICAgID4gICAgICAgICAgPHJlZ2lzdHJhdGlvbiBhb3I9c2lwOnBo
b25lX251bWJlcjEvU0lQIGlkPSIxIiBzdGF0ZT0iYWN0aXZlIj4NCiAgICA+ICAgICAgPiAgICAg
ICAgICAgCTxjb250YWN0PiA8dXJpPklQLUFkZHJlc3MxPC91cmk+PC9jb250YWN0Pg0KICAgID4g
ICAgICA+ICAgICAgICAgICAJPGNvbnRhY3Q+IDx1cmk+SVAtQWRkcmVzczI8L3VyaT48L2NvbnRh
Y3Q+DQogICAgPiAgICAgID4gICAgICAgICAgIAk8Y29udGFjdD4gPHVyaT5JUC1BZGRyZXNzMzwv
dXJpPjwvY29udGFjdD4NCiAgICA+ICAgICAgPiAgICAgICAgICA8cmVnaXN0cmF0aW9uIGFvcj10
ZWw6cGhvbmVfbnVtYmVyMS9URUwgaWQ9IjIiIHN0YXRlPSJhY3RpdmUiPg0KICAgID4gICAgICA+
ICAgICAgICAgICAJPGNvbnRhY3Q+IDx1cmk+SVAtQWRkcmVzczE8L3VyaT48L2NvbnRhY3Q+DQog
ICAgPiAgICAgID4gICAgICAgICAgIAk8Y29udGFjdD4gPHVyaT5JUC1BZGRyZXNzMjwvdXJpPjwv
Y29udGFjdD4NCiAgICA+ICAgICAgPiAgICAgICAgICAgCTxjb250YWN0PiA8dXJpPklQLUFkZHJl
c3MzPC91cmk+PC9jb250YWN0Pg0KICAgID4gICAgICA+ICAgICAgICAgIDxyZWdpc3RyYXRpb24g
YW9yPXNpcDpwaG9uZV9udW1iZXIyL1NJUCBpZD0iMSIgc3RhdGU9ImFjdGl2ZSI+DQogICAgPiAg
ICAgID4gICAgICAgICAgIAk8Y29udGFjdD4gPHVyaT5JUC1BZGRyZXNzMTwvdXJpPjwvY29udGFj
dD4NCiAgICA+ICAgICAgPiAgICAgICAgICAgCTxjb250YWN0PiA8dXJpPklQLUFkZHJlc3MyPC91
cmk+PC9jb250YWN0Pg0KICAgID4gICAgICA+ICAgICAgICAgICAJPGNvbnRhY3Q+IDx1cmk+SVAt
QWRkcmVzczM8L3VyaT48L2NvbnRhY3Q+DQogICAgPiAgICAgID4gICAgICAgICAgPHJlZ2lzdHJh
dGlvbiBhb3I9dGVsOnBob25lX251bWJlcjIvVEVMIGlkPSIyIiBzdGF0ZT0iYWN0aXZlIj4NCiAg
ICA+ICAgICAgPiAgICAgICAgICAgCTxjb250YWN0PiA8dXJpPklQLUFkZHJlc3MxPC91cmk+PC9j
b250YWN0Pg0KICAgID4gICAgICA+ICAgICAgICAgICAJPGNvbnRhY3Q+IDx1cmk+SVAtQWRkcmVz
czI8L3VyaT48L2NvbnRhY3Q+DQogICAgPiAgICAgID4gICAgICAgICAgIAk8Y29udGFjdD4gPHVy
aT5JUC1BZGRyZXNzMzwvdXJpPjwvY29udGFjdD4NCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+
ICAgICAgICAgIEFzIHlvdSBjYW4gc2VlLCB0aGUgY29udGFjdCBpbmZvcm1hdGlvbiBpcyBkdXBs
aWNhdGVkIG1hbnkgdGltZXMuDQogICAgPiAgICAgID4NCiAgICA+ICAgICAgPiAgICAgICAgICBV
c2luZyBhbiBleGFtcGxlIGJhc2VkIG9uIHRoZSBYTUwgc2NoZW1hIGluIFJGQyAzNjgwIHNob3dz
IHRoYXQgdGhlIHBheWxvYWQgY2FuIGdldCB2ZXJ5IGJpZyAoSSBhbSB1c2luZyBlbXB0eSBsaW5l
cyBmb3IgcmVhZGFiaWxpdHkpOg0KICAgID4gICAgICA+DQogICAgPiAgICAgID4gICAgICAgICAg
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCiAgICA+ICAgICAgPiAgICAg
ICAgICA8IS0tU2FtcGxlIFhNTCBmaWxlIGdlbmVyYXRlZCBieSBYTUxTcHkgdjIwMDggKGh0dHA6
Ly93d3cuYWx0b3ZhLmNvbSktLT4NCiAgICA+ICAgICAgPiAgICAgICAgICA8dG5zOnJlZ2luZm8g
c3RhdGU9ImZ1bGwiIHZlcnNpb249IjAiIHhzaTpzY2hlbWFMb2NhdGlvbj0idXJuOmlldGY6cGFy
YW1zOnhtbDpuczpyZWdpbmZvIFVudGl0bGVkMS54c2QiIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53
My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnRucz0idXJuOmlldGY6cGFyYW1z
OnhtbDpuczpyZWdpbmZvIj4NCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+ICAgICAgICAgIDx0
bnM6cmVnaXN0cmF0aW9uIGlkPSIxMjM0NTY3ODkwIiBhb3I9InNpcDptYWlsdG86KzE1NTU2NjY3
Nzc3QGltcy5tbmMwMDEubWNjMDAxLjNncHBuZXR3b3Jrcy5vcmciPg0KICAgID4gICAgICA+ICAg
ICAgICAgICAgICA8dG5zOmNvbnRhY3QgZXZlbnQ9InJlZ2lzdGVyZWQiIGlkPSIyMzQ1Njc4OTAx
IiBkdXJhdGlvbi1yZWdpc3RlcmVkPSI0Mjk0OTY3Mjk1Ig0KICAgID4gICAgICA+ICAgICAgICAg
ICAgICAgICAgIGNzZXE9IjQyOTQ5NjcyOTUiIHJldHJ5LWFmdGVyPSI0Mjk0OTY3Mjk1IiBxPSIw
IiBzdGF0ZT0iYWN0aXZlIg0KICAgID4gICAgICA+ICAgICAgICAgICAgICAgICAgIGNhbGxpZD0i
U3RyaW5nIiBleHBpcmVzPSI0Mjk0OTY3Mjk1Ij4NCiAgICA+ICAgICAgPiAgICAgICAgICAgICAg
ICA8dG5zOnVyaT5zaXA6KzE1NTU2NjY3Nzc3QFsyMDAxOjBkYjg6ODVhMzowMDAwOjAwMDA6OGEy
ZTowMzcwOmFhYWFdPC90bnM6dXJpPg0KICAgID4gICAgICA+ICAgICAgICAgICAgICAgIDx0bnM6
ZGlzcGxheS1uYW1lIHhtbDpsYW5nPSJlbi11cyI+U3RyaW5nPC90bnM6ZGlzcGxheS1uYW1lPg0K
ICAgID4gICAgICA+ICAgICAgICAgICAgICAgIDx0bnM6dW5rbm93bi1wYXJhbSBuYW1lPSJTdHJp
bmciPlN0cmluZzwvdG5zOnVua25vd24tcGFyYW0+DQogICAgPiAgICAgID4gICAgICAgICAgICAg
IDwvdG5zOmNvbnRhY3Q+DQogICAgPiAgICAgID4gICAgICAgICAgICAgIDx0bnM6Y29udGFjdCBl
dmVudD0icmVnaXN0ZXJlZCIgaWQ9IjIzNDU2Nzg5MDEiIGR1cmF0aW9uLXJlZ2lzdGVyZWQ9IjQy
OTQ5NjcyOTUiDQogICAgPiAgICAgID4gICAgICAgICAgICAgICAgICAgY3NlcT0iNDI5NDk2NzI5
NSIgcmV0cnktYWZ0ZXI9IjQyOTQ5NjcyOTUiIHE9IjAiIHN0YXRlPSJhY3RpdmUiDQogICAgPiAg
ICAgID4gICAgICAgICAgICAgICAgICAgY2FsbGlkPSJTdHJpbmciIGV4cGlyZXM9IjQyOTQ5Njcy
OTUiPg0KICAgID4gICAgICA+ICAgICAgICAgICAgICAgIDx0bnM6dXJpPnNpcDorMTU1NTY2Njc3
NzdAWzIwMDE6MGRiODo4NWEzOjAwMDA6MDAwMDo4YTJlOjAzNzA6YmJiYl08L3Ruczp1cmk+DQog
ICAgPiAgICAgID4gICAgICAgICAgICAgICAgPHRuczpkaXNwbGF5LW5hbWUgeG1sOmxhbmc9ImVu
LXVzIj5TdHJpbmc8L3RuczpkaXNwbGF5LW5hbWU+DQogICAgPiAgICAgID4gICAgICAgICAgICAg
ICAgPHRuczp1bmtub3duLXBhcmFtIG5hbWU9IlN0cmluZyI+U3RyaW5nPC90bnM6dW5rbm93bi1w
YXJhbT4NCiAgICA+ICAgICAgPiAgICAgICAgICAgICAgPC90bnM6Y29udGFjdD4NCiAgICA+ICAg
ICAgPiAgICAgICAgICAgICAgPHRuczpjb250YWN0IGV2ZW50PSJyZWdpc3RlcmVkIiBpZD0iMjM0
NTY3ODkwMSIgZHVyYXRpb24tcmVnaXN0ZXJlZD0iNDI5NDk2NzI5NSINCiAgICA+ICAgICAgPiAg
ICAgICAgICAgICAgICAgICBjc2VxPSI0Mjk0OTY3Mjk1IiByZXRyeS1hZnRlcj0iNDI5NDk2NzI5
NSIgcT0iMCIgc3RhdGU9ImFjdGl2ZSINCiAgICA+ICAgICAgPiAgICAgICAgICAgICAgICAgICBj
YWxsaWQ9IlN0cmluZyIgZXhwaXJlcz0iNDI5NDk2NzI5NSI+DQogICAgPiAgICAgID4gICAgICAg
ICAgICAgICAgPHRuczp1cmk+c2lwOisxNTU1NjY2Nzc3N0BbMjAwMTowZGI4Ojg1YTM6MDAwMDow
MDAwOjhhMmU6MDM3MDpjY2NjXTwvdG5zOnVyaT4NCiAgICA+ICAgICAgPiAgICAgICAgICAgICAg
ICA8dG5zOmRpc3BsYXktbmFtZSB4bWw6bGFuZz0iZW4tdXMiPlN0cmluZzwvdG5zOmRpc3BsYXkt
bmFtZT4NCiAgICA+ICAgICAgPiAgICAgICAgICAgICAgICA8dG5zOnVua25vd24tcGFyYW0gbmFt
ZT0iU3RyaW5nIj5TdHJpbmc8L3Ruczp1bmtub3duLXBhcmFtPg0KICAgID4gICAgICA+ICAgICAg
ICAgICAgICA8L3Ruczpjb250YWN0Pg0KICAgID4gICAgICA+ICAgICAgICAgIDwvdG5zOnJlZ2lz
dHJhdGlvbj4NCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+ICAgICAgICAgIDx0bnM6cmVnaXN0
cmF0aW9uIGlkPSIxMjM0NTY3ODkwIiBhb3I9InRlbDorMTU1NTY2Njc3NzciPg0KICAgID4gICAg
ICA+ICAgICAgICAgICAgICA8dG5zOmNvbnRhY3QgZXZlbnQ9InJlZ2lzdGVyZWQiIGlkPSIyMzQ1
Njc4OTAxIiBkdXJhdGlvbi1yZWdpc3RlcmVkPSI0Mjk0OTY3Mjk1Ig0KICAgID4gICAgICA+ICAg
ICAgICAgICAgICAgICAgIGNzZXE9IjQyOTQ5NjcyOTUiIHJldHJ5LWFmdGVyPSI0Mjk0OTY3Mjk1
IiBxPSIwIiBzdGF0ZT0iYWN0aXZlIg0KICAgID4gICAgICA+ICAgICAgICAgICAgICAgICAgIGNh
bGxpZD0iU3RyaW5nIiBleHBpcmVzPSI0Mjk0OTY3Mjk1Ij4NCiAgICA+ICAgICAgPiAgICAgICAg
ICAgICAgICA8dG5zOnVyaT5zaXA6KzE1NTU2NjY3Nzc3QFsyMDAxOjBkYjg6ODVhMzowMDAwOjAw
MDA6OGEyZTowMzcwOmFhYWFdPC90bnM6dXJpPg0KICAgID4gICAgICA+ICAgICAgICAgICAgICAg
IDx0bnM6ZGlzcGxheS1uYW1lIHhtbDpsYW5nPSJlbi11cyI+U3RyaW5nPC90bnM6ZGlzcGxheS1u
YW1lPg0KICAgID4gICAgICA+ICAgICAgICAgICAgICAgIDx0bnM6dW5rbm93bi1wYXJhbSBuYW1l
PSJTdHJpbmciPlN0cmluZzwvdG5zOnVua25vd24tcGFyYW0+DQogICAgPiAgICAgID4gICAgICAg
ICAgICAgIDwvdG5zOmNvbnRhY3Q+DQogICAgPiAgICAgID4gICAgICAgICAgICAgIDx0bnM6Y29u
dGFjdCBldmVudD0icmVnaXN0ZXJlZCIgaWQ9IjIzNDU2Nzg5MDEiIGR1cmF0aW9uLXJlZ2lzdGVy
ZWQ9IjQyOTQ5NjcyOTUiDQogICAgPiAgICAgID4gICAgICAgICAgICAgICAgICAgY3NlcT0iNDI5
NDk2NzI5NSIgcmV0cnktYWZ0ZXI9IjQyOTQ5NjcyOTUiIHE9IjAiIHN0YXRlPSJhY3RpdmUiDQog
ICAgPiAgICAgID4gICAgICAgICAgICAgICAgICAgY2FsbGlkPSJTdHJpbmciIGV4cGlyZXM9IjQy
OTQ5NjcyOTUiPg0KICAgID4gICAgICA+ICAgICAgICAgICAgICAgIDx0bnM6dXJpPnNpcDorMTU1
NTY2Njc3NzdAWzIwMDE6MGRiODo4NWEzOjAwMDA6MDAwMDo4YTJlOjAzNzA6YmJiYl08L3Ruczp1
cmk+DQogICAgPiAgICAgID4gICAgICAgICAgICAgICAgPHRuczpkaXNwbGF5LW5hbWUgeG1sOmxh
bmc9ImVuLXVzIj5TdHJpbmc8L3RuczpkaXNwbGF5LW5hbWU+DQogICAgPiAgICAgID4gICAgICAg
ICAgICAgICAgPHRuczp1bmtub3duLXBhcmFtIG5hbWU9IlN0cmluZyI+U3RyaW5nPC90bnM6dW5r
bm93bi1wYXJhbT4NCiAgICA+ICAgICAgPiAgICAgICAgICAgICAgPC90bnM6Y29udGFjdD4NCiAg
ICA+ICAgICAgPiAgICAgICAgICAgICAgPHRuczpjb250YWN0IGV2ZW50PSJyZWdpc3RlcmVkIiBp
ZD0iMjM0NTY3ODkwMSIgZHVyYXRpb24tcmVnaXN0ZXJlZD0iNDI5NDk2NzI5NSINCiAgICA+ICAg
ICAgPiAgICAgICAgICAgICAgICAgICBjc2VxPSI0Mjk0OTY3Mjk1IiByZXRyeS1hZnRlcj0iNDI5
NDk2NzI5NSIgcT0iMCIgc3RhdGU9ImFjdGl2ZSINCiAgICA+ICAgICAgPiAgICAgICAgICAgICAg
ICAgICBjYWxsaWQ9IlN0cmluZyIgZXhwaXJlcz0iNDI5NDk2NzI5NSI+DQogICAgPiAgICAgID4g
ICAgICAgICAgICAgICAgPHRuczp1cmk+c2lwOisxNTU1NjY2Nzc3N0BbMjAwMTowZGI4Ojg1YTM6
MDAwMDowMDAwOjhhMmU6MDM3MDpjY2NjXTwvdG5zOnVyaT4NCiAgICA+ICAgICAgPiAgICAgICAg
ICAgICAgICA8dG5zOmRpc3BsYXktbmFtZSB4bWw6bGFuZz0iZW4tdXMiPlN0cmluZzwvdG5zOmRp
c3BsYXktbmFtZT4NCiAgICA+ICAgICAgPiAgICAgICAgICAgICAgICA8dG5zOnVua25vd24tcGFy
YW0gbmFtZT0iU3RyaW5nIj5TdHJpbmc8L3Ruczp1bmtub3duLXBhcmFtPg0KICAgID4gICAgICA+
ICAgICAgICAgICAgICA8L3Ruczpjb250YWN0Pg0KICAgID4gICAgICA+ICAgICAgICAgIDwvdG5z
OnJlZ2lzdHJhdGlvbj4NCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+ICAgICAgICAgIDx0bnM6
cmVnaXN0cmF0aW9uIGlkPSIxMjM0NTY3ODkwIiBhb3I9InNpcDptYWlsdG86KzE2NjY3Nzc4ODg4
QGltcy5tbmMwMDEubWNjMDAxLjNncHBuZXR3b3Jrcy5vcmciPg0KICAgID4gICAgICA+ICAgICAg
ICAgICAgICA8dG5zOmNvbnRhY3QgZXZlbnQ9InJlZ2lzdGVyZWQiIGlkPSIyMzQ1Njc4OTAxIiBk
dXJhdGlvbi1yZWdpc3RlcmVkPSI0Mjk0OTY3Mjk1Ig0KICAgID4gICAgICA+ICAgICAgICAgICAg
ICAgICAgIGNzZXE9IjQyOTQ5NjcyOTUiIHJldHJ5LWFmdGVyPSI0Mjk0OTY3Mjk1IiBxPSIwIiBz
dGF0ZT0iYWN0aXZlIg0KICAgID4gICAgICA+ICAgICAgICAgICAgICAgICAgIGNhbGxpZD0iU3Ry
aW5nIiBleHBpcmVzPSI0Mjk0OTY3Mjk1Ij4NCiAgICA+ICAgICAgPiAgICAgICAgICAgICAgICA8
dG5zOnVyaT5zaXA6KzE1NTU2NjY3Nzc3QFsyMDAxOjBkYjg6ODVhMzowMDAwOjAwMDA6OGEyZTow
MzcwOmFhYWFdPC90bnM6dXJpPg0KICAgID4gICAgICA+ICAgICAgICAgICAgICAgIDx0bnM6ZGlz
cGxheS1uYW1lIHhtbDpsYW5nPSJlbi11cyI+U3RyaW5nPC90bnM6ZGlzcGxheS1uYW1lPg0KICAg
ID4gICAgICA+ICAgICAgICAgICAgICAgIDx0bnM6dW5rbm93bi1wYXJhbSBuYW1lPSJTdHJpbmci
PlN0cmluZzwvdG5zOnVua25vd24tcGFyYW0+DQogICAgPiAgICAgID4gICAgICAgICAgICAgIDwv
dG5zOmNvbnRhY3Q+DQogICAgPiAgICAgID4gICAgICAgICAgICAgIDx0bnM6Y29udGFjdCBldmVu
dD0icmVnaXN0ZXJlZCIgaWQ9IjIzNDU2Nzg5MDEiIGR1cmF0aW9uLXJlZ2lzdGVyZWQ9IjQyOTQ5
NjcyOTUiDQogICAgPiAgICAgID4gICAgICAgICAgICAgICAgICAgY3NlcT0iNDI5NDk2NzI5NSIg
cmV0cnktYWZ0ZXI9IjQyOTQ5NjcyOTUiIHE9IjAiIHN0YXRlPSJhY3RpdmUiDQogICAgPiAgICAg
ID4gICAgICAgICAgICAgICAgICAgY2FsbGlkPSJTdHJpbmciIGV4cGlyZXM9IjQyOTQ5NjcyOTUi
Pg0KICAgID4gICAgICA+ICAgICAgICAgICAgICAgIDx0bnM6dXJpPnNpcDorMTU1NTY2Njc3NzdA
WzIwMDE6MGRiODo4NWEzOjAwMDA6MDAwMDo4YTJlOjAzNzA6YmJiYl08L3Ruczp1cmk+DQogICAg
PiAgICAgID4gICAgICAgICAgICAgICAgPHRuczpkaXNwbGF5LW5hbWUgeG1sOmxhbmc9ImVuLXVz
Ij5TdHJpbmc8L3RuczpkaXNwbGF5LW5hbWU+DQogICAgPiAgICAgID4gICAgICAgICAgICAgICAg
PHRuczp1bmtub3duLXBhcmFtIG5hbWU9IlN0cmluZyI+U3RyaW5nPC90bnM6dW5rbm93bi1wYXJh
bT4NCiAgICA+ICAgICAgPiAgICAgICAgICAgICAgPC90bnM6Y29udGFjdD4NCiAgICA+ICAgICAg
PiAgICAgICAgICAgICAgPHRuczpjb250YWN0IGV2ZW50PSJyZWdpc3RlcmVkIiBpZD0iMjM0NTY3
ODkwMSIgZHVyYXRpb24tcmVnaXN0ZXJlZD0iNDI5NDk2NzI5NSINCiAgICA+ICAgICAgPiAgICAg
ICAgICAgICAgICAgICBjc2VxPSI0Mjk0OTY3Mjk1IiByZXRyeS1hZnRlcj0iNDI5NDk2NzI5NSIg
cT0iMCIgc3RhdGU9ImFjdGl2ZSINCiAgICA+ICAgICAgPiAgICAgICAgICAgICAgICAgICBjYWxs
aWQ9IlN0cmluZyIgZXhwaXJlcz0iNDI5NDk2NzI5NSI+DQogICAgPiAgICAgID4gICAgICAgICAg
ICAgICAgPHRuczp1cmk+c2lwOisxNTU1NjY2Nzc3N0BbMjAwMTowZGI4Ojg1YTM6MDAwMDowMDAw
OjhhMmU6MDM3MDpjY2NjXTwvdG5zOnVyaT4NCiAgICA+ICAgICAgPiAgICAgICAgICAgICAgICA8
dG5zOmRpc3BsYXktbmFtZSB4bWw6bGFuZz0iZW4tdXMiPlN0cmluZzwvdG5zOmRpc3BsYXktbmFt
ZT4NCiAgICA+ICAgICAgPiAgICAgICAgICAgICAgICA8dG5zOnVua25vd24tcGFyYW0gbmFtZT0i
U3RyaW5nIj5TdHJpbmc8L3Ruczp1bmtub3duLXBhcmFtPg0KICAgID4gICAgICA+ICAgICAgICAg
ICAgICA8L3Ruczpjb250YWN0Pg0KICAgID4gICAgICA+ICAgICAgICAgIDwvdG5zOnJlZ2lzdHJh
dGlvbj4NCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+ICAgICAgICAgIDx0bnM6cmVnaXN0cmF0
aW9uIGlkPSIxMjM0NTY3ODkwIiBhb3I9InRlbDorMTU1NTY2Njc3NzciPg0KICAgID4gICAgICA+
ICAgICAgICAgICAgICA8dG5zOmNvbnRhY3QgZXZlbnQ9InJlZ2lzdGVyZWQiIGlkPSIyMzQ1Njc4
OTAxIiBkdXJhdGlvbi1yZWdpc3RlcmVkPSI0Mjk0OTY3Mjk1Ig0KICAgID4gICAgICA+ICAgICAg
ICAgICAgICAgICAgIGNzZXE9IjQyOTQ5NjcyOTUiIHJldHJ5LWFmdGVyPSI0Mjk0OTY3Mjk1IiBx
PSIwIiBzdGF0ZT0iYWN0aXZlIg0KICAgID4gICAgICA+ICAgICAgICAgICAgICAgICAgIGNhbGxp
ZD0iU3RyaW5nIiBleHBpcmVzPSI0Mjk0OTY3Mjk1Ij4NCiAgICA+ICAgICAgPiAgICAgICAgICAg
ICAgICA8dG5zOnVyaT5zaXA6KzE1NTU2NjY3Nzc3QFsyMDAxOjBkYjg6ODVhMzowMDAwOjAwMDA6
OGEyZTowMzcwOmFhYWFdPC90bnM6dXJpPg0KICAgID4gICAgICA+ICAgICAgICAgICAgICAgIDx0
bnM6ZGlzcGxheS1uYW1lIHhtbDpsYW5nPSJlbi11cyI+U3RyaW5nPC90bnM6ZGlzcGxheS1uYW1l
Pg0KICAgID4gICAgICA+ICAgICAgICAgICAgICAgIDx0bnM6dW5rbm93bi1wYXJhbSBuYW1lPSJT
dHJpbmciPlN0cmluZzwvdG5zOnVua25vd24tcGFyYW0+DQogICAgPiAgICAgID4gICAgICAgICAg
ICAgIDwvdG5zOmNvbnRhY3Q+DQogICAgPiAgICAgID4gICAgICAgICAgICAgIDx0bnM6Y29udGFj
dCBldmVudD0icmVnaXN0ZXJlZCIgaWQ9IjIzNDU2Nzg5MDEiIGR1cmF0aW9uLXJlZ2lzdGVyZWQ9
IjQyOTQ5NjcyOTUiDQogICAgPiAgICAgID4gICAgICAgICAgICAgICAgICAgY3NlcT0iNDI5NDk2
NzI5NSIgcmV0cnktYWZ0ZXI9IjQyOTQ5NjcyOTUiIHE9IjAiIHN0YXRlPSJhY3RpdmUiDQogICAg
PiAgICAgID4gICAgICAgICAgICAgICAgICAgY2FsbGlkPSJTdHJpbmciIGV4cGlyZXM9IjQyOTQ5
NjcyOTUiPg0KICAgID4gICAgICA+ICAgICAgICAgICAgICAgIDx0bnM6dXJpPnNpcDorMTU1NTY2
Njc3NzdAWzIwMDE6MGRiODo4NWEzOjAwMDA6MDAwMDo4YTJlOjAzNzA6YmJiYl08L3Ruczp1cmk+
DQogICAgPiAgICAgID4gICAgICAgICAgICAgICAgPHRuczpkaXNwbGF5LW5hbWUgeG1sOmxhbmc9
ImVuLXVzIj5TdHJpbmc8L3RuczpkaXNwbGF5LW5hbWU+DQogICAgPiAgICAgID4gICAgICAgICAg
ICAgICAgPHRuczp1bmtub3duLXBhcmFtIG5hbWU9IlN0cmluZyI+U3RyaW5nPC90bnM6dW5rbm93
bi1wYXJhbT4NCiAgICA+ICAgICAgPiAgICAgICAgICAgICAgPC90bnM6Y29udGFjdD4NCiAgICA+
ICAgICAgPiAgICAgICAgICAgICAgPHRuczpjb250YWN0IGV2ZW50PSJyZWdpc3RlcmVkIiBpZD0i
MjM0NTY3ODkwMSIgZHVyYXRpb24tcmVnaXN0ZXJlZD0iNDI5NDk2NzI5NSINCiAgICA+ICAgICAg
PiAgICAgICAgICAgICAgICAgICBjc2VxPSI0Mjk0OTY3Mjk1IiByZXRyeS1hZnRlcj0iNDI5NDk2
NzI5NSIgcT0iMCIgc3RhdGU9ImFjdGl2ZSINCiAgICA+ICAgICAgPiAgICAgICAgICAgICAgICAg
ICBjYWxsaWQ9IlN0cmluZyIgZXhwaXJlcz0iNDI5NDk2NzI5NSI+DQogICAgPiAgICAgID4gICAg
ICAgICAgICAgICAgPHRuczp1cmk+c2lwOisxNTU1NjY2Nzc3N0BbMjAwMTowZGI4Ojg1YTM6MDAw
MDowMDAwOjhhMmU6MDM3MDpjY2NjXTwvdG5zOnVyaT4NCiAgICA+ICAgICAgPiAgICAgICAgICAg
ICAgICA8dG5zOmRpc3BsYXktbmFtZSB4bWw6bGFuZz0iZW4tdXMiPlN0cmluZzwvdG5zOmRpc3Bs
YXktbmFtZT4NCiAgICA+ICAgICAgPiAgICAgICAgICAgICAgICA8dG5zOnVua25vd24tcGFyYW0g
bmFtZT0iU3RyaW5nIj5TdHJpbmc8L3Ruczp1bmtub3duLXBhcmFtPg0KICAgID4gICAgICA+ICAg
ICAgICAgICAgICA8L3Ruczpjb250YWN0Pg0KICAgID4gICAgICA+ICAgICAgICAgIDwvdG5zOnJl
Z2lzdHJhdGlvbj4NCiAgICA+ICAgICAgPiAgICAgICAgICA8L3RuczpyZWdpbmZvPg0KICAgID4g
ICAgICA+DQogICAgPiAgICAgID4gICAgICAgICAgSWYgdGhlIG51bWJlciBvZiBwaG9uZSBudW1i
ZXJzIGFuZC9vciBkZXZpY2VzIGluY3JlYXNlLCB0aGUgcGF5bG9hZCBzaXplIHdpbGwgZ3JvdyBy
YXRoZXIgcmFwaWRseS4NCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+ICAgICAgICAgIE9uZSBj
YW4gb2YgY291cnNlIGUuZy4sIHVzZSBtZXNzYWdlIGNvbXByZXNzaW9uIHRvIHJlZHVjZSB0aGUg
c2l6ZSBvZiB0aGUgcGF5bG9hZCwgYnV0IGluIG15IG9waW5pb24gdGhlIHJlYWwgcHJvYmxlbSBp
cyB0aGUgZmFjdCB0aGF0IGluZm9ybWF0aW9uIGlzIGR1cGxpY2F0ZWQuDQogICAgPiAgICAgID4N
CiAgICA+ICAgICAgPiAgICAgICAgICBXaGVuIGRpc2N1c3NpbmcgdGhpcyB3aXRoIHNvbWUgY29s
bGVhZ3Vlcywgb25lIGlkZWEgdGhhdCBjYW1lIHVwIHdhcyB0byB1c2UgcmVmZXJlbmNlczogc2Vw
YXJhdGUgdGhlICdjb250YWN0IGVsZW1lbnRzJyBmcm9tIHRoZSAncmVnaXN0cmF0aW9uIGVsZW1l
bnRzJywgYW5kIHRoZW4gc2ltcGx5IHJlZmVyZW5jZSB0aGUgJ2NvbnRhY3QgZWxlbWVudHMnIGZy
b20gd2l0aGluIHRoZSAncmVnaXN0cmF0aW9uIGVsZW1lbnRzJy4NCiAgICA+ICAgICAgPg0KICAg
ID4gICAgICA+ICAgICAgICAgIEEgc2ltcGxpZmllZCBleGFtcGxlIHdvdWxkIGxvb2sgc29tZXRo
aW5nIGxpa2UgKG5vdGUgdGhlIG5ldyBhbmNob3IgYW5kIHRhcmdldCBhdHRyaWJ1dGVzKToNCiAg
ICA+ICAgICAgPg0KICAgID4gICAgICA+ICAgICAgICAgIDxjb250YWN0PiA8dXJpPklQLUFkZHJl
c3MxIGFuY2hvcj0iMSI8L3VyaT48L2NvbnRhY3Q+DQogICAgPiAgICAgID4gICAgICAgICAgPGNv
bnRhY3Q+IDx1cmk+SVAtQWRkcmVzczIgYW5jaG9yPSIyIjwvdXJpPjwvY29udGFjdD4NCiAgICA+
ICAgICAgPiAgICAgICAgICA8Y29udGFjdD4gPHVyaT5JUC1BZGRyZXNzMyBhbmNob3I9IjMiPC91
cmk+PC9jb250YWN0Pg0KICAgID4gICAgICA+ICAgICAgICAgIDxyZWdpc3RyYXRpb24gYW9yPXNp
cDpwaG9uZV9udW1iZXIxL1NJUCBpZD0iMSIgc3RhdGU9ImFjdGl2ZSI+DQogICAgPiAgICAgID4g
ICAgICAgICAgCTxjb250YWN0LXJlZiB0YXJnZXQ9IjEiIC8+DQogICAgPiAgICAgID4gICAgICAg
ICAgCTxjb250YWN0LXJlZiB0YXJnZXQ9IjIiIC8+DQogICAgPiAgICAgID4gICAgICAgICAgCTxj
b250YWN0LXJlZiB0YXJnZXQ9IjMiIC8+DQogICAgPiAgICAgID4gICAgICAgICAgPHJlZ2lzdHJh
dGlvbiBhb3I9dGVsOnBob25lX251bWJlcjEvVEVMIGlkPSIyIiBzdGF0ZT0iYWN0aXZlIj4NCiAg
ICA+ICAgICAgPiAgICAgICAgICAJPGNvbnRhY3QtcmVmIHRhcmdldD0iMSIgLz4NCiAgICA+ICAg
ICAgPiAgICAgICAgICAJPGNvbnRhY3QtcmVmIHRhcmdldD0iMiIgLz4NCiAgICA+ICAgICAgPiAg
ICAgICAgICAJPGNvbnRhY3QtcmVmIHRhcmdldD0iMyIgLz4NCiAgICA+ICAgICAgPiAgICAgICAg
ICA8cmVnaXN0cmF0aW9uIGFvcj1zaXA6cGhvbmVfbnVtYmVyMi9TSVAgaWQ9IjEiIHN0YXRlPSJh
Y3RpdmUiPg0KICAgID4gICAgICA+ICAgICAgICAgIAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIxIiAv
Pg0KICAgID4gICAgICA+ICAgICAgICAgIAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIyIiAvPg0KICAg
ID4gICAgICA+ICAgICAgICAgIAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIzIiAvPg0KICAgID4gICAg
ICA+ICAgICAgICAgIDxyZWdpc3RyYXRpb24gYW9yPXRlbDpwaG9uZV9udW1iZXIyL1RFTCBpZD0i
MiIgc3RhdGU9ImFjdGl2ZSI+DQogICAgPiAgICAgID4gICAgICAgICAgCTxjb250YWN0LXJlZiB0
YXJnZXQ9IjEiIC8+DQogICAgPiAgICAgID4gICAgICAgICAgCTxjb250YWN0LXJlZiB0YXJnZXQ9
IjIiIC8+DQogICAgPiAgICAgID4gICAgICAgICAgCTxjb250YWN0LXJlZiB0YXJnZXQ9IjMiIC8+
DQogICAgPiAgICAgID4NCiAgICA+ICAgICAgPiAgICAgICAgICBJZiB5b3UgYXBwbHkgdGhpcyBv
biB0aGUgZXhhbXBsZSBiYXNlZCBvbiB0aGUgWE1MIHNjaGVtYSBpbiBSRkMgMzY4MCB5b3Ugd2ls
bCBzZWUgYSBzaWduaWZpY2FudCByZWR1Y3Rpb24gaW4gc2l6ZToNCiAgICA+ICAgICAgPg0KICAg
ID4gICAgICA+ICAgICAgICAgIDw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+
DQogICAgPiAgICAgID4gICAgICAgICAgPCEtLVNhbXBsZSBYTUwgZmlsZSBnZW5lcmF0ZWQgYnkg
WE1MU3B5IHYyMDA4IChodHRwOi8vd3d3LmFsdG92YS5jb20pLS0+DQogICAgPiAgICAgID4gICAg
ICAgICAgPHRuczpyZWdpbmZvIHN0YXRlPSJmdWxsIiB2ZXJzaW9uPSIwIiB4c2k6c2NoZW1hTG9j
YXRpb249InVybjppZXRmOnBhcmFtczp4bWw6bnM6cmVnaW5mbyBVbnRpdGxlZDEueHNkIiB4bWxu
czp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp0
bnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6cmVnaW5mbyI+DQogICAgPiAgICAgID4NCiAgICA+
ICAgICAgPiAgICAgICAgICA8dG5zOmNvbnRhY3QgZXZlbnQ9InJlZ2lzdGVyZWQiIGFuY2hvcj0i
MSIgaWQ9IjIzNDU2Nzg5MDEiIGR1cmF0aW9uLXJlZ2lzdGVyZWQ9IjQyOTQ5NjcyOTUiDQogICAg
PiAgICAgID4gICAgICAgICAgICAgICAgICAgY3NlcT0iNDI5NDk2NzI5NSIgcmV0cnktYWZ0ZXI9
IjQyOTQ5NjcyOTUiIHE9IjAiIHN0YXRlPSJhY3RpdmUiDQogICAgPiAgICAgID4gICAgICAgICAg
ICAgICAgICAgY2FsbGlkPSJTdHJpbmciIGV4cGlyZXM9IjQyOTQ5NjcyOTUiPg0KICAgID4gICAg
ICA+ICAgICAgICAgICAgICAgIDx0bnM6dXJpPnNpcDorMTU1NTY2Njc3NzdAWzIwMDE6MGRiODo4
NWEzOjAwMDA6MDAwMDo4YTJlOjAzNzA6YWFhYV08L3Ruczp1cmk+DQogICAgPiAgICAgID4gICAg
ICAgICAgICAgICAgPHRuczpkaXNwbGF5LW5hbWUgeG1sOmxhbmc9ImVuLXVzIj5TdHJpbmc8L3Ru
czpkaXNwbGF5LW5hbWU+DQogICAgPiAgICAgID4gICAgICAgICAgICAgICAgPHRuczp1bmtub3du
LXBhcmFtIG5hbWU9IlN0cmluZyI+U3RyaW5nPC90bnM6dW5rbm93bi1wYXJhbT4NCiAgICA+ICAg
ICAgPiAgICAgICAgICA8L3Ruczpjb250YWN0Pg0KICAgID4gICAgICA+ICAgICAgICAgIDx0bnM6
Y29udGFjdCBldmVudD0icmVnaXN0ZXJlZCIgYW5jaG9yPSIyIiBpZD0iMjM0NTY3ODkwMSIgZHVy
YXRpb24tcmVnaXN0ZXJlZD0iNDI5NDk2NzI5NSINCiAgICA+ICAgICAgPiAgICAgICAgICAgICAg
ICAgICBjc2VxPSI0Mjk0OTY3Mjk1IiByZXRyeS1hZnRlcj0iNDI5NDk2NzI5NSIgcT0iMCIgc3Rh
dGU9ImFjdGl2ZSINCiAgICA+ICAgICAgPiAgICAgICAgICAgICAgICAgICBjYWxsaWQ9IlN0cmlu
ZyIgZXhwaXJlcz0iNDI5NDk2NzI5NSI+DQogICAgPiAgICAgID4gICAgICAgICAgICAgICAgPHRu
czp1cmk+c2lwOisxNTU1NjY2Nzc3N0BbMjAwMTowZGI4Ojg1YTM6MDAwMDowMDAwOjhhMmU6MDM3
MDpiYmJiXTwvdG5zOnVyaT4NCiAgICA+ICAgICAgPiAgICAgICAgICAgICAgICA8dG5zOmRpc3Bs
YXktbmFtZSB4bWw6bGFuZz0iZW4tdXMiPlN0cmluZzwvdG5zOmRpc3BsYXktbmFtZT4NCiAgICA+
ICAgICAgPiAgICAgICAgICAgICAgICA8dG5zOnVua25vd24tcGFyYW0gbmFtZT0iU3RyaW5nIj5T
dHJpbmc8L3Ruczp1bmtub3duLXBhcmFtPg0KICAgID4gICAgICA+ICAgICAgICAgIDwvdG5zOmNv
bnRhY3Q+DQogICAgPiAgICAgID4gICAgICAgICAgPHRuczpjb250YWN0IGV2ZW50PSJyZWdpc3Rl
cmVkIiBhbmNob3I9IjMiIGlkPSIyMzQ1Njc4OTAxIiBkdXJhdGlvbi1yZWdpc3RlcmVkPSI0Mjk0
OTY3Mjk1Ig0KICAgID4gICAgICA+ICAgICAgICAgICAgICAgICAgIGNzZXE9IjQyOTQ5NjcyOTUi
IHJldHJ5LWFmdGVyPSI0Mjk0OTY3Mjk1IiBxPSIwIiBzdGF0ZT0iYWN0aXZlIg0KICAgID4gICAg
ICA+ICAgICAgICAgICAgICAgICAgIGNhbGxpZD0iU3RyaW5nIiBleHBpcmVzPSI0Mjk0OTY3Mjk1
Ij4NCiAgICA+ICAgICAgPiAgICAgICAgICAgICAgICA8dG5zOnVyaT5zaXA6KzE1NTU2NjY3Nzc3
QFsyMDAxOjBkYjg6ODVhMzowMDAwOjAwMDA6OGEyZTowMzcwOmNjY2NdPC90bnM6dXJpPg0KICAg
ID4gICAgICA+ICAgICAgICAgICAgICAgIDx0bnM6ZGlzcGxheS1uYW1lIHhtbDpsYW5nPSJlbi11
cyI+U3RyaW5nPC90bnM6ZGlzcGxheS1uYW1lPg0KICAgID4gICAgICA+ICAgICAgICAgICAgICAg
IDx0bnM6dW5rbm93bi1wYXJhbSBuYW1lPSJTdHJpbmciPlN0cmluZzwvdG5zOnVua25vd24tcGFy
YW0+DQogICAgPiAgICAgID4gICAgICAgICAgPC90bnM6Y29udGFjdD4NCiAgICA+ICAgICAgPg0K
ICAgID4gICAgICA+ICAgICAgICAgIDx0bnM6cmVnaXN0cmF0aW9uIGlkPSIxMjM0NTY3ODkwIiBh
b3I9InNpcDptYWlsdG86KzE1NTU2NjY3Nzc3QGltcy5tbmMwMDEubWNjMDAxLjNncHBuZXR3b3Jr
cy5vcmciPg0KICAgID4gICAgICA+ICAgICAgICAgIAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIxIiAv
Pg0KICAgID4gICAgICA+ICAgICAgICAgIAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIyIiAvPg0KICAg
ID4gICAgICA+ICAgICAgICAgIAk8Y29udGFjdC1yZWYgdGFyZ2V0PSIzIiAvPg0KICAgID4gICAg
ICA+ICAgICAgICAgIDwvdG5zOnJlZ2lzdHJhdGlvbj4NCiAgICA+ICAgICAgPiAgICAgICAgICA8
dG5zOnJlZ2lzdHJhdGlvbiBpZD0iMTIzNDU2Nzg5MCIgYW9yPSJ0ZWw6KzE1NTU2NjY3Nzc3Ij4N
CiAgICA+ICAgICAgPiAgICAgICAgICAJPGNvbnRhY3QtcmVmIHRhcmdldD0iMSIgLz4NCiAgICA+
ICAgICAgPiAgICAgICAgICAJPGNvbnRhY3QtcmVmIHRhcmdldD0iMiIgLz4NCiAgICA+ICAgICAg
PiAgICAgICAgICAJPGNvbnRhY3QtcmVmIHRhcmdldD0iMyIgLz4NCiAgICA+ICAgICAgPiAgICAg
ICAgICA8L3RuczpyZWdpc3RyYXRpb24+DQogICAgPiAgICAgID4gICAgICAgICAgPHRuczpyZWdp
c3RyYXRpb24gaWQ9IjEyMzQ1Njc4OTAiIGFvcj0ic2lwOm1haWx0bzorMTY2Njc3Nzg4ODhAaW1z
Lm1uYzAwMS5tY2MwMDEuM2dwcG5ldHdvcmtzLm9yZyI+DQogICAgPiAgICAgID4gICAgICAgICAg
CTxjb250YWN0LXJlZiB0YXJnZXQ9IjEiIC8+DQogICAgPiAgICAgID4gICAgICAgICAgCTxjb250
YWN0LXJlZiB0YXJnZXQ9IjIiIC8+DQogICAgPiAgICAgID4gICAgICAgICAgCTxjb250YWN0LXJl
ZiB0YXJnZXQ9IjMiIC8+DQogICAgPiAgICAgID4gICAgICAgICAgPC90bnM6cmVnaXN0cmF0aW9u
Pg0KICAgID4gICAgICA+ICAgICAgICAgIDx0bnM6cmVnaXN0cmF0aW9uIGlkPSIxMjM0NTY3ODkw
IiBhb3I9InRlbDorMTU1NTY2Njc3NzciPg0KICAgID4gICAgICA+ICAgICAgICAgIAk8Y29udGFj
dC1yZWYgdGFyZ2V0PSIxIiAvPg0KICAgID4gICAgICA+ICAgICAgICAgIAk8Y29udGFjdC1yZWYg
dGFyZ2V0PSIyIiAvPg0KICAgID4gICAgICA+ICAgICAgICAgIAk8Y29udGFjdC1yZWYgdGFyZ2V0
PSIzIiAvPg0KICAgID4gICAgICA+ICAgICAgICAgIDwvdG5zOnJlZ2lzdHJhdGlvbj4NCiAgICA+
ICAgICAgPiAgICAgICAgICA8L3RuczpyZWdpbmZvPg0KICAgID4gICAgICA+DQogICAgPiAgICAg
ID4NCiAgICA+ICAgICAgPiAgICAgICAgIEFzIGZhciBhcyBzdGFuZGFyZGl6YXRpb24gaXMgY29u
Y2VybmVkLCBJIGd1ZXNzIHRoaXMgY291bGQgYmUgZG9uZSBhcyBhbiBSRkMgMzY4MCB1cGRhdGUs
IGJ5IGVpdGhlciBkZWZpbmluZyBhbiBhZGRpdGlvbmFsIHJlZy1ldmVudCBwYWNrYWdlIHdpdGgg
YSBuZXcgWE1MIHNjaGVtYSwgT1IgZGVmaW5pbmcgYW4gYWRkaXRpb25hbCBYTUwgc2NoZW1hIGZv
ciB0aGUgZXhpc3RpbmcgcmVnLWV2ZW50IHBhY2thZ2UgKGlmIHRoYXQgaXMgYWxsb3dlZCkuIElu
IGVpdGhlciBjYXNlLCB0aGUgVUEgb2J2aW91c2x5IG5lZWQgdG8gYmUgYWJsZSB0byBpbmRpY2F0
ZSBzdXBwb3J0IG9mIHRoZSBuZXcgc2NoZW1hLg0KICAgID4gICAgICA+DQogICAgPiAgICAgID4g
ICAgICAgICAgQ29tbWVudHM/DQogICAgPiAgICAgID4NCiAgICA+ICAgICAgPiAgICAgICAgICBS
ZWdhcmRzLA0KICAgID4gICAgICA+DQogICAgPiAgICAgID4gICAgICAgICAgQ2hyaXN0ZXINCiAg
ICA+ICAgICAgPg0KICAgID4gICAgICA+DQogICAgPiAgICAgID4NCiAgICA+ICAgICAgPiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gICAgICA+
IHNpcGNvcmUgbWFpbGluZyBsaXN0DQogICAgPiAgICAgID4gc2lwY29yZUBpZXRmLm9yZw0KICAg
ID4gICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K
ICAgID4gICAgICA+DQogICAgPiAgICAgIA0KICAgID4gICAgICBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gICAgICBzaXBjb3JlIG1haWxpbmcg
bGlzdA0KICAgID4gICAgICBzaXBjb3JlQGlldGYub3JnDQogICAgPiAgICAgIGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KICAgID4gICAgICANCiAgICA+IA0K
ICAgIA0KICAgIA0KDQo=


From nobody Thu Mar 28 00:50:08 2019
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 749C912031F for ; Thu, 28 Mar 2019 00:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 GD1rShWnn9db for ; Thu, 28 Mar 2019 00:50:03 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150087.outbound.protection.outlook.com [40.107.15.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F52120170 for ; Thu, 28 Mar 2019 00:50:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xsCqDC7ai+ckrgBEkSp240cKa+Gu2kdwvtJMQvxTHN8=; b=Z9jjYAZVS/E6ufPZmSjZT1jIuuMqk9+Iur0QQ+cyF4r3H5Z1VjkFeqblrIs7rAbjvskXw4b/H3OP8gQW/udp718cvDu8LBCj5XQEWGFME2+o4cTVwSUqTubIgfLJP4ADK8S94733oHtfsE8Tv0edEHLQHd9D6a/hKbf2yy4m9SU=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3164.eurprd07.prod.outlook.com (10.170.245.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.15; Thu, 28 Mar 2019 07:50:00 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1750.014; Thu, 28 Mar 2019 07:50:00 +0000
From: Christer Holmberg 
To: "Dale R. Worley" 
CC: "sipcore@ietf.org" 
Thread-Topic: [sipcore] reg-event issue with multi-identity/multi-device
Thread-Index: AQHU5Qgnz/jJs73IVEGCL49ymjXIcKYgzSQA
Date: Thu, 28 Mar 2019 07:50:00 +0000
Message-ID: <9FCA42CF-01C9-4DEC-AD53-5ABE3E7D66C1@ericsson.com>
References: <97159F5B-8C69-4B89-A25F-39F95ED57027@ericsson.com> <87bm1vlqjn.fsf@hobgoblin.ariadne.com>
In-Reply-To: <87bm1vlqjn.fsf@hobgoblin.ariadne.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6a0e7940-ad3d-49b6-57b6-08d6b351fafb
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3164; 
x-ms-traffictypediagnostic: HE1PR07MB3164:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0990C54589
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(376002)(346002)(396003)(39860400002)(189003)(199004)(11346002)(6916009)(26005)(53936002)(256004)(68736007)(36756003)(2616005)(81166006)(478600001)(486006)(81156014)(5660300002)(6116002)(76176011)(71200400001)(6246003)(71190400001)(3846002)(14454004)(82746002)(446003)(83716004)(97736004)(305945005)(7736002)(4326008)(8676002)(476003)(6512007)(316002)(66066001)(86362001)(6506007)(2906002)(25786009)(99286004)(102836004)(105586002)(6346003)(44832011)(229853002)(58126008)(106356001)(186003)(33656002)(8936002)(6436002)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3164; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: NfUtpafYS0W7zbZBeZ2/DIa450T5Qvl8gcIiV3DvWoG1iBgk7kGWz1PaDjuAMKYujS3c3lWWOgJzgXgCy8CR7ry/B8NXPB9d6q+Gy70zLR0YcubZNKz77eD7WDbd3tk6JE9unaa68k1vDKVuc8QSH5Na9CWz/dGlri3BcUo0QZOyx75vqTE9iyHA3uOzxL3YSqq+pTW3Bv92+BTePp829Tqg9DSZKEYPMwk5v79NM5Q1ZhJGLDEFMaZwM9Ur9/0sX5FaSxZm+SzbeOjtswYOe2dlJonXCEmEmBuOLBqapjytbpvCQmnhA42itFjpl54m1Du41E2jpobPwvKPj+bYkLXLXPhC3CWaXid8KYzRKxWyJFWRK+vMRT3y7z+qJWQ8o4u5r9BJPQo+12NpRb+LgZTO1fE0ipY8hAvIN8+czsY=
Content-Type: text/plain; charset="utf-8"
Content-ID: <5713C7D396D77F4AAF4FB8D584732EF0@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6a0e7940-ad3d-49b6-57b6-08d6b351fafb
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2019 07:50:00.2831 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3164
Archived-At: 
Subject: Re: [sipcore] reg-event issue with multi-identity/multi-device
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Mar 2019 07:50:06 -0000

SGksDQoNCj4gICAgQ2VydGFpbmx5IHRoZSBjb21wbGFpbnQgdGhhdCB0aGUgY29udGVudCBjYW4g
YmVjb21lIGxhcmdlIGlzIHZhbGlkLCBhcw0KPiAgICBpdHMgc2l6ZSBpcyByb3VnaGx5IHRoZSBw
cm9kdWN0IG9mIHRoZSBudW1iZXIgb2YgZGV2aWNlcyBhbmQgdGhlIG51bWJlcg0KPiAgICBvZiBB
T1JzLg0KICANCkNvcnJlY3QuDQogIA0KPiAgICBCdXQgdXNpbmcgY29udGFjdCByZWZlcmVuY2Vz
IGlzIG9ubHkgZ29pbmcgdG8gaGVscCB3aGVuICJhbGwgdGhlIHN0YXJzDQo+ICAgIGxpbmUgdXAi
LiAgT25lIG9mIHRoZSBleGFtcGxlIGNvbnRhY3QtcmVnaXN0cmF0aW9ucyBpczoNCj4gICAgDQo+
ICAgICAgICA8dG5zOmNvbnRhY3QgZXZlbnQ9InJlZ2lzdGVyZWQiIGlkPSIyMzQ1Njc4OTAxIiBk
dXJhdGlvbi1yZWdpc3RlcmVkPSI0Mjk0OTY3Mjk1Ig0KPiAgICAJIGNzZXE9IjQyOTQ5NjcyOTUi
IHJldHJ5LWFmdGVyPSI0Mjk0OTY3Mjk1IiBxPSIwIiBzdGF0ZT0iYWN0aXZlIg0KPiAgICAJIGNh
bGxpZD0iU3RyaW5nIiBleHBpcmVzPSI0Mjk0OTY3Mjk1Ij4NCj4gICAgICAgICAgPHRuczp1cmk+
c2lwOisxNTU1NjY2Nzc3N0BbMjAwMTowZGI4Ojg1YTM6MDAwMDowMDAwOjhhMmU6MDM3MDphYWFh
XTwvdG5zOnVyaT4NCj4gICAgICAgICAgPHRuczpkaXNwbGF5LW5hbWUgeG1sOmxhbmc9ImVuLXVz
Ij5TdHJpbmc8L3RuczpkaXNwbGF5LW5hbWU+DQo+ICAgICAgICAgIDx0bnM6dW5rbm93bi1wYXJh
bSBuYW1lPSJTdHJpbmciPlN0cmluZzwvdG5zOnVua25vd24tcGFyYW0+DQo+ICAgICAgICA8L3Ru
czpjb250YWN0Pg0KPiAgICANCj4gICAgQW5kIHRoaXMgaXMgcmVwZWF0ZWQgdmVyYmF0aW0gZm9y
IGVhY2ggb2YgdGhlIDQgQU9Scy4NCj4gICAgDQo+ICAgIEJ1dCBpZiwgb24gZWFjaCBkZXZpY2Us
IHRoZSB1c2VyIGhhcyBhIGRpZmZlcmVudCBkaXNwbGF5LW5hbWUgZm9yIGVhY2gNCj4gICAgb2Yg
dGhlIEFPUnMgdGhhdCBjYW4gcmVhY2ggdGhlIGRldmljZSwgdGhlbiBhbGwgMTIgb2YgdGhlIDxj
b250YWN0Pg0KPiAgICBlbGVtZW50cyBoYXZlIGRpZmZlcmVudCA8ZGlzcGxheS1uYW1lPiBlbGVt
ZW50cy4gIFNvIHlvdSB3b3VsZCBuZWVkIGENCj4gICAgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIG1v
cmUgZmxleGliaWxpdHkgdGhhbiBqdXN0IHJlcGVhdGluZyBleGFjdGx5IHRoZQ0KPiAgICBzYW1l
IDxjb250YWN0PiBlbGVtZW50IGluIG11bHRpcGxlIHBsYWNlcy4NCiAgDQpUaGF0IGlzIHRydWUg
aW4gdGhlb3J5Lg0KDQpCdXQsIGF0IGxlYXN0IGJhc2VkIG9uIG1lIGV4cGVyaWVuY2UsIHRoYXQg
aXMgbm90IGEgcmVhbC1kZXBsb3ltZW50IHByb2JsZW0uDQoNCj4gICAgQ29tcGFyZTogIFRoZSB1
c2Ugb2YgIkFjY2VwdC1FbmNvZGluZzogZ3ppcCIgYW5kICJDb250ZW50LUVuY29kaW5nOg0KPiAg
ICBnemlwIiBpcyBhbHJlYWR5IHBlcm1pdHRlZCBhbmQgc3RhbmRhcmRpemVkLiAgV2UgYWxyZWFk
eSBoYXZlIGENCj4gICAgZmVhdHVyZS1uZWdvdGlhdGlvbiBwcm9jZXNzIGZvciBpdC4gIEl0J3Mg
dHJ1ZSB0aGF0IHByb2Nlc3NpbmcgcHVyZQ0KPiAgICBjb250YWN0LXJlZmVyZW5jZXMgaXMgZmFz
dGVyIHRoYW4gdW4tZ3ppcHBpbmcgYW5kIHRoZW4gcHJvY2Vzc2luZyB0aGUNCj4gICAgZnVsbCBy
ZWdpbmZvLiAgQnV0IGlmIHlvdXIgbWFqb3IgY29uY2VybiBpcyBkYXRhIGxlbmd0aCAoYmFuZHdp
ZHRoKSwNCj4gICAgZ3ppcCBpcyAqbXVjaCogbW9yZSBlZmZpY2llbnQgLS0gaW4gdGhlIGV4YW1w
bGUsIHVzaW5nDQo+ICAgIGNvbnRhY3QtcmVmZXJlbmNlcyByZWR1Y2VzIHRoZSB0ZXh0IHRvIDIw
MjQgY2hhcmFjdGVycywgYnV0IGd6aXBwaW5nIHRoZQ0KPiAgICBmdWxsIHJlZ2luZm8gZ2l2ZXMg
b25seSAzOTQgb2N0ZXRzLg0KDQpNZXNzYWdlIHNpemUgaXMgb25seSBvbmUgcHJvYmxlbS4NCiAg
DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQogICAgDQoNCg==


From nobody Thu Mar 28 14:45:30 2019
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 722331203B4 for ; Thu, 28 Mar 2019 14:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 EiFt-s3H7cb7 for ; Thu, 28 Mar 2019 14:45:26 -0700 (PDT)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 0D4FA12038C for ; Thu, 28 Mar 2019 14:45:25 -0700 (PDT)
Received: by mail-pg1-x531.google.com with SMTP id j26so149336pgl.5 for ; Thu, 28 Mar 2019 14:45:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V6Zo0CNQ+vIH4dYCUzriI76cYawnQBNHy+jBu/++5BM=; b=VqqCVLFOnj6D9/ggfS1mOduJvrsyT/FESa4FNc3N1CxjXHfe4EvKqpZi4uA9VGJYM2 nkJTQfMchrNZigHOqV4wpMotP5IbqIA1bL4rs+SHKXWhcZLLBU1reuIfMZskJy6V+rK1 nKT/y3DrAPoHdU0hmFwpoz8xZUCc+sHB5ETum/q4i5Jfiz32q2XG2Y6aIYY1QKC6eq2Z xJZE+GbKPEN04IRM4LV+M4+hXuzLdBMIqyqdIy3z/nhjFYR3hM4FlbBRexu53TO8qRqX 4jcTfpWlpO1g6tgIAe3I9PguN2ISYbA83vSUz8q794yFRLYNjuP23HslYJ1qV1hZmRJc 9vMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V6Zo0CNQ+vIH4dYCUzriI76cYawnQBNHy+jBu/++5BM=; b=nf1OaSSNHjZEc4SrDVegYOZpO8cWqQs/LbLAL+StCGmFrDBeMq+bYSaMFF9aiokT6U 9M8ZiIaW5ijoMVxH7XggwUoUcQrTZ/EzTNKh6rW9qThUiV3BbWPlNW7W5g/aLCRu0t1c rsLS6rzXTfTMzoDkAwsPftZg2mcOoDRiaY/DHVBXzRWoaFrQ4TXwUWei9h4aCe/VWyCk pN1Lf8bzT+XYZeDPBL12vgCYUAYgtMs0QEHnuSXc+x7FkVzIwb6cKeTwRWPxwS+OaKjI 9MQb6BWjNyCYgZG9y2wbQuhRped+FVg9CZxlBl+BQsoehZ3DmVW1Z21xrWZ9l6SG2P0v 3cyA==
X-Gm-Message-State: APjAAAUu6TQ+24jR6TJ/+Cdg9hZkhiqbWh+uT/dPBTkcPbIwB9R7O9ch bbn6OSLQBRaVhUAOZVOhnzkCt/y+Vx4=
X-Google-Smtp-Source: APXvYqyeRHqHPVql+U+fGYXBMeeWYowpjYNCVolA38vkbEF8LiBYFv0r8xNhkS4vgeS0YEJvgqyX2w==
X-Received: by 2002:a65:6107:: with SMTP id z7mr28501169pgu.313.1553809525060;  Thu, 28 Mar 2019 14:45:25 -0700 (PDT)
Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com. [209.85.210.182]) by smtp.gmail.com with ESMTPSA id q86sm178661pfi.171.2019.03.28.14.45.23 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 14:45:24 -0700 (PDT)
Received: by mail-pf1-f182.google.com with SMTP id b3so10186pfd.1 for ; Thu, 28 Mar 2019 14:45:23 -0700 (PDT)
X-Received: by 2002:a63:df43:: with SMTP id h3mr3005407pgj.294.1553809523644;  Thu, 28 Mar 2019 14:45:23 -0700 (PDT)
MIME-Version: 1.0
References: <97159F5B-8C69-4B89-A25F-39F95ED57027@ericsson.com> <87bm1vlqjn.fsf@hobgoblin.ariadne.com> <9FCA42CF-01C9-4DEC-AD53-5ABE3E7D66C1@ericsson.com>
In-Reply-To: <9FCA42CF-01C9-4DEC-AD53-5ABE3E7D66C1@ericsson.com>
From: Roman Shpount 
Date: Thu, 28 Mar 2019 17:45:12 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Christer Holmberg 
Cc: "Dale R. Worley" , "sipcore@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000b4a1e105852e78c7"
Archived-At: 
Subject: Re: [sipcore] reg-event issue with multi-identity/multi-device
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Mar 2019 21:45:29 -0000

--000000000000b4a1e105852e78c7
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 28, 2019 at 3:50 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> >    And this is repeated verbatim for each of the 4 AORs.
> >
> >    But if, on each device, the user has a different display-name for each
> >    of the AORs that can reach the device, then all 12 of the 
> >    elements have different  elements.  So you would need a
> >    mechanism that allows more flexibility than just repeating exactly the
> >    same  element in multiple places.
>
> That is true in theory.
>
> But, at least based on me experience, that is not a real-deployment
> problem.
>

Should not each registration entry have a different instance-id/reg-id
(defined in https://tools.ietf.org/html/rfc5626) in unknown-param
attributes?

We see RFC 5626 and those parameters quite commonly implemented. Should the
proposed solution work when RFC 5262 implemented and these parameters are
used?

Regards,
_____________
Roman Shpount

--000000000000b4a1e105852e78c7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Thu, Mar 28, 2019 at =
3:50 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>=C2=A0 =
=C2=A0 And this is repeated verbatim for each of the 4 AORs.

>=C2=A0 =C2=A0 

>=C2=A0 =C2=A0 But if, on each device, the user has a different display-=
name for each

>=C2=A0 =C2=A0 of the AORs that can reach the device, then all 12 of the=
 <contact>

>=C2=A0 =C2=A0 elements have different <display-name> elements.=C2=
=A0 So you would need a

>=C2=A0 =C2=A0 mechanism that allows more flexibility than just repeatin=
g exactly the

>=C2=A0 =C2=A0 same <contact> element in multiple places.



That is true in theory.



But, at least based on me experience, that is not a real-deployment problem=
.

Should not each registration entry ha=
ve a different instance-id/reg-id (defined in=C2=A0https://tools.ietf.org/html/rfc5626) in unknown=
-param attributes?

We see RFC 5626 and those param=
eters quite commonly implemented. Should the proposed solution work when RF=
C 5262 implemented and these parameters are used?

=
Regards,
_____________
Roman Shpount


--000000000000b4a1e105852e78c7--


From nobody Thu Mar 28 18:55:32 2019
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 9BE2E120142 for ; Thu, 28 Mar 2019 18:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.933
X-Spam-Level: 
X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.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 62ge0lXISmuG for ; Thu, 28 Mar 2019 18:55:28 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08ED6120128 for ; Thu, 28 Mar 2019 18:55:27 -0700 (PDT)
Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-08v.sys.comcast.net with ESMTP id 9f4Oh3db00S3o9gjuh2jtq; Fri, 29 Mar 2019 01:55:26 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1553824526; bh=4ilmDvlFvuFLkThS39uLeCApbqPfyKoeluFFAIz3Pp0=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=hceMDc/afxRXBXCKedOXL7hob1ISUub7cyuISZEZncBX5fKcBF9juijTxJ8BR+DJv Mt3b3qegkLxFZyY0ASPy2VU9vdnapGbJH3rFMmjyJ7tNsh9n4n0VhdYg1NLOuHghBN +++qhy+sDMsScZs/2KzDq4/SWrwLhpbmGoDlh5bh0Seyisk2aATHMqlz91H6RZqSyI YEEhR9er5cEav9KMou7UZ7hOL3jPRUWpAcVQ7Hfm4q1v1TkfCktAE/ELo3JfOJw4+x qlRWJefOXEansNpSRKKrJW5PghKSzAkBlXc2dEGhuedTouCEJ8VaWPlxKlJ2mVGA4J b3MBfvZXmbosQ==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-03v.sys.comcast.net with ESMTPA id 9gjshASpyLq869gjuhqs5o; Fri, 29 Mar 2019 01:55:26 +0000
X-Xfinity-VMeta: sc=-100;st=legit
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id x2T1tOsT017108; Thu, 28 Mar 2019 21:55:24 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id x2T1tNWr017105; Thu, 28 Mar 2019 21:55:23 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Roman Shpount 
Cc: christer.holmberg@ericsson.com, sipcore@ietf.org
In-Reply-To:  (roman@telurix.com)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Thu, 28 Mar 2019 21:55:23 -0400
Message-ID: <8736n6la0k.fsf@hobgoblin.ariadne.com>
Archived-At: 
Subject: Re: [sipcore] reg-event issue with multi-identity/multi-device
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 01:55:31 -0000

Roman Shpount  writes:
> Should not each registration entry have a different instance-id/reg-id
> (defined in https://tools.ietf.org/html/rfc5626) in unknown-param
> attributes?

Looking at the example more carefully.  The typical  start
tag and the typical  element look like this:


    
      sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:aaaa]
      String
      String
    

As I read RFC 3680, the id attribute of  and the id
attribute of  have to be unique within the .

The actual name of the AOR displayed to the user on the device is likely
to be customized, but I was probably wrong regarding the 
element here -- it's taken from the Contact header in the REGISTER
request, and most likely is empty.

The sip.instance in the Contact will show up as an 
element, but it should be the same for all  elements for
registrations from the same UA.

The  element -- the contact URI -- is likely to contain both some
part of the AOR and the IP address of the UA, and so they're likely to
be different for every  element.

So any scheme for abridging registration events is likely to have to
deal with uniquess in the  and 'id' strings.

A better way to judge this is to look at a *real* registration event for
a situation like this -- say, three UAs registered for the same three
AORs.  Does anyone have any examples to share?

Dale


From nobody Thu Mar 28 21:52:42 2019
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 8D218120195 for ; Thu, 28 Mar 2019 21:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 OAlqBRE44rCM for ; Thu, 28 Mar 2019 21:52:37 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 A69C912018D for ; Thu, 28 Mar 2019 21:52:37 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id i2so584961pgj.11 for ; Thu, 28 Mar 2019 21:52:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M4TeszJtVtE6YjrBs6DH5XmdmdBdMHct5eRX9lWWeNk=; b=zvgGmqwKbkfIUKJJeZBDNroUIB1pp58zMUx5Ej8pctC+UN8KiE0DIZsDYKdn4JrQxD mKirqNEA7SuIghEjyG4pweoLYnBlaJgJCgBpGpCgbriXeBweIR1MqoAklXTPN734OrM5 c64VizV+S2meW3MjToRmX2XO2wAZborjY2HUJaijeaC8W+szmrYpttFlxGz5BkIP2ycQ ogR5XMuVzEonlxigQ9FsjTYiaUbwkuFeXygemBopFYTo0Ddt9Unq+f60DWirhGvZMVjT rjKMWqkQ/lYsnsIm6FQ4jLeb3bpe0VmI9RYUMylohW6SPo2TszlD8ZE7F92eKkUUkjyi RHEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M4TeszJtVtE6YjrBs6DH5XmdmdBdMHct5eRX9lWWeNk=; b=DMLwVJmk7UHC6IefLxs2xoxrbTcT8fPa04ikuxwdkwDiEc+1qLGEEQC3c8aCwCu9nO Jdo+JCyuog3TEvS0cimobVEtkpv8kA9UJ53529A+2uT+45vvqoO7DgtlHzlIbEvgo8vb uMOyVVAvIHVd5DA3+eLerU3oYe8teoTC//zpavhsbaR35vxBHmT74d2LQS02tmcfUOj0 Etr4fJazWk7ngZjN38MDAVbnFRqV3ovG1xYqVi1Br4EkF4kqSicEk3QPUOKtesdQplMx g1N5WpDdqPcLAy1OTOf6dAenjKHl8MbonjKcHKLvElavucPhi+3ViWQeDozi4UCVD/P8 MkMg==
X-Gm-Message-State: APjAAAWn/9cCC2tJwKNKKyy4ZN2Wv9P+p349EX4+wP/TSMakoZye5pTD OSRgDk2MP32yUB7NusQd7MbHIOHsiz8=
X-Google-Smtp-Source: APXvYqyXTkCx9GtZCKcvfTAFaEhuEblHiBSZWqzgEQ4LB6y/p/ahUcWL6fIxz7lDvaXZO239DXsZeg==
X-Received: by 2002:a63:751d:: with SMTP id q29mr8357525pgc.215.1553835156885;  Thu, 28 Mar 2019 21:52:36 -0700 (PDT)
Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com. [209.85.210.169]) by smtp.gmail.com with ESMTPSA id w2sm1114194pgp.81.2019.03.28.21.52.35 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 21:52:35 -0700 (PDT)
Received: by mail-pf1-f169.google.com with SMTP id y13so437598pfm.11 for ; Thu, 28 Mar 2019 21:52:35 -0700 (PDT)
X-Received: by 2002:a63:a04c:: with SMTP id u12mr44222815pgn.131.1553835155525;  Thu, 28 Mar 2019 21:52:35 -0700 (PDT)
MIME-Version: 1.0
References:  <8736n6la0k.fsf@hobgoblin.ariadne.com>
In-Reply-To: <8736n6la0k.fsf@hobgoblin.ariadne.com>
From: Roman Shpount 
Date: Fri, 29 Mar 2019 00:52:30 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: "Dale R. Worley" 
Cc: Christer Holmberg , SIPCORE 
Content-Type: multipart/alternative; boundary="0000000000007c16c405853470de"
Archived-At: 
Subject: Re: [sipcore] reg-event issue with multi-identity/multi-device
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 04:52:41 -0000

--0000000000007c16c405853470de
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 28, 2019 at 9:55 PM Dale R. Worley  wrote:

> Roman Shpount  writes:
> > Should not each registration entry have a different instance-id/reg-id
> > (defined in https://tools.ietf.org/html/rfc5626) in unknown-param
> > attributes?
>
> The sip.instance in the Contact will show up as an 
> element, but it should be the same for all  elements for
> registrations from the same UA.
>
>
According to RFC5626, UA should maintain two different registrations with
the same sip.instance parameter and different reg-id parameters, which will
also show up in . Also, if the same UA registers for
multiple different AOR, sip.instance will be the same across all of those
registrations, but reg-id parameter will be different. So, essentially, you
will need to deal with different reg-id in  across all of
those registrations.

Regards,
_____________
Roman Shpount

--0000000000007c16c405853470de
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Thu, Mar 28, 2019 at 9:55 PM D=
ale R. Worley <worley@ariadne.com<=
/a>> wrote:
Roman Shpount <roman@telurix.com> writes:

> Should not each registration entry have a different instance-id/reg-id=


> (defined in https://tools.ietf.org/html/rfc5626) in unkn=
own-param

> attributes?


The sip.instance in the Contact will show up as an <unknown-param>=
;

element, but it should be the same for all <contact> elements for

registrations from the same UA.


Acc=
ording to RFC5626, UA should maintain two different registrations with the =
same sip.instance parameter and different reg-id parameters, which will als=
o show up in <unknown-param>. Also, if the same UA registers for mult=
iple different AOR, sip.instance will be the same across all of those regis=
trations, but reg-id parameter will be different. So, essentially, you will=
 need to deal with different reg-id in <unknown-param> across all of =
those registrations.

Regards,=C2=A0
_________=
____
Roman Shpount
=C2=
=A0


--0000000000007c16c405853470de--


From nobody Fri Mar 29 00:39:18 2019
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 CF17C1201EF for ; Fri, 29 Mar 2019 00:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 o0HqJJbgE_kg for ; Fri, 29 Mar 2019 00:39:14 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70079.outbound.protection.outlook.com [40.107.7.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2981B12013D for ; Fri, 29 Mar 2019 00:39:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ByVLTbJQ0iGTlu4lpZ2uEFVNYkx4/w2ow4ZSToA3qBo=; b=IviOza715J0nD0fVQUbWX8KpGojoWPjMmspokg+sWAyyPrGSm3ECGb76Sq7Z3YvZ+MpvM8GpCyYpdY/+FJsbAnhvAdJZxTIC5HKwwwkxarFuGMcIcw/LA1hYhoFyJwlEQX1H89wEOE64u3KdPUzd8AuUfpJ1IPC9iiO3fyQ2lkk=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4393.eurprd07.prod.outlook.com (20.176.167.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Fri, 29 Mar 2019 07:39:10 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1750.014; Fri, 29 Mar 2019 07:39:10 +0000
From: Christer Holmberg 
To: Roman Shpount , "Dale R. Worley" 
CC: SIPCORE 
Thread-Topic: [sipcore] reg-event issue with multi-identity/multi-device
Thread-Index: AQHU5dKIZHWL8hDqjUW2JMDFs9lEoaYiCsgAgABQGAA=
Date: Fri, 29 Mar 2019 07:39:10 +0000
Message-ID: <0F773A8D-4AB8-40F0-9350-6BBD26D4D1F7@ericsson.com>
References:  <8736n6la0k.fsf@hobgoblin.ariadne.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a33141bf-9d4a-4589-191d-08d6b419a23a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4393; 
x-ms-traffictypediagnostic: HE1PR07MB4393:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0991CAB7B3
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(396003)(39860400002)(136003)(346002)(189003)(199004)(81156014)(6116002)(486006)(66066001)(33656002)(44832011)(478600001)(99286004)(476003)(76176011)(14454004)(2616005)(316002)(83716004)(25786009)(58126008)(11346002)(6486002)(81166006)(110136005)(446003)(71200400001)(68736007)(966005)(86362001)(256004)(4744005)(8676002)(82746002)(71190400001)(53936002)(2906002)(4326008)(6512007)(36756003)(6436002)(5660300002)(8936002)(6246003)(105586002)(3846002)(229853002)(97736004)(7736002)(102836004)(186003)(26005)(6506007)(106356001)(305945005)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4393; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 7ec/6MGG7We7fhtASLNdoejj6jm2NRoG72auIU1qNAsKvs7pEh3dTFMQ81Wjfsl/+F0oMX4tgs82Qmu2K5q5pu/vK4V2mQP8euOdKc8WIYrOmd7pVfSv5XsPhtjvGQIBU7Uj/RXkvocGM6oCL8UboUA+bej7a5FCsoQwxXbwswtjvTdKd0NOoq3vNzBs0aexjs2V5zMe0M/AY0Tau3Jv/jAQj0Sq6W4gMqm04wvHhZ4C3+ydPDA3kkNpQ2D02lfxIRaCVYMGO3yoV/d+p8J71cfwTtwG/7NurGdvnbtpjgn94tzPxoPnYLDaOveZ30l0k4Z1IuZOzlvDh7rrPR1Ko7Eqkb3T1aQKgQ5XTUrXOmLMUeZixUsf8BvMVVNBvn8KR+SRS99bWHqdl7gAq87dnaAEl7yun83MibBo/S6Gjbc=
Content-Type: text/plain; charset="utf-8"
Content-ID: <12A87FD97486DA40B67E120912F6CDD5@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a33141bf-9d4a-4589-191d-08d6b419a23a
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2019 07:39:10.6861 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4393
Archived-At: 
Subject: Re: [sipcore] reg-event issue with multi-identity/multi-device
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 07:39:17 -0000

SGksDQoNCj4+PiBTaG91bGQgbm90IGVhY2ggcmVnaXN0cmF0aW9uIGVudHJ5IGhhdmUgYSBkaWZm
ZXJlbnQgaW5zdGFuY2UtaWQvcmVnLWlkDQo+Pj4gKGRlZmluZWQgaW4gaHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL3JmYzU2MjYpIGluIHVua25vd24tcGFyYW0NCj4+PiBhdHRyaWJ1dGVzPw0K
Pj4NCj4+IFRoZSBzaXAuaW5zdGFuY2UgaW4gdGhlIENvbnRhY3Qgd2lsbCBzaG93IHVwIGFzIGFu
IDx1bmtub3duLXBhcmFtPg0KPj4gZWxlbWVudCwgYnV0IGl0IHNob3VsZCBiZSB0aGUgc2FtZSBm
b3IgYWxsIDxjb250YWN0PiBlbGVtZW50cyBmb3INCj4+IHJlZ2lzdHJhdGlvbnMgZnJvbSB0aGUg
c2FtZSBVQS4NCj4NCj4gQWNjb3JkaW5nIHRvIFJGQzU2MjYsIFVBIHNob3VsZCBtYWludGFpbiB0
d28gZGlmZmVyZW50IHJlZ2lzdHJhdGlvbnMgd2l0aCB0aGUgc2FtZSBzaXAuaW5zdGFuY2UgcGFy
YW1ldGVyIGFuZCANCj4gZGlmZmVyZW50IHJlZy1pZCBwYXJhbWV0ZXJzLCB3aGljaCB3aWxsIGFs
c28gc2hvdyB1cCBpbiA8dW5rbm93bi1wYXJhbT4uIEFsc28sIGlmIHRoZSBzYW1lIFVBIHJlZ2lz
dGVycyBmb3IgbXVsdGlwbGUgDQo+IGRpZmZlcmVudCBBT1IsIHNpcC5pbnN0YW5jZSB3aWxsIGJl
IHRoZSBzYW1lIGFjcm9zcyBhbGwgb2YgdGhvc2UgcmVnaXN0cmF0aW9ucywgYnV0IHJlZy1pZCBw
YXJhbWV0ZXIgd2lsbCBiZSBkaWZmZXJlbnQuIA0KPiBTbywgZXNzZW50aWFsbHksIHlvdSB3aWxs
IG5lZWQgdG8gZGVhbCB3aXRoIGRpZmZlcmVudCByZWctaWQgaW4gPHVua25vd24tcGFyYW0+IGFj
cm9zcyBhbGwgb2YgdGhvc2UgcmVnaXN0cmF0aW9ucy4NCg0KU28sIHRoYXQgbWVhbnMgeW91IHdv
dWxkIG5lZWQgc2VwYXJhdGUgY29udGFjdCBlbGVtZW50cyBmb3IgZWFjaCByZWctaWQuIA0KDQpS
ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQrCoA0KDQo=


From nobody Fri Mar 29 00:45:20 2019
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 BAA6B1201ED for ; Fri, 29 Mar 2019 00:45:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 6CYaIa7yiKXK for ; Fri, 29 Mar 2019 00:45:14 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30047.outbound.protection.outlook.com [40.107.3.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC6E1201C1 for ; Fri, 29 Mar 2019 00:45:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BWrml+WsN++QbfR8he4jrG6zeMeB5LfpXKZ81rLq5XM=; b=a1ySuG+s09I8bgt16/neBJAsb0RiEtjUDsEY/GHA9ZjAFvl15AXM0Lq3ZmsJFTekhDqoJpmapq0iPYDU1bIAKeq4q5FBWeWAZtPhr4g3SnP/anhtaHQ9tNZnhIpuUg+DzilHylC9LS6QrGJG0tECWhJ9nF2CSuXjSQotC9cxg7c=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB0954.eurprd07.prod.outlook.com (10.162.27.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Fri, 29 Mar 2019 07:45:11 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1750.014; Fri, 29 Mar 2019 07:45:11 +0000
From: Christer Holmberg 
To: "Dale R. Worley" , Roman Shpount 
CC: "sipcore@ietf.org" 
Thread-Topic: [sipcore] reg-event issue with multi-identity/multi-device
Thread-Index: AQHU5dKIZHWL8hDqjUW2JMDFs9lEoaYiXI0A
Date: Fri, 29 Mar 2019 07:45:11 +0000
Message-ID: <24A3CCD0-F4C9-439F-8A2B-9BA52E071D52@ericsson.com>
References:  <8736n6la0k.fsf@hobgoblin.ariadne.com>
In-Reply-To: <8736n6la0k.fsf@hobgoblin.ariadne.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 262838ca-d2b6-4796-ea89-08d6b41a794d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB0954; 
x-ms-traffictypediagnostic: HE1PR07MB0954:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0991CAB7B3
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(346002)(396003)(366004)(39860400002)(189003)(199004)(58126008)(316002)(7736002)(76176011)(476003)(446003)(11346002)(2616005)(6346003)(26005)(478600001)(99286004)(25786009)(6506007)(486006)(229853002)(305945005)(33656002)(6486002)(6436002)(110136005)(36756003)(86362001)(102836004)(186003)(82746002)(105586002)(106356001)(66066001)(8676002)(81156014)(6116002)(83716004)(44832011)(81166006)(5660300002)(53936002)(71200400001)(71190400001)(8936002)(6306002)(256004)(2906002)(97736004)(14454004)(6512007)(3846002)(6246003)(14444005)(68736007)(4326008)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB0954; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: M7F1n+afmltv/7fUslR9s4ZW5DTDEonY3jHieSB0SVLdUrpCPxrVU7D770B9IsOal7olmaL+yguppr8wiFlkijVFcIKjSd7YFPwyT2RoHnNLiS1upzBI/vqH1jm5+JbHa4ORuo7rkYBqeSm/Ss6d1NP/cm7VRW1qpVEhATivmKlOscfAHNMSOcIIKi0nnygFpGHiXztXsADEm9UUf0Dls0IysGhdyg0y4N1KNpYWt/j3HQVTTgBqsG+QxfijKnhhqVLzJyJzjrgjywE9PkgrYTbMHJJt9KEah17Txnbfz2HNauC3YQszMSZy75A2R6vsKiG0yo7w1Bcdp/BdpT9IftjhtnnrLIba7jxOl5HNdsSHdSwiVjxO6rERd51kTiYnPTO50WG5PYWzVWR6NAbaeMCzvfvotJNA7FHTbEILMiw=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 262838ca-d2b6-4796-ea89-08d6b41a794d
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2019 07:45:11.5061 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0954
Archived-At: 
Subject: Re: [sipcore] reg-event issue with multi-identity/multi-device
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 07:45:18 -0000

SGkgRGFsZSwNCg0KPlNvIGFueSBzY2hlbWUgZm9yIGFicmlkZ2luZyByZWdpc3RyYXRpb24gZXZl
bnRzIGlzIGxpa2VseSB0byBoYXZlIHRvDQo+ZGVhbCB3aXRoIHVuaXF1ZXNzIGluIHRoZSA8dXJp
PiBhbmQgJ2lkJyBzdHJpbmdzLg0KDQpNeSBhc3N1bXB0aW9uIGlzIHRoYXQgdGhlIDx1cmk+IGFu
ZCAnaWQnIGFyZSB1bmlxdWUgZm9yIGVhY2ggY29udGFjdC4gICAgDQoNCj4gICAgQSBiZXR0ZXIg
d2F5IHRvIGp1ZGdlIHRoaXMgaXMgdG8gbG9vayBhdCBhICpyZWFsKiByZWdpc3RyYXRpb24gZXZl
bnQgZm9yDQo+ICAgIGEgc2l0dWF0aW9uIGxpa2UgdGhpcyAtLSBzYXksIHRocmVlIFVBcyByZWdp
c3RlcmVkIGZvciB0aGUgc2FtZSB0aHJlZQ0KPiAgICBBT1JzLiAgRG9lcyBhbnlvbmUgaGF2ZSBh
bnkgZXhhbXBsZXMgdG8gc2hhcmU/DQoNClRoZSBleGFtcGxlIEkgZ2F2ZSB3YXMgcmVmbGVjdGlu
ZyBhIHJlYWwgZGVwbG95bWVudCBzY2VuYXJpby4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K
DQoNCu+7v09uIDI5LzAzLzIwMTksIDMuNTUsICJEYWxlIFIuIFdvcmxleSIgPHdvcmxleUBhcmlh
ZG5lLmNvbT4gd3JvdGU6DQoNCiAgICBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT4g
d3JpdGVzOg0KICAgID4gU2hvdWxkIG5vdCBlYWNoIHJlZ2lzdHJhdGlvbiBlbnRyeSBoYXZlIGEg
ZGlmZmVyZW50IGluc3RhbmNlLWlkL3JlZy1pZA0KICAgID4gKGRlZmluZWQgaW4gaHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL3JmYzU2MjYpIGluIHVua25vd24tcGFyYW0NCiAgICA+IGF0dHJp
YnV0ZXM/DQogICAgDQogICAgTG9va2luZyBhdCB0aGUgZXhhbXBsZSBtb3JlIGNhcmVmdWxseS4g
IFRoZSB0eXBpY2FsIDxyZWdpc3RyYXRpb24+IHN0YXJ0DQogICAgdGFnIGFuZCB0aGUgdHlwaWNh
bCA8Y29udGFjdD4gZWxlbWVudCBsb29rIGxpa2UgdGhpczoNCiAgICANCiAgICA8dG5zOnJlZ2lz
dHJhdGlvbiBpZD0iMTIzNDU2Nzg5MCIgYW9yPSJzaXA6bWFpbHRvOisxNTU1NjY2Nzc3N0BpbXMu
bW5jMDAxLm1jYzAwMS4zZ3BwbmV0d29ya3Mub3JnIj4NCiAgICAgICAgPHRuczpjb250YWN0IGV2
ZW50PSJyZWdpc3RlcmVkIiBpZD0iMjM0NTY3ODkwMSIgZHVyYXRpb24tcmVnaXN0ZXJlZD0iNDI5
NDk2NzI5NSINCiAgICAJIGNzZXE9IjQyOTQ5NjcyOTUiIHJldHJ5LWFmdGVyPSI0Mjk0OTY3Mjk1
IiBxPSIwIiBzdGF0ZT0iYWN0aXZlIg0KICAgIAkgY2FsbGlkPSJTdHJpbmciIGV4cGlyZXM9IjQy
OTQ5NjcyOTUiPg0KICAgICAgICAgIDx0bnM6dXJpPnNpcDorMTU1NTY2Njc3NzdAWzIwMDE6MGRi
ODo4NWEzOjAwMDA6MDAwMDo4YTJlOjAzNzA6YWFhYV08L3Ruczp1cmk+DQogICAgICAgICAgPHRu
czpkaXNwbGF5LW5hbWUgeG1sOmxhbmc9ImVuLXVzIj5TdHJpbmc8L3RuczpkaXNwbGF5LW5hbWU+
DQogICAgICAgICAgPHRuczp1bmtub3duLXBhcmFtIG5hbWU9IlN0cmluZyI+U3RyaW5nPC90bnM6
dW5rbm93bi1wYXJhbT4NCiAgICAgICAgPC90bnM6Y29udGFjdD4NCiAgICANCiAgICBBcyBJIHJl
YWQgUkZDIDM2ODAsIHRoZSBpZCBhdHRyaWJ1dGUgb2YgPHJlZ2lzdHJhdGlvbj4gYW5kIHRoZSBp
ZA0KICAgIGF0dHJpYnV0ZSBvZiA8Y29udGFjdD4gaGF2ZSB0byBiZSB1bmlxdWUgd2l0aGluIHRo
ZSA8cmVnaW5mbz4uDQogICAgDQogICAgVGhlIGFjdHVhbCBuYW1lIG9mIHRoZSBBT1IgZGlzcGxh
eWVkIHRvIHRoZSB1c2VyIG9uIHRoZSBkZXZpY2UgaXMgbGlrZWx5DQogICAgdG8gYmUgY3VzdG9t
aXplZCwgYnV0IEkgd2FzIHByb2JhYmx5IHdyb25nIHJlZ2FyZGluZyB0aGUgPGRpc3BsYXktbmFt
ZT4NCiAgICBlbGVtZW50IGhlcmUgLS0gaXQncyB0YWtlbiBmcm9tIHRoZSBDb250YWN0IGhlYWRl
ciBpbiB0aGUgUkVHSVNURVINCiAgICByZXF1ZXN0LCBhbmQgbW9zdCBsaWtlbHkgaXMgZW1wdHku
DQogICAgDQogICAgVGhlIHNpcC5pbnN0YW5jZSBpbiB0aGUgQ29udGFjdCB3aWxsIHNob3cgdXAg
YXMgYW4gPHVua25vd24tcGFyYW0+DQogICAgZWxlbWVudCwgYnV0IGl0IHNob3VsZCBiZSB0aGUg
c2FtZSBmb3IgYWxsIDxjb250YWN0PiBlbGVtZW50cyBmb3INCiAgICByZWdpc3RyYXRpb25zIGZy
b20gdGhlIHNhbWUgVUEuDQogICAgDQogICAgVGhlIDx1cmk+IGVsZW1lbnQgLS0gdGhlIGNvbnRh
Y3QgVVJJIC0tIGlzIGxpa2VseSB0byBjb250YWluIGJvdGggc29tZQ0KICAgIHBhcnQgb2YgdGhl
IEFPUiBhbmQgdGhlIElQIGFkZHJlc3Mgb2YgdGhlIFVBLCBhbmQgc28gdGhleSdyZSBsaWtlbHkg
dG8NCiAgICBiZSBkaWZmZXJlbnQgZm9yIGV2ZXJ5IDxjb250YWN0PiBlbGVtZW50Lg0KICAgIA0K
ICAgIFNvIGFueSBzY2hlbWUgZm9yIGFicmlkZ2luZyByZWdpc3RyYXRpb24gZXZlbnRzIGlzIGxp
a2VseSB0byBoYXZlIHRvDQogICAgZGVhbCB3aXRoIHVuaXF1ZXNzIGluIHRoZSA8dXJpPiBhbmQg
J2lkJyBzdHJpbmdzLg0KICAgIA0KICAgIEEgYmV0dGVyIHdheSB0byBqdWRnZSB0aGlzIGlzIHRv
IGxvb2sgYXQgYSAqcmVhbCogcmVnaXN0cmF0aW9uIGV2ZW50IGZvcg0KICAgIGEgc2l0dWF0aW9u
IGxpa2UgdGhpcyAtLSBzYXksIHRocmVlIFVBcyByZWdpc3RlcmVkIGZvciB0aGUgc2FtZSB0aHJl
ZQ0KICAgIEFPUnMuICBEb2VzIGFueW9uZSBoYXZlIGFueSBleGFtcGxlcyB0byBzaGFyZT8NCiAg
ICANCiAgICBEYWxlDQogICAgDQoNCg==


From nobody Fri Mar 29 01:47:19 2019
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 4CD11120437 for ; Fri, 29 Mar 2019 01:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 PQ_bd_6oW14Q for ; Fri, 29 Mar 2019 01:47:03 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40050.outbound.protection.outlook.com [40.107.4.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AF42120445 for ; Fri, 29 Mar 2019 01:47:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Uri7S809JMWMlaQDYOtTe0TvbHyinxjtZBef+viPxKk=; b=D9KX/WOeD5Uz1BxTa4pQkGUoOos1WasTb+5WFN9awyePq4ELf+TVHSgbZjyJgonjZL5sbwiHQbVz41SLm+2TAGnH29T+Vg5CuvQhEasKay+FD8ivChxsUCRMv/NobIZ2tAs/z+Xm6QGpdQGAUP5CwhTJARkRYrSgfXpXyaoMRl0=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3337.eurprd07.prod.outlook.com (10.170.247.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Fri, 29 Mar 2019 08:47:00 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1750.014; Fri, 29 Mar 2019 08:47:00 +0000
From: Christer Holmberg 
To: Andy Hutton , "Dale R. Worley" 
CC: "rifaat.sy@gmail.com" , SIPCORE 
Thread-Topic: [sipcore] ABNF: request-digest: 32 characters, only 32 characters and nothing but 32 characters?
Thread-Index: AQHTpLmHxKt9ONeoFEmooBFZAE7p66OjOFCAgABwZ4CAAQpLgIAAZ9OAgABRhgCAAM8mgIA05ZSAgknO8IA=
Date: Fri, 29 Mar 2019 08:47:00 +0000
Message-ID: 
References:  <87vaexg01a.fsf@hobgoblin.ariadne.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f656d480-b566-40d0-a0b7-08d6b4231bde
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3337; 
x-ms-traffictypediagnostic: HE1PR07MB3337:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0991CAB7B3
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(376002)(136003)(366004)(199004)(189003)(18543002)(2616005)(6246003)(25786009)(486006)(6306002)(97736004)(81166006)(6512007)(5660300002)(81156014)(82746002)(446003)(476003)(36756003)(966005)(68736007)(53936002)(66066001)(58126008)(7736002)(33656002)(14454004)(53546011)(6506007)(229853002)(26005)(76176011)(102836004)(316002)(8936002)(11346002)(71190400001)(105586002)(186003)(478600001)(54906003)(110136005)(6486002)(86362001)(4326008)(71200400001)(2906002)(83716004)(6436002)(256004)(305945005)(44832011)(8676002)(99286004)(106356001)(6116002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3337; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 0laKlM9KSN8+GVEIBKIout+E4DMqP1btaGHYpOJZ+KCNNI5W7cphxevcAQotC3Dj2IiRYh/oKYV+plNGBZud7fdxYTn97inTOm4imL5tFzKWfY83cCOe0aQaJNS1t1V5qg6EeiqYTnlCHzKgoVXnbDlDB8+CkO/6UsjUqX0nDUchcmfDR1w8+KNiSkBhL6WQa60v/3ge5oJaEl3En/4bEP325+fBj4NHKKa4ED9kZKnaSBWSAjN46zjR3KjlffyKMhGr8sypzyHsf3bWBtZzoJiCmNTEKdX1Q9a7JQee5AdyhDMvQgXiGs9PCuWTnte8k6o2z4KFNM/pFpf2ycbwp+Jm6Jd97MdSoEXgNwLxF+YWQYlR5XnV/Wwk1fbb5kZH4YaP9w7Mzv2btmYtokrWGi9rxI+ZRnWcmxNGTi3YH9g=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f656d480-b566-40d0-a0b7-08d6b4231bde
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2019 08:47:00.2022 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3337
Archived-At: 
Subject: Re: [sipcore] ABNF: request-digest: 32 characters, only 32 characters and nothing but 32 characters?
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 08:47:18 -0000

SGksDQoNClRoaXMgdGhyZWFkIGlzIGEgeWVhciBvbGQsIGJ1dCBJIHdvdWxkIGxpa2UgdG8gYnJp
bmcgaXQgYmFjayB0byB0aGUgc3VyZmFjZS4NCg0KVGhlIHN5bnRheCBuZWVkcyB0byBiZSBmaXhl
ZCwgc28gSSB3b3VsZCBsaWtlIHRoZSBXRyB0byBhZG9wdCB0aGUgZHJhZnQuDQoNClJlZ2FyZHMs
DQoNCkNocmlzdGVyDQoNCg0K77u/T24gMjEvMDMvMjAxOCwgMTkuNTQsICJBbmR5IEh1dHRvbiIg
PGFuZHlodXR0b24uaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KDQogICAgSSB3b3VsZCBhbHNvIGxp
a2UgdG8gc2VlIGRyYWZ0LXl1c2VmLXNpcGNvcmUtZGlnZXN0LXNjaGVtZSBhZG9wdGVkLg0KICAg
IA0KICAgIEFuZHkNCiAgICANCiAgICBPbiAxNiBGZWJydWFyeSAyMDE4IGF0IDAyOjA3LCBEYWxl
IFIuIFdvcmxleSA8d29ybGV5QGFyaWFkbmUuY29tPiB3cm90ZToNCiAgICA+IENocmlzdGVyIEhv
bG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyaXRlczoNCiAgICA+PiBJ
IHJlYWxpc2VkIHRoYXQgUmlmYWF0J3MgZHJhZnQgYWN0dWFsbHkgdXBkYXRlcyB0aGUgQUJORiAo
YnkgcmVtb3ZpbmcgdGhlDQogICAgPj4gMzIgY2hhcmFjdGVycyByZXN0cmljdGlvbiksIHNvIHdl
IHdvdWxkbid0IG5lZWQgYW55dGhpbmcgaW4gYWRkaXRpb24gdG8NCiAgICA+PiB0aGF0Lg0KICAg
ID4NCiAgICA+IEkgd2FzIGdvaW5nIHRvIHNheSwgV2hhdCBpcyB0aGUgbmFtZSBvZiB0aGUgZHJh
ZnQ/LCBidXQgaXQncw0KICAgID4gZHJhZnQteXVzZWYtc2lwY29yZS1kaWdlc3Qtc2NoZW1lLCB3
aGljaCBpcyBkYXRlZCBsYXN0IFNlcHRlbWJlciwgd2hpY2gNCiAgICA+IGlzIHByb2JhYmx5IHdo
eSBJIHJlbWVtYmVyIGl0Lg0KICAgID4NCiAgICA+IEl0IG5vdCBvbmx5IHVwZGF0ZXMgdGhlIEFC
TkYgaW4gUkZDIDMyNjEsIGl0IGFsc28gY29ubmVjdHMgaXQgd2l0aCBSRkMNCiAgICA+IDc2MTEu
DQogICAgPg0KICAgID4gLS0tPiBTbywgSSBjYWxsIGZvciBhZG9wdGlvbiBvZiBkcmFmdC15dXNl
Zi1zaXBjb3JlLWRpZ2VzdC1zY2hlbWUgYXMgYQ0KICAgID4gV0cgZHJhZnQuDQogICAgPg0KICAg
ID4gRGFsZQ0KICAgID4NCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQogICAgPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KICAgID4gc2lwY29yZUBp
ZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj
b3JlDQogICAgDQoNCg==


From nobody Sat Mar 30 12:28:35 2019
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 8650E1202D9 for ; Sat, 30 Mar 2019 12:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDTDzLZFWGzA for ; Sat, 30 Mar 2019 12:28:31 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 075D9120270 for ; Sat, 30 Mar 2019 12:28:31 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id f6so4512220iop.3 for ; Sat, 30 Mar 2019 12:28:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pPCAcz84fwrfFshiO8pBqDrF4+EBJToyy1xiCr78cvc=; b=AsGl1ytx16kWSFTjXhIn6cKx1iy5z7dbmOG/sg/uJFeX7gNv9jLfC+djHe1MCcQeiR CGAnEKAUxca3AVYXB2ogZj9huyBwbkIqF+c4iotm/Qu8rGJcbhjRlVPKtP6oyuCHFu/S S1Wiv/E++BfGEA+Mhl1jgDStOYHBhkERaLZfG7a6B21uV9Z5eiVVwrK2HJgh2M2gUysc xng5e6GsYw2ivtJC7NVtm8yL+RVXdx3deFLlDggmD3PZ4awC0Vc5OQ3UUh5ysZ5K3LUk zpbXOAIVhU8FLvpns+XIK/FP6ovuVsoOoXQtmNcfL0SQ3T7yE+eHwayyLzroWR4gfcCi gN0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pPCAcz84fwrfFshiO8pBqDrF4+EBJToyy1xiCr78cvc=; b=j51dfKHhaKVoXobKFQhgGC/RCr0/LD/IC/FUmviw2a5wA8UR5LKLHUCfAN3MnaUZwG 4zs/Nr9TIoUOUNWM83ogd1VSWzqD+UCSVOjpwW0/bnl+CAxwWAI9jpjGLxvVGQj7hsO5 KCFhiTPc/bGSbd+0iBD1mDsKMPL+zMWqK28FCbc9uSM4keg4BM01plClu7cTYzIHwHCz 99LunOwv+02z23lhdzgKqOae1BjH+4vlhXFWuV67uJgrxwyeeSgdsWjq/Bd6CNgpvAlY JB9Pu2EqmcxRKMm0vANSmTjAYIkU0DZ5KAQaeSwF9nD7gqxA9NEeDS2saD0i1lmSBa7q ww1Q==
X-Gm-Message-State: APjAAAX7NgqdOVODxnZMuexxpwIuZfkMUfgX5tFP9jFKSJXbSzjY40qW a1k9MzsCUDb1sm0KY8lq+wGNasNK4rubtCio8nM=
X-Google-Smtp-Source: APXvYqwyuySi/VZlxaXvjTPlWKYK2qZjDL2oZyOdXY1nlIbUpPwic1z5Dw9Umw2EyiSKEBjYEfv3/F6O7WBV6jkXRoQ=
X-Received: by 2002:a5d:8597:: with SMTP id f23mr9412727ioj.148.1553974110376;  Sat, 30 Mar 2019 12:28:30 -0700 (PDT)
MIME-Version: 1.0
References:  <87vaexg01a.fsf@hobgoblin.ariadne.com>  
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Sat, 30 Mar 2019 15:28:19 -0400
Message-ID: 
To: Christer Holmberg 
Cc: Andy Hutton , "Dale R. Worley" ,  "rifaat.sy@gmail.com" , SIPCORE 
Content-Type: multipart/alternative; boundary="000000000000d6d8b2058554ca86"
Archived-At: 
Subject: Re: [sipcore] ABNF: request-digest: 32 characters, only 32 characters and nothing but 32 characters?
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Mar 2019 19:28:34 -0000

--000000000000d6d8b2058554ca86
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I am honestly really puzzled why this draft has not be adopted long time
ago.
This could have been delivered few years ago already.

What is stopping this from happening?

Regards,
 Rifaat



On Fri, Mar 29, 2019 at 4:47 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> This thread is a year old, but I would like to bring it back to the
> surface.
>
> The syntax needs to be fixed, so I would like the WG to adopt the draft.
>
> Regards,
>
> Christer
>
>
> =EF=BB=BFOn 21/03/2018, 19.54, "Andy Hutton"  =
wrote:
>
>     I would also like to see draft-yusef-sipcore-digest-scheme adopted.
>
>     Andy
>
>     On 16 February 2018 at 02:07, Dale R. Worley 
> wrote:
>     > Christer Holmberg  writes:
>     >> I realised that Rifaat's draft actually updates the ABNF (by
> removing the
>     >> 32 characters restriction), so we wouldn't need anything in
> addition to
>     >> that.
>     >
>     > I was going to say, What is the name of the draft?, but it's
>     > draft-yusef-sipcore-digest-scheme, which is dated last September,
> which
>     > is probably why I remember it.
>     >
>     > It not only updates the ABNF in RFC 3261, it also connects it with
> RFC
>     > 7611.
>     >
>     > ---> So, I call for adoption of draft-yusef-sipcore-digest-scheme a=
s
> a
>     > WG draft.
>     >
>     > Dale
>     >
>     > _______________________________________________
>     > sipcore mailing list
>     > sipcore@ietf.org
>     > https://www.ietf.org/mailman/listinfo/sipcore
>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>

--000000000000d6d8b2058554ca86
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I am honestly really puzzled why this draft has not be ado=
pted long time ago.
This could have been delivered few years=C2=A0ago a=
lready.

What is stopping this from happening?

Regards,
=C2=A0Rifaat


On Fri, Mar 29, 2019 at 4:47 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi=
,



This thread is a year old, but I would like to bring it back to the surface=
.



The syntax needs to be fixed, so I would like the WG to adopt the draft.


Regards,



Christer





=EF=BB=BFOn 21/03/2018, 19.54, "Andy Hutton" <andyhutton.ietf@gmail.com> wrote:



=C2=A0 =C2=A0 I would also like to see draft-yusef-sipcore-digest-scheme ad=
opted.



=C2=A0 =C2=A0 Andy



=C2=A0 =C2=A0 On 16 February 2018 at 02:07, Dale R. Worley <worley@ariadne.com> wrot=
e:

=C2=A0 =C2=A0 > Christer Holmberg <christer.holmberg@ericsson.com> wr=
ites:

=C2=A0 =C2=A0 >> I realised that Rifaat's draft actually updates =
the ABNF (by removing the

=C2=A0 =C2=A0 >> 32 characters restriction), so we wouldn't need =
anything in addition to

=C2=A0 =C2=A0 >> that.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > I was going to say, What is the name of the draft?, but =
it's

=C2=A0 =C2=A0 > draft-yusef-sipcore-digest-scheme, which is dated last S=
eptember, which

=C2=A0 =C2=A0 > is probably why I remember it.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > It not only updates the ABNF in RFC 3261, it also connec=
ts it with RFC

=C2=A0 =C2=A0 > 7611.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > ---> So, I call for adoption of draft-yusef-sipcore-d=
igest-scheme as a

=C2=A0 =C2=A0 > WG draft.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Dale

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > _______________________________________________

=C2=A0 =C2=A0 > sipcore mailing list

=C2=A0 =C2=A0 > si=
pcore@ietf.org

=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinf=
o/sipcore





_______________________________________________

sipcore mailing list

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




--000000000000d6d8b2058554ca86--


From nobody Sun Mar 31 10:54:52 2019
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 2F2231201AC; Sun, 31 Mar 2019 10:54:44 -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.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: sipcore@ietf.org
Message-ID: <155405488411.12377.4081014867895170518@ietfa.amsl.com>
Date: Sun, 31 Mar 2019 10:54:44 -0700
Archived-At: 
Subject: [sipcore] I-D Action: draft-ietf-sipcore-rejected-05.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Mar 2019 17:54:44 -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 WG of the IETF.

        Title           : A Session Initiation Protocol (SIP) Response Code for Rejected Calls
        Authors         : Eric W. Burger
                          Bhavik Nagda
	Filename        : draft-ietf-sipcore-rejected-05.txt
	Pages           : 22
	Date            : 2019-03-31

Abstract:
   This document defines the 608 (Rejected) SIP response code.  This
   response code enables calling parties to learn that an intermediary
   rejected their call attempt.  The call will not be answered.  As a
   6xx code, the caller will be aware that future attempts to contact
   the same UAS will likely fail.  The present use case driving the need
   for the 608 response code is when the intermediary is an analytics
   engine.  In this case, the rejection is by a machine or other
   process.  This contrasts with the 607 (Unwanted) SIP response code,
   which a human at the target UAS indicated the call was not wanted.
   In some jurisdictions this distinction is important.  This document
   also defines the use of the Call-Info header in 608 responses to
   enable rejected callers to contact entities that blocked their calls
   in error.  This provides a remediation mechanism for legal callers
   that find their calls blocked.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-rejected-05
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rejected-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sun Mar 31 10:56:37 2019
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 9A78E1201AE for ; Sun, 31 Mar 2019 10:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.69
X-Spam-Level: 
X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.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 zg-CYf55NgCe for ; Sun, 31 Mar 2019 10:56:34 -0700 (PDT)
Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [198.46.93.79]) (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 5EE411201AC for ; Sun, 31 Mar 2019 10:56:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Message-Id:In-Reply-To:To:References:Date: Subject:Mime-Version:Content-Type:From:Sender:Reply-To:Cc: Content-Transfer-Encoding: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=O6T9R3IYqmWWG4SLdslhDWBnaKbIp4aJnk1NeqQb1PI=; b=GBW0vgVmv0O9cHClHKRCsr7YB DXQdVbvczjDEDYw18/HDJUJ1zZmUbhgvmjD/dLkRuDHf3KxCrc0R2uKdWOhDG7f1gebRHR2Kq15y0 0cKWYk7S7DwrICDjtIzhUsw0ketcfmqW1a66fzyqDbZ9fPdcjXepDb+fDoqeeHkVtGSE4=;
Received: from [68.100.196.217] (port=55828 helo=[192.168.10.26]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hAegw-000SKy-VK for sipcore@ietf.org; Sun, 31 Mar 2019 10:56:33 -0700
From: Eric Burger 
Content-Type: multipart/signed; boundary="Apple-Mail=_8E304D0E-9031-429F-AF85-FF1A96233465"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Sun, 31 Mar 2019 13:56:20 -0400
References: <155405488411.12377.4081014867895170518@ietfa.amsl.com>
To: sipcore@ietf.org
In-Reply-To: <155405488411.12377.4081014867895170518@ietfa.amsl.com>
Message-Id: <731E6922-A1DA-43D7-BC83-FE37759B281E@standardstrack.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rejected-05.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Mar 2019 17:56:36 -0000

--Apple-Mail=_8E304D0E-9031-429F-AF85-FF1A96233465
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Fixed the nit that Christer found.

> On Mar 31, 2019, at 1:54 PM, internet-drafts@ietf.org wrote:
>=20
>=20
> 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 WG =
of the IETF.
>=20
>        Title           : A Session Initiation Protocol (SIP) Response =
Code for Rejected Calls
>        Authors         : Eric W. Burger
>                          Bhavik Nagda
> 	Filename        : draft-ietf-sipcore-rejected-05.txt
> 	Pages           : 22
> 	Date            : 2019-03-31
>=20
> Abstract:
>   This document defines the 608 (Rejected) SIP response code.  This
>   response code enables calling parties to learn that an intermediary
>   rejected their call attempt.  The call will not be answered.  As a
>   6xx code, the caller will be aware that future attempts to contact
>   the same UAS will likely fail.  The present use case driving the =
need
>   for the 608 response code is when the intermediary is an analytics
>   engine.  In this case, the rejection is by a machine or other
>   process.  This contrasts with the 607 (Unwanted) SIP response code,
>   which a human at the target UAS indicated the call was not wanted.
>   In some jurisdictions this distinction is important.  This document
>   also defines the use of the Call-Info header in 608 responses to
>   enable rejected callers to contact entities that blocked their calls
>   in error.  This provides a remediation mechanism for legal callers
>   that find their calls blocked.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-sipcore-rejected-05
> https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected-05
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rejected-05
>=20
>=20
> 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.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore


--Apple-Mail=_8E304D0E-9031-429F-AF85-FF1A96233465
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEfEc/N7T7IfiAuDEHDDCGh758rskFAlyg/0UACgkQDDCGh758
rskiVxAAj4jReUstArsdMb2Afgov5d8GnnOw92NsipQp0tPVwsS/63wDTnupH7ue
rCClB/lN6BHgWvPf4v28D1xZMyBayP0co/pM7Y1x2FBtv4I2gwsXOZlLGe+LtDXG
jblXuMW5brkBOcfoPE/dl7Uru6VnCjfVwtK2z182/VvgBirYiJNiOuESaP8uv86Q
SNh+0fixj1YjI82eUzdpsGLNL3g2hNerXndwbXCosGkg73xugj7TtXieLPrBMDV/
00Bnl1gA0BAknu8woUMhGxZfdyc/hMUrORYFPmCglJ4HpHaZdJwkzNyU2LEBMveG
kf2DiiXjpivO5RvqfrLYgv2IBs3JqytO1/0dX72psKK4dGFEZv6nWdIO4mMeVy9f
TEhfXQ3+9bCtkdsiHOYZqFguY8SX9/iSae6lfwGkzcmL+5AW3mjIDsPJjtRufBCF
qFLGL2+RYCJqAQhn+uhmYPQGExPSbS8g7HBPnerhQkBBH9X4S7OYMMsG6TRJ5z5l
HISNUCuupOmG/vGJqg7b4w5XLet1vEZJih6RDUrIJnYeW3omSF6aNYzRXBaOGOC5
gY5GFxBTpFsITp0w2PKeFkHPdmoWN8gZoDEbzrr724uudixhGfFDl9OS04QStkb2
BddLe/aXePpW0I5yVLD4HfqWgZaaipe8ckUI84EHNo0jHltl7e8=
=vZXy
-----END PGP SIGNATURE-----

--Apple-Mail=_8E304D0E-9031-429F-AF85-FF1A96233465--


From nobody Sun Mar 31 12:26:30 2019
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 B0B4312000E for ; Sun, 31 Mar 2019 12:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 E2QpGda-gQS8 for ; Sun, 31 Mar 2019 12:26:26 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00050.outbound.protection.outlook.com [40.107.0.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A921F120003 for ; Sun, 31 Mar 2019 12:26:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Gvj5kTtQUTmwFcy4KP8ewL2wylpUB9HGcZQb7hLllaQ=; b=hEmpakWHbhMl96FfiFw8pl+fa7p4b3t7nmLhptH5EJG4RnSXm+5y0wdwgssC7VukXHVe8Bv19AwCdmLuxRk7I1JX748g/m3MUo0UsKaXEGFD+z/QdcMONoKbYJrP66lXLx87iZ5FTLxU+M6gEuN1fzLzKMxWaaaFE26GVFzDZ5w=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3241.eurprd07.prod.outlook.com (10.170.246.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Sun, 31 Mar 2019 19:26:21 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1771.007; Sun, 31 Mar 2019 19:26:21 +0000
From: Christer Holmberg 
To: Eric Burger , "sipcore@ietf.org" 
Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-rejected-05.txt
Thread-Index: AQHU5+r2RO38/JJvSkuLNxq5LVkmn6YmBkEAgABLcYA=
Date: Sun, 31 Mar 2019 19:26:21 +0000
Message-ID: <7AADCD87-12F6-4A88-ACA4-5C59C74E450F@ericsson.com>
References: <155405488411.12377.4081014867895170518@ietfa.amsl.com> <731E6922-A1DA-43D7-BC83-FE37759B281E@standardstrack.com>
In-Reply-To: <731E6922-A1DA-43D7-BC83-FE37759B281E@standardstrack.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [87.93.95.44]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b1882a2c-5c03-4413-07a2-08d6b60ec1e6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3241; 
x-ms-traffictypediagnostic: HE1PR07MB3241:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0993689CD1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(396003)(39860400002)(346002)(366004)(199004)(189003)(81156014)(476003)(8936002)(105586002)(966005)(2906002)(6436002)(229853002)(106356001)(76176011)(44832011)(8676002)(25786009)(6506007)(26005)(478600001)(11346002)(102836004)(2501003)(36756003)(446003)(2616005)(6512007)(53546011)(99286004)(14454004)(14444005)(3846002)(71200400001)(186003)(83716004)(110136005)(68736007)(6116002)(6486002)(53936002)(71190400001)(5660300002)(66066001)(33656002)(7736002)(97736004)(86362001)(6246003)(82746002)(81166006)(486006)(58126008)(66574012)(256004)(6306002)(305945005)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3241; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: yXSQiX8/PQ2sg70I6cbuylzJ8iTqcJvUAhqxh6/+zlRJ25dCm1kjN9+DJdGoptBL9eVfv+9ogd7uZ1oCDXFTdDRpLvQiwN8w2YNAYLNI/Q1FStMviuX9uyiA7Pgy4yKaZ24zI/EGZfs5cwExbi0/eEvcHjkdHG+JeXVXDv4+y2eD5WUN0adNjmB/eYh1CkcZHEEYA50f4uRICLgvky62p3Aml9S2skFvgszpAvvjQP34QJ8eEi1xQVp7EVA/hOdv+EETLhlQLfjqqfFVZq0y+XLKTuJNRdIvtTrvK+ias4J16NwhBz1gDaCoQCnb6XssnyvSUHyQRBr/gDbJYOpBZ7pbetadRCeVwFTeXY+BcT2plW4QkDJ3ffwMpXyw1DuFnXEdAibq3IoRzo1VOpcJbuFoINwz1FSSaY2eVlbkZgE=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b1882a2c-5c03-4413-07a2-08d6b60ec1e6
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2019 19:26:21.6978 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3241
Archived-At: 
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rejected-05.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Mar 2019 19:26:29 -0000

SGksDQoNClRoZSBjcmVkaXRzIGZvciBmaW5kaW5nIHRoZSBuaXQgYmVsb25nIHRvIFllaG9zaHVh
LCBidXQgdGhhbmtzIGZvciBmaXhpbmcgaXQgX18NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K
DQrvu79PbiAzMS8wMy8yMDE5LCAyMC41NiwgInNpcGNvcmUgb24gYmVoYWxmIG9mIEVyaWMgQnVy
Z2VyIiA8c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBlYnVyZ2VyQHN0YW5k
YXJkc3RyYWNrLmNvbT4gd3JvdGU6DQoNCiAgICBGaXhlZCB0aGUgbml0IHRoYXQgQ2hyaXN0ZXIg
Zm91bmQuDQogICAgDQogICAgPiBPbiBNYXIgMzEsIDIwMTksIGF0IDE6NTQgUE0sIGludGVybmV0
LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCiAgICA+IA0KICAgID4gDQogICAgPiBBIE5ldyBJbnRl
cm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMg
ZGlyZWN0b3JpZXMuDQogICAgPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTZXNz
aW9uIEluaXRpYXRpb24gUHJvdG9jb2wgQ29yZSBXRyBvZiB0aGUgSUVURi4NCiAgICA+IA0KICAg
ID4gICAgICAgIFRpdGxlICAgICAgICAgICA6IEEgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29s
IChTSVApIFJlc3BvbnNlIENvZGUgZm9yIFJlamVjdGVkIENhbGxzDQogICAgPiAgICAgICAgQXV0
aG9ycyAgICAgICAgIDogRXJpYyBXLiBCdXJnZXINCiAgICA+ICAgICAgICAgICAgICAgICAgICAg
ICAgICBCaGF2aWsgTmFnZGENCiAgICA+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXNp
cGNvcmUtcmVqZWN0ZWQtMDUudHh0DQogICAgPiAJUGFnZXMgICAgICAgICAgIDogMjINCiAgICA+
IAlEYXRlICAgICAgICAgICAgOiAyMDE5LTAzLTMxDQogICAgPiANCiAgICA+IEFic3RyYWN0Og0K
ICAgID4gICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIDYwOCAoUmVqZWN0ZWQpIFNJUCByZXNw
b25zZSBjb2RlLiAgVGhpcw0KICAgID4gICByZXNwb25zZSBjb2RlIGVuYWJsZXMgY2FsbGluZyBw
YXJ0aWVzIHRvIGxlYXJuIHRoYXQgYW4gaW50ZXJtZWRpYXJ5DQogICAgPiAgIHJlamVjdGVkIHRo
ZWlyIGNhbGwgYXR0ZW1wdC4gIFRoZSBjYWxsIHdpbGwgbm90IGJlIGFuc3dlcmVkLiAgQXMgYQ0K
ICAgID4gICA2eHggY29kZSwgdGhlIGNhbGxlciB3aWxsIGJlIGF3YXJlIHRoYXQgZnV0dXJlIGF0
dGVtcHRzIHRvIGNvbnRhY3QNCiAgICA+ICAgdGhlIHNhbWUgVUFTIHdpbGwgbGlrZWx5IGZhaWwu
ICBUaGUgcHJlc2VudCB1c2UgY2FzZSBkcml2aW5nIHRoZSBuZWVkDQogICAgPiAgIGZvciB0aGUg
NjA4IHJlc3BvbnNlIGNvZGUgaXMgd2hlbiB0aGUgaW50ZXJtZWRpYXJ5IGlzIGFuIGFuYWx5dGlj
cw0KICAgID4gICBlbmdpbmUuICBJbiB0aGlzIGNhc2UsIHRoZSByZWplY3Rpb24gaXMgYnkgYSBt
YWNoaW5lIG9yIG90aGVyDQogICAgPiAgIHByb2Nlc3MuICBUaGlzIGNvbnRyYXN0cyB3aXRoIHRo
ZSA2MDcgKFVud2FudGVkKSBTSVAgcmVzcG9uc2UgY29kZSwNCiAgICA+ICAgd2hpY2ggYSBodW1h
biBhdCB0aGUgdGFyZ2V0IFVBUyBpbmRpY2F0ZWQgdGhlIGNhbGwgd2FzIG5vdCB3YW50ZWQuDQog
ICAgPiAgIEluIHNvbWUganVyaXNkaWN0aW9ucyB0aGlzIGRpc3RpbmN0aW9uIGlzIGltcG9ydGFu
dC4gIFRoaXMgZG9jdW1lbnQNCiAgICA+ICAgYWxzbyBkZWZpbmVzIHRoZSB1c2Ugb2YgdGhlIENh
bGwtSW5mbyBoZWFkZXIgaW4gNjA4IHJlc3BvbnNlcyB0bw0KICAgID4gICBlbmFibGUgcmVqZWN0
ZWQgY2FsbGVycyB0byBjb250YWN0IGVudGl0aWVzIHRoYXQgYmxvY2tlZCB0aGVpciBjYWxscw0K
ICAgID4gICBpbiBlcnJvci4gIFRoaXMgcHJvdmlkZXMgYSByZW1lZGlhdGlvbiBtZWNoYW5pc20g
Zm9yIGxlZ2FsIGNhbGxlcnMNCiAgICA+ICAgdGhhdCBmaW5kIHRoZWlyIGNhbGxzIGJsb2NrZWQu
DQogICAgPiANCiAgICA+IA0KICAgID4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug
Zm9yIHRoaXMgZHJhZnQgaXM6DQogICAgPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv
Yy9kcmFmdC1pZXRmLXNpcGNvcmUtcmVqZWN0ZWQvDQogICAgPiANCiAgICA+IFRoZXJlIGFyZSBh
bHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAgICA+IGh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNpcGNvcmUtcmVqZWN0ZWQtMDUNCiAgICA+IGh0dHBz
Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zaXBjb3JlLXJlamVj
dGVkLTA1DQogICAgPiANCiAgICA+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlz
IGF2YWlsYWJsZSBhdDoNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k
cmFmdC1pZXRmLXNpcGNvcmUtcmVqZWN0ZWQtMDUNCiAgICA+IA0KICAgID4gDQogICAgPiBQbGVh
c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt
ZSBvZiBzdWJtaXNzaW9uDQogICAgPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm
ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgID4gDQogICAgPiBJbnRlcm5l
dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAgPiBm
dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KICAgID4gDQogICAgPiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gc2lwY29yZSBt
YWlsaW5nIGxpc3QNCiAgICA+IHNpcGNvcmVAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KICAgIA0KICAgIA0KDQo=


From nobody Sun Mar 31 13:01:29 2019
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 0EF2E120033 for ; Sun, 31 Mar 2019 13:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.28
X-Spam-Level: 
X-Spam-Status: No, score=-0.28 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 fo_fFF5zMjVb for ; Sun, 31 Mar 2019 13:01:26 -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 E119912000E for ; Sun, 31 Mar 2019 13:01:26 -0700 (PDT)
Received: from mutabilis-2.local ([47.186.39.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2VK1Ohu094578 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 31 Mar 2019 15:01:25 -0500 (CDT) (envelope-from mahoney@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1554062486; bh=BD6boSHJle4zY6AvDZVXSNxv8A/e9ba006qnJiwQ5Jk=; h=To:From:Subject:Date; b=IPzP5VtHsWIcRhR+vBTjt0/jmfAZSOKc4m9FbSAATOn4AuGYMUxJmUPFH1EIkQn9J QHyd8sdyE0eYpJQUnJRldiE/pKCXzcDG64jhfxxQUnQgcelgOz2SpM1YiUPXGMqO90 Le9LoWLoWTf9WkfCyfeAbVo0zbnHBKUUBPk7frzU=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.39.7] claimed to be mutabilis-2.local
To: SIPCORE , Ben Campbell , Adam Roach 
From: "A. Jean Mahoney" 
Message-ID: <1ba2aa30-d789-763a-d442-5e16d517def0@nostrum.com>
Date: Sun, 31 Mar 2019 15:01:24 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [sipcore] Area Director for SIPCORE
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Mar 2019 20:01:28 -0000

Hi all,

The SIPCORE chairs would like to thank Ben Campbell for his hard work as 
SIPCORE's area director, and welcome Adam Roach as SIPCORE's new AD. You 
may remember Adam from when he was SIPCORE chair a couple of years back ;-)

A big thank you to both Ben and Adam!

Jean