From nobody Mon Feb 7 06:56:47 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9C93A07E1 for ; Mon, 7 Feb 2022 06:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 pM8gj4ihgQb2 for ; Mon, 7 Feb 2022 06:56:40 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 0C10B3A08C8 for ; Mon, 7 Feb 2022 06:56:39 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 217EaX4a019919; Mon, 7 Feb 2022 14:56:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=eUKK0eOw0RHbEvnTun2DlVVlIgCyOPXeM4vx3ZQd3QM=; b=GkjkOUU9GTEQjAFDGxDFWvPZv+/I+G4MYBekyAsE5Ucs4LTzcmYBsU+86+qbJCyUVWsN R7tODMXL/zqKabV0mJl3f7yYjLJWhLn2ip+9qDxaPZRN/HPTtH1+pcl0vyx2M19WTIcl To0eM5pKpRXYOmpNqtpWdAmrzAzcJOebCrOpCdoLvIioPNb3eDZ/WTVpzhlNG1GXc6Lk Y/i3QLUL7PAE9J0AwEDfSFOvE/D0KPliQTRkCX5jlW175b91/dfMfqfO7szZBVLuZD7L ac9N/8LF11LemTp8I0Qb+6dzTQEy93pkmilW0OMHlM2yo99/GQioIscqi9WphSkloimB 2g== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com (PPS) with ESMTPS id 3e2knjq6m1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Feb 2022 14:56:32 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 217EojP3009662; Mon, 7 Feb 2022 09:56:31 -0500 Received: from email.msg.corp.akamai.com ([172.27.91.20]) by prod-mail-ppoint1.akamai.com with ESMTP id 3e1nf2udvd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Feb 2022 09:56:30 -0500 Received: from USMA1EX-DAG1MB4.msg.corp.akamai.com (172.27.123.104) by usma1ex-dag4mb6.msg.corp.akamai.com (172.27.91.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.922.19; Mon, 7 Feb 2022 09:56:30 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Mon, 7 Feb 2022 09:56:30 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.028; Mon, 7 Feb 2022 09:56:30 -0500 From: "Salz, Rich" To: "Salz, Rich" , "httpapi@ietf.org" CC: Francesca Palombini Thread-Topic: [httpapi] Linkset draft: move from informational to proposed standard? Thread-Index: AQHYHDLjGuKh+/n/uE2ke2jD3dyAKw== Date: Mon, 7 Feb 2022 14:56:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.58.22020202 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.118.139] Content-Type: multipart/alternative; boundary="_000_AE488BFCA36B49C694B539F97E8B5EE3akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-02-07_05:2022-02-07, 2022-02-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 adultscore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202070095 X-Proofpoint-ORIG-GUID: BFoKm_nRNLcwAeG4XqgkEp9Dp5InLrLJ X-Proofpoint-GUID: BFoKm_nRNLcwAeG4XqgkEp9Dp5InLrLJ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-07_05,2022-02-07_02,2021-12-02_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 adultscore=0 spamscore=0 priorityscore=1501 suspectscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1015 phishscore=0 malwarescore=0 impostorscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202070096 Archived-At: Subject: Re: [httpapi] Linkset draft: move from informational to proposed standard? X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2022 14:56:44 -0000 --_000_AE488BFCA36B49C694B539F97E8B5EE3akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8gZGlzYWdyZWVtZW50Lg0KDQpMaW5rc2V0IGlzIG5vdyDigJxwcm9wb3NlZCBzdGFuZGFyZOKA nSBhbmQgb3VyIGRlZmF1bHQgcG9saWNpZXMgaXMgbm90IGNoYW5nZWQuDQoNClRoYW5rcyBldmVy eW9uZS4NCg0KRnJvbTogIlNhbHosIFJpY2giIDxyc2Fsej00MGFrYW1haS5jb21AZG1hcmMuaWV0 Zi5vcmc+DQpEYXRlOiBNb25kYXksIEphbnVhcnkgMzEsIDIwMjIgYXQgMTA6MDUgQU0NClRvOiAi aHR0cGFwaUBpZXRmLm9yZyIgPGh0dHBhcGlAaWV0Zi5vcmc+DQpDYzogRnJhbmNlc2NhIFBhbG9t YmluaSA8ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20+DQpTdWJqZWN0OiBSZTogW2h0 dHBhcGldIExpbmtzZXQgZHJhZnQ6IG1vdmUgZnJvbSBpbmZvcm1hdGlvbmFsIHRvIHByb3Bvc2Vk IHN0YW5kYXJkPw0KDQpEaXNjdXNzaW9uIG9uIHRoaXMgc2VlbXMgdG8gaGF2ZSBkaWVkIGRvd24u IFdlIGhhZCBzZXZlcmFsIGV4cGVyaWVuY2VkIG1lbWJlcnMgZ2l2ZSBvcGluaW9ucywgYW5kIHRo ZXkgYWxsIHNlZW0gdG8gYWdyZWU6DQoNCiAgKiAgIE9rYXkgZm9yIGxpbmtzZXQgdG8gbW92ZSB0 byBwcm9wb3NlZCBzdGFuZGFyZA0KICAqICAgTm90IG9rYXkgdG8gYXNzdW1lIGFsbCBuZXcgZHJh ZnRzIGFyZSBwcm9wb3NlZCBzdGFuZGFyZC4gT25lIG1ham9yIHJlYXNvbiBjaXRlZCBmb3IgdGhl IGFzc3VtcHRpb24gaXMgdGhhdCB0aGUgSUVURiBkb2VzIG5vdCB3YW50IHRvIGNyZWF0ZSBhIHN0 YW5kYXJkIHRoYXQgaXMgbm90IGltcGxlbWVudGVkLg0KDQpJZiB5b3UgZGlzYWdyZWUgd2l0aCB0 aGlzLCBwbGVhc2Ugc3BlYWsgcG9zdCB3aXRoaW4gYSBmZXcgZGF5cy4NCg0KRnJvbTogUmljaCBT YWx6IDxyc2FsekBha2FtYWkuY29tPg0KRGF0ZTogRnJpZGF5LCBKYW51YXJ5IDIxLCAyMDIyIGF0 IDM6NDggUE0NClRvOiAiaHR0cGFwaUBpZXRmLm9yZyIgPGh0dHBhcGlAaWV0Zi5vcmc+DQpDYzog RnJhbmNlc2NhIFBhbG9tYmluaSA8ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20+DQpT dWJqZWN0OiBMaW5rc2V0IGRyYWZ0OiBtb3ZlIGZyb20gaW5mb3JtYXRpb25hbCB0byBwcm9wb3Nl ZCBzdGFuZGFyZD8NCg0KT25lIG9mIHRoZSBhcmVhIHJldmlld2VycyBxdWVzdGlvbmVkIHdoeSB0 aGUgbGlua3NldCBkb2N1bWVudCBpcyBpbmZvcm1hdGlvbmFsIHJhdGhlciB0aGFuIHByb3Bvc2Vk IHN0YW5kYXJkLiAgVGhlIGRvYyBhdXRob3JzIGFuZCB0aGUgY2hhaXJzIGhhZCBzb21lIG9mZi1s aW5lIGRpc2N1c3Npb24gYWJvdXQgdGhpcywgYW5kIHdlIHNob3VsZCBicmluZyB0aGlzIG9uZSB0 byB0aGUgZ3JvdXAuDQoNClRoZSBkaWZmZXJlbmNlIGFtb25nIHRoZSBzdGFuZGFyZHMgdHlwZXMg Y2FuIGJlIG9wYXF1ZSB0byBtYW55LCBpbmNsdWRpbmcgdGhvc2UgYWN0aXZlIG9uIGRvY3VtZW50 cy4gIDopICBUaGUgb2ZmaWNpYWwgZGVmaW5pdGlvbiBpcyBmb3VuZCBpbiBSRkMgMjAyNiBbMV0s IGJ1dCB0aGF0IGRvY3VtZW50IGhhcyBiZWVuIHVwZGF0ZWQgYnkgYWJvdXQgYSBkb3plbiBSRkPi gJlzIHNpbmNlIHRoZW4uIFRoZSB0d28gdGhhdCBhcmUgbW9zdCBhcHBsaWNhYmxlIGhlcmUgYXJl IFJGQyA2NDEwIFsyXSBhbmQgUkZDIDcxMjcgWzNdLg0KSSBkb27igJl0IGV4cGVjdCB5b3UgdG8g cmVhZCB0aGVtISBFdmVuIHRoZSBiaWdnZXN0IElFVEYgbmVyZC1oZWFkcyBhcmVu4oCZdCBmYW1p bGlhciB3aXRoIGFsbCB0aGVpciBub29rcyBhbmQgY3Jhbm5pZXMuIERhcnJlbCBwb2ludHMgb3V0 IGFuIGV4Y2VycHQgb2YgMjAyNiB0aGF0IChhbHRob3VnaCBhIGJpdCBvdXRkYXRlZCksIHN0aWxs IG1vc3RseSBob2xkczsgaXQgY2FuIGJlIGZvdW5kIGF0IFs0XSwgYW5kIGp1c3QgaWdub3JlIHRo ZSB0aXRsZS4gSSByZWNvbW1lbmQgWzNdIGdpdmVzIHRoZSBtb3N0IHZhbGlkIGNvbnRlbnQgcGVy IGJ5dGUgb2YgYW55IG9mIHRoZSBsaW5rcyBiZWxvdy4gOikNCg0KSXTigJlzIGltcG9ydGFudCB0 byBrbm93IHRoYXQgd2hhdCB3b3JraW5nIGdyb3VwcyBwcm9kdWNlIGFyZSDigJxwcm9wb3NlZCBz dGFuZGFyZHPigJ0gIExhdGVyIG9uIHRoZSB3b3JraW5nIGdyb3VwIGNhbiBhc2sgdGhlIElFU0cg dG8gdGFrZSBhIOKAnHN0YW5kYXJkcyBhY3Rpb27igJ0gdG8gbW92ZSBpdCB0aHJvdWdoIHRoZSBw aGFzZXMgb2YgRHJhZnQgU3RhbmRhcmQgYW5kIGV2ZW50dWFsbHkgdG8gSW50ZXJuZXQgU3RhbmRh cmQuIE9mdGVuLCBob3dldmVyLCBQcm9wb3NlZCBTdGFuZGFyZCBpcyBnb29kIGVub3VnaC4gSeKA mWxsIHBvaW50IG91dCB0aGF0IFRMUyBuZXZlciBiZWVuIHByb21vdGVkIHRvIGFuIEludGVybmV0 IFN0YW5kYXJkLiBNeSBzdWdnZXN0aW9uIHRvIHRoZSB3b3JraW5nIGdyb3VwIGlzIGRvbuKAmXQg d29ycnkgYWJvdXQgaXQuIFlvdSBjYW4gZmluZCB0aGUgbGlzdCBvZiBzdGFuZGFyZHMsIGRyYWZ0 IHN0YW5kYXJkcywgYW5kIHByb3Bvc2VkIHN0YW5kYXJkcyBhdCBbNV0uDQoNCldoYXQgd2UgZG8g aGVyZSBpcyBub3QgaW50ZW5kZWQgdG8gYmUganVzdCBkb2N1bWVudGVkIGZvciBwb3N0ZXJpdHks IGJ1dCBpcyBkZXNpZ25lZCB0byBiZSBpbXBsZW1lbnRlZCwgaW50ZXJvcGVyYWJsZSwgYW5kIGhv cGVmdWxseSBhY2hpZXZlIGNvbW1vbiBkZXBsb3ltZW50IGFuZCBoYXMgbm8gZXhwbGljaXQgY3Jp dGVyaWEgdG8gbWVhc3VyZSBzdWNjZXNzIG9yIGZhaWx1cmUuIEJ5IHRob3NlIGNyaXRlcmlhLCB3 aGljaCBoYXBwZW4gdG8gbWF0Y2ggdGhlIGxpc3QgaW4gWzFdLCBbNF0uICBQdXQgbm9hdGhlciB3 YXk6IOKAnFtUaGlzXSBzcGVjaWZpY2F0aW9uIGlzIHN0YWJsZSwgaGFzIHJlc29sdmVkIGtub3du IGRlc2lnbiBjaG9pY2VzLCBoYXMgcmVjZWl2ZWQgc2lnbmlmaWNhbnQgY29tbXVuaXR5IHJldmll dywgYW5kIGFwcGVhcnMgdG8gZW5qb3kgZW5vdWdoIGNvbW11bml0eSBpbnRlcmVzdCB0byBiZSBj b25zaWRlcmVkIHZhbHVhYmxlLuKAnSBbM10uDQoNClRoZXJlIGFyZSB0d28gcXVlc3Rpb25zIEni gJlkIGxpa2UgdGhlIFdHIHRvIGNvbnNpZGVyOg0KDQoNCiAgKiAgIEEuIFNob3VsZCB0aGUg4oCc bGlua3NldOKAnSBkcmFmdCBiZSBhIFByb3Bvc2VkIFN0YW5kYXJkPw0KICAqICAgQi4gU2hvdWxk IHdlIGFzc3VtZSBldmVyeXRoaW5nIHdlIGRvIGlzIFByb3Bvc2VkIFN0YW5kYXJkIHVubGVzcyBv dGhlcndpc2UgZGlzY3Vzc2VkPw0KDQpQbGVhc2UgcG9zdCB5b3VyIHRob3VnaHRzIGFib3V0IEEg YW5kL29yIEIgd2l0aGluIHRoZSBuZXh0IHR3byB3ZWVrcy4NCg0KVGhhbmsgeW91IQ0KDQpbMV0g aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMyMDI2PGh0dHBzOi8vdXJsZGVmZW5z ZS5jb20vdjMvX19odHRwczovd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMjAyNl9fOyEhR2p2 VHpfdmshRE1rc3RuTHFVZHF0UWNGTXlsNzVKZ1hJS2pValFKalA3ay10bEdkbjNTWFd1c2ZDQjlQ N3dKS0JQM04yJD4NClsyXSBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzY0MTA8 aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cucmZjLWVkaXRvci5vcmcvaW5m by9yZmM2NDEwX187ISFHanZUel92ayFETWtzdG5McVVkcXRRY0ZNeWw3NUpnWElLalVqUUpqUDdr LXRsR2RuM1NYV3VzZkNCOVA3d1BNSmZELWwkPg0KWzNdIGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL2luZm8vcmZjNzEyNzxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5y ZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzcxMjdfXzshIUdqdlR6X3ZrIURNa3N0bkxxVWRxdFFjRk15 bDc1SmdYSUtqVWpRSmpQN2stdGxHZG4zU1hXdXNmQ0I5UDd3UEpodDI4QiQ+DQpbNF0gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvc3RhbmRhcmRzL3Byb2Nlc3MvaW5mb3JtYXRpb25hbC12cy1leHBlcmlt ZW50YWwvPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL3N0 YW5kYXJkcy9wcm9jZXNzL2luZm9ybWF0aW9uYWwtdnMtZXhwZXJpbWVudGFsL19fOyEhR2p2VHpf dmshRE1rc3RuTHFVZHF0UWNGTXlsNzVKZ1hJS2pValFKalA3ay10bEdkbjNTWFd1c2ZDQjlQN3dL MHF6OHAyJD4NCls1XSBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9zdGFuZGFyZHM8aHR0cHM6 Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cucmZjLWVkaXRvci5vcmcvc3RhbmRhcmRz X187ISFHanZUel92ayFETWtzdG5McVVkcXRRY0ZNeWw3NUpnWElLalVqUUpqUDdrLXRsR2RuM1NY V3VzZkNCOVA3d0RKWHk3Ym0kPg0KDQo= --_000_AE488BFCA36B49C694B539F97E8B5EE3akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <8E5AFC1ABEDB9A48A392F49897CB99D5@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMzEwMjQxMjA7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xODE0Mjk1 MDI0IC0yODgzMzEyODAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC1zdGFydC1hdDozOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlz dC1pZDo3OTgyNTg1ODI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzMxMjgyMzk2O30NCkBs aXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTcyODQ1ODkyNzsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6LTEzOTc0ODQ4MTg7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDox OTcyNzg3ODM0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czoxOTE4Njg0MzQ4IC01NDM0MTg0MTIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDM6bGV2ZWwx DQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDouNzVpbjsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1s ZWZ0OjEuMjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MS43NWluOw0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIuMjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6Mi43NWluOw0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozLjI1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu LWxlZnQ6My43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo0LjI1aW47DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjQuNzVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk5vIGRpc2FncmVlbWVudC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkxpbmtzZXQgaXMgbm93IOKAnHByb3Bvc2VkIHN0 YW5kYXJk4oCdIGFuZCBvdXIgZGVmYXVsdCBwb2xpY2llcyBpcyBub3QgY2hhbmdlZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyBldmVyeW9uZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+JnF1b3Q7 U2FseiwgUmljaCZxdW90OyAmbHQ7cnNhbHo9NDBha2FtYWkuY29tQGRtYXJjLmlldGYub3JnJmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIEphbnVhcnkgMzEsIDIwMjIgYXQgMTA6MDUgQU08 YnI+DQo8Yj5UbzogPC9iPiZxdW90O2h0dHBhcGlAaWV0Zi5vcmcmcXVvdDsgJmx0O2h0dHBhcGlA aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5GcmFuY2VzY2EgUGFsb21iaW5pICZsdDtmcmFu Y2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6 IFtodHRwYXBpXSBMaW5rc2V0IGRyYWZ0OiBtb3ZlIGZyb20gaW5mb3JtYXRpb25hbCB0byBwcm9w b3NlZCBzdGFuZGFyZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+RGlzY3Vzc2lvbiBvbiB0aGlzIHNlZW1zIHRvIGhhdmUg ZGllZCBkb3duLiBXZSBoYWQgc2V2ZXJhbCBleHBlcmllbmNlZCBtZW1iZXJzIGdpdmUgb3Bpbmlv bnMsIGFuZCB0aGV5IGFsbCBzZWVtIHRvIGFncmVlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1 bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxm bzMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Pa2F5IGZvciBsaW5rc2V0IHRvIG1v dmUgdG8gcHJvcG9zZWQgc3RhbmRhcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWluO21zby1saXN0OmwzIGxl dmVsMSBsZm8zIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Tm90IG9rYXkgdG8gYXNz dW1lIGFsbCBuZXcgZHJhZnRzIGFyZSBwcm9wb3NlZCBzdGFuZGFyZC4gT25lIG1ham9yIHJlYXNv biBjaXRlZCBmb3IgdGhlIGFzc3VtcHRpb24gaXMgdGhhdCB0aGUgSUVURiBkb2VzIG5vdCB3YW50 IHRvIGNyZWF0ZSBhIHN0YW5kYXJkDQogdGhhdCBpcyBub3QgaW1wbGVtZW50ZWQuPG86cD48L286 cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JZiB5b3UgZGlzYWdyZWUg d2l0aCB0aGlzLCBwbGVhc2Ugc3BlYWsgcG9zdCB3aXRoaW4gYSBmZXcgZGF5cy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UmljaCBTYWx6ICZs dDtyc2FsekBha2FtYWkuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEphbnVhcnkg MjEsIDIwMjIgYXQgMzo0OCBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7aHR0cGFwaUBpZXRmLm9y ZyZxdW90OyAmbHQ7aHR0cGFwaUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPkZyYW5jZXNj YSBQYWxvbWJpbmkgJmx0O2ZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tJmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5MaW5rc2V0IGRyYWZ0OiBtb3ZlIGZyb20gaW5mb3JtYXRpb25hbCB0 byBwcm9wb3NlZCBzdGFuZGFyZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+T25lIG9mIHRoZSBhcmVhIHJldmlld2VycyBx dWVzdGlvbmVkIHdoeSB0aGUgbGlua3NldCBkb2N1bWVudCBpcyBpbmZvcm1hdGlvbmFsIHJhdGhl ciB0aGFuIHByb3Bvc2VkIHN0YW5kYXJkLiZuYnNwOyBUaGUgZG9jIGF1dGhvcnMgYW5kIHRoZSBj aGFpcnMgaGFkIHNvbWUgb2ZmLWxpbmUgZGlzY3Vzc2lvbiBhYm91dCB0aGlzLCBhbmQgd2Ugc2hv dWxkIGJyaW5nIHRoaXMNCiBvbmUgdG8gdGhlIGdyb3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIGRpZmZlcmVuY2UgYW1vbmcgdGhlIHN0YW5kYXJkcyB0 eXBlcyBjYW4gYmUgb3BhcXVlIHRvIG1hbnksIGluY2x1ZGluZyB0aG9zZSBhY3RpdmUgb24gZG9j dW1lbnRzLiZuYnNwOyA6KSZuYnNwOyBUaGUgb2ZmaWNpYWwgZGVmaW5pdGlvbiBpcyBmb3VuZCBp biBSRkMgMjAyNiBbMV0sIGJ1dCB0aGF0IGRvY3VtZW50IGhhcyBiZWVuIHVwZGF0ZWQgYnkgYWJv dXQgYSBkb3plbg0KIFJGQ+KAmXMgc2luY2UgdGhlbi4gVGhlIHR3byB0aGF0IGFyZSBtb3N0IGFw cGxpY2FibGUgaGVyZSBhcmUgUkZDIDY0MTAgWzJdIGFuZCBSRkMgNzEyNyBbM10uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPkkgZG9u4oCZdCBleHBlY3QgeW91IHRvIHJlYWQgdGhlbSEgRXZlbiB0aGUgYmln Z2VzdCBJRVRGIG5lcmQtaGVhZHMgYXJlbuKAmXQgZmFtaWxpYXIgd2l0aCBhbGwgdGhlaXIgbm9v a3MgYW5kIGNyYW5uaWVzLiBEYXJyZWwgcG9pbnRzIG91dCBhbiBleGNlcnB0IG9mIDIwMjYgdGhh dCAoYWx0aG91Z2ggYSBiaXQgb3V0ZGF0ZWQpLCBzdGlsbCBtb3N0bHkgaG9sZHM7DQogaXQgY2Fu IGJlIGZvdW5kIGF0IFs0XSwgYW5kIGp1c3QgaWdub3JlIHRoZSB0aXRsZS4gSSByZWNvbW1lbmQg WzNdIGdpdmVzIHRoZSBtb3N0IHZhbGlkIGNvbnRlbnQgcGVyIGJ5dGUgb2YgYW55IG9mIHRoZSBs aW5rcyBiZWxvdy4gOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi Pkl04oCZcyBpbXBvcnRhbnQgdG8ga25vdyB0aGF0IHdoYXQgd29ya2luZyBncm91cHMgcHJvZHVj ZSBhcmUg4oCccHJvcG9zZWQgc3RhbmRhcmRz4oCdJm5ic3A7IExhdGVyIG9uIHRoZSB3b3JraW5n IGdyb3VwIGNhbiBhc2sgdGhlIElFU0cgdG8gdGFrZSBhIOKAnHN0YW5kYXJkcyBhY3Rpb27igJ0g dG8gbW92ZSBpdCB0aHJvdWdoIHRoZSBwaGFzZXMgb2YgRHJhZnQgU3RhbmRhcmQgYW5kDQogZXZl bnR1YWxseSB0byBJbnRlcm5ldCBTdGFuZGFyZC4gT2Z0ZW4sIGhvd2V2ZXIsIFByb3Bvc2VkIFN0 YW5kYXJkIGlzIGdvb2QgZW5vdWdoLiBJ4oCZbGwgcG9pbnQgb3V0IHRoYXQgVExTIG5ldmVyIGJl ZW4gcHJvbW90ZWQgdG8gYW4gSW50ZXJuZXQgU3RhbmRhcmQuIE15IHN1Z2dlc3Rpb24gdG8gdGhl IHdvcmtpbmcgZ3JvdXAgaXMgZG9u4oCZdCB3b3JyeSBhYm91dCBpdC4gWW91IGNhbiBmaW5kIHRo ZSBsaXN0IG9mIHN0YW5kYXJkcywgZHJhZnQgc3RhbmRhcmRzLA0KIGFuZCBwcm9wb3NlZCBzdGFu ZGFyZHMgYXQgWzVdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ V2hhdCB3ZSBkbyBoZXJlIGlzIG5vdCBpbnRlbmRlZCB0byBiZSBqdXN0IGRvY3VtZW50ZWQgZm9y IHBvc3Rlcml0eSwgYnV0IGlzIGRlc2lnbmVkIHRvIGJlIGltcGxlbWVudGVkLCBpbnRlcm9wZXJh YmxlLCBhbmQgaG9wZWZ1bGx5IGFjaGlldmUgY29tbW9uIGRlcGxveW1lbnQgYW5kIGhhcyBubyBl eHBsaWNpdCBjcml0ZXJpYSB0byBtZWFzdXJlIHN1Y2Nlc3MNCiBvciBmYWlsdXJlLiBCeSB0aG9z ZSBjcml0ZXJpYSwgd2hpY2ggaGFwcGVuIHRvIG1hdGNoIHRoZSBsaXN0IGluIFsxXSwgWzRdLiZu YnNwOyBQdXQgbm9hdGhlciB3YXk6IOKAnFtUaGlzXSBzcGVjaWZpY2F0aW9uIGlzIHN0YWJsZSwg aGFzIHJlc29sdmVkIGtub3duIGRlc2lnbiBjaG9pY2VzLCBoYXMgcmVjZWl2ZWQgc2lnbmlmaWNh bnQgY29tbXVuaXR5IHJldmlldywgYW5kIGFwcGVhcnMgdG8gZW5qb3kgZW5vdWdoIGNvbW11bml0 eSBpbnRlcmVzdCB0byBiZQ0KIGNvbnNpZGVyZWQgdmFsdWFibGUu4oCdIFszXS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZXJlIGFyZSB0d28gcXVlc3Rpb25z IEnigJlkIGxpa2UgdGhlIFdHIHRvIGNvbnNpZGVyOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJk aXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvNiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PkEuIFNob3VsZCB0aGUg4oCcbGlua3NldOKAnSBkcmFmdCBiZSBhIFByb3Bvc2VkIFN0YW5kYXJk PzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm82Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+Qi4gU2hvdWxkIHdlIGFzc3VtZSBldmVyeXRoaW5nIHdlIGRvIGlz IFByb3Bvc2VkIFN0YW5kYXJkIHVubGVzcyBvdGhlcndpc2UgZGlzY3Vzc2VkPzxvOnA+PC9vOnA+ PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGxlYXNlIHBvc3QgeW91ciB0 aG91Z2h0cyBhYm91dCBBIGFuZC9vciBCIHdpdGhpbiB0aGUgbmV4dCB0d28gd2Vla3MuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFuayB5b3UhPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5bMV0gPGEgaHJlZj0iaHR0cHM6Ly91 cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMyMDI2 X187ISFHanZUel92ayFETWtzdG5McVVkcXRRY0ZNeWw3NUpnWElLalVqUUpqUDdrLXRsR2RuM1NY V3VzZkNCOVA3d0pLQlAzTjIkIj4NCmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZj MjAyNjwvYT4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlsyXSA8YSBocmVmPSJodHRwczovL3VybGRlZmVu c2UuY29tL3YzL19faHR0cHM6L3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzY0MTBfXzshIUdq dlR6X3ZrIURNa3N0bkxxVWRxdFFjRk15bDc1SmdYSUtqVWpRSmpQN2stdGxHZG4zU1hXdXNmQ0I5 UDd3UE1KZkQtbCQiPg0KaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM2NDEwPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5bM10gPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92 My9fX2h0dHBzOi93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3MTI3X187ISFHanZUel92ayFE TWtzdG5McVVkcXRRY0ZNeWw3NUpnWElLalVqUUpqUDdrLXRsR2RuM1NYV3VzZkNCOVA3d1BKaHQy OEIkIj4NCmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzEyNzwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+WzRdIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRw czovd3d3LmlldGYub3JnL3N0YW5kYXJkcy9wcm9jZXNzL2luZm9ybWF0aW9uYWwtdnMtZXhwZXJp bWVudGFsL19fOyEhR2p2VHpfdmshRE1rc3RuTHFVZHF0UWNGTXlsNzVKZ1hJS2pValFKalA3ay10 bEdkbjNTWFd1c2ZDQjlQN3dLMHF6OHAyJCI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9zdGFuZGFy ZHMvcHJvY2Vzcy9pbmZvcm1hdGlvbmFsLXZzLWV4cGVyaW1lbnRhbC88L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPls1XSA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3 dy5yZmMtZWRpdG9yLm9yZy9zdGFuZGFyZHNfXzshIUdqdlR6X3ZrIURNa3N0bkxxVWRxdFFjRk15 bDc1SmdYSUtqVWpRSmpQN2stdGxHZG4zU1hXdXNmQ0I5UDd3REpYeTdibSQiPg0KaHR0cHM6Ly93 d3cucmZjLWVkaXRvci5vcmcvc3RhbmRhcmRzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AE488BFCA36B49C694B539F97E8B5EE3akamaicom_-- From nobody Mon Feb 7 15:54:28 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1613A105B for ; Mon, 7 Feb 2022 15:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=LPg+j+pk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ROdka00V 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 KLOzbVV43SuX for ; Mon, 7 Feb 2022 15:54:22 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2163A0EE7 for ; Mon, 7 Feb 2022 15:54:22 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id CF1985C0194 for ; Mon, 7 Feb 2022 18:54:21 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 07 Feb 2022 18:54:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm1; bh=aFk29MJ9gu5x7CI/6jyyW0+FXoX3iX67FrqARW Pk9S8=; b=LPg+j+pkheJeMemqRCKZ0z1/gCnZJFtqodnmKTXqXjmjRYnd9tq87y jGndFx/2dJBbu/Xke3lBkijnfIbRG6TZw8B7XjhzmvQXPh6vJPee1l8MmtNjW8ge 6fWgKC9pyqAlicc++VpCot3mx7aEARggQYzmXh7EEL/mgdImaZa+dYv7i+qShe0A kUpgMc689U+lK/K/OQa433oIM+DVHLwPEwVIh58i+lz2MVW9b4c1BO3AR1OF7UYT jZ4uYfinSJ75oY8rQMyVxXyxYCPOnBvYOwxIwCuxrRai1Ii3w3m3ABnIy9pMFwCQ Arh2XBvjHAZiHBKW/1r3Ezmc/4hF2uwQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=aFk29MJ9gu5x7CI/6 jyyW0+FXoX3iX67FrqARWPk9S8=; b=ROdka00VVQK2eunGV6FSaYY2t7pndDmst pSi3kN8KJFLHns6MKqOeIApQWGgmnCOqZ8UwiWdBjJjQ+tDt1ixOhoKFCvrH86cb Ygdw0AlKtMT5ihu9rdhSBtP8GaOu2wYlvLnqF+wh3S3ztDyf6sZ66f0ywIvsAfHQ /OV5xgv+wqVbshKw9e4j7zH/hHE/HzdzoO4VBbUzX4b3p476xaRdyLOe163Q0hmc U4kbN1JQrRTfZXW0msjaSpImrJ8pd5pImPfTmkGxIA7s8ZShU80/Er4ZzWXYqyqU /EcPatMASF23x1Fbs0GV8X4lOB2FqqltbdJdBKxvpzTBoMoS7QC4w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrheeigddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhtgfgggfukfffvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcupfho thhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnh epjeehleelueekhffhkeehjeejuddvjeegtdduieduieejjefguefhtddutdejgfdtnecu ffhomhgrihhnpehgihhthhhusgdrtghomhdphhhtthhpshgvmhgrnhhtihgtshdrshhopd hmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 7 Feb 2022 18:54:20 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Message-Id: Date: Tue, 8 Feb 2022 10:54:18 +1100 To: HTTP APIs Working Group X-Mailer: Apple Mail (2.3693.60.0.1.1) Archived-At: Subject: [httpapi] Multiple Problems in RFC7807bis X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2022 23:54:28 -0000 Hi everyone, We've been discussing how to talk about conveying multiple problems in = RFC7807bis here: https://github.com/ietf-wg-httpapi/rfc7807bis/issues/6 Towards the end of that conversation (as of now), we seem to be = converging on how to do this. Copying my comments from there: ~~~ We currently: =E2=80=A2 Describe how to design extensions to accommodate = multiple instances of the same type =E2=80=A2 Describe how to use 207 Multi-Status to convey = multiple problems with different types/status codes =E2=80=A2 Do not describe how one might convey multiple problems = with different types but the same status code. I think (1) is fine and good. Right now, (2) seems like it's recommending the pattern, but doesn't = define an actual type for use in that situation. That's not great. If = we're going to show that pattern, we should probably define the type for = use in that situation (especially since we have a registry now). = However, I have serious doubts about the wisdom of recommending that = pattern, and feel like we should either remove that text, or at least = heavily contextualise it. Regarding (3) -- again, if we want to document that, we should define a = type. I tend to think we shouldn't, though. If we retract (2) and don't attempt (3), we might want to add some text = along the lines of: When an API encounters multiple problems that do not share the same = type, it is RECOMMENDED that the most relevant or urgent problem be = represented in the response. While it is possible to create generic = "batch" problem types that convey multiple, disparate types, they do not = map well into HTTP semantics. ~~~ So far, there seems to be support for removing (2) and adding text = similar to that proposed. What do people think?=20 Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Feb 8 08:26:27 2022 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1E43A0C0D; Tue, 8 Feb 2022 08:26:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: httpapi@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: httpapi@ietf.org Message-ID: <164433757713.27235.18360157893914327848@ietfa.amsl.com> Date: Tue, 08 Feb 2022 08:26:17 -0800 Archived-At: Subject: [httpapi] I-D Action: draft-ietf-httpapi-linkset-07.txt X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2022 16:26:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Building Blocks for HTTP APIs WG of the IETF. Title : Linkset: Media Types and a Link Relation Type for Link Sets Authors : Erik Wilde Herbert Van de Sompel Filename : draft-ietf-httpapi-linkset-07.txt Pages : 34 Date : 2022-02-08 Abstract: This specification defines two formats and respective media types for representing sets of links as stand-alone documents. One format is JSON-based, the other aligned with the format for representing links in the HTTP "Link" header field. This specification also introduces a link relation type to support discovery of sets of links. Note to Readers Please discuss this draft on the "Building Blocks for HTTP APIs" mailing list (https://www.ietf.org/mailman/listinfo/httpapi). Online access to all versions and files is available on GitHub (https://github.com/ietf-wg-httpapi/linkset). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpapi-linkset/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-httpapi-linkset-07.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-httpapi-linkset-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Feb 8 09:04:28 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409B13A0C61 for ; Tue, 8 Feb 2022 09:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gs1.org 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 8QL_KFtxnTan for ; Tue, 8 Feb 2022 09:04:21 -0800 (PST) Received: from eu-smtp-delivery-175.mimecast.com (eu-smtp-delivery-175.mimecast.com [185.58.86.175]) (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 127043A0C42 for ; Tue, 8 Feb 2022 09:04:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gs1.org; s=mimecast20200207; t=1644339858; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dG9XHRN6kKUDv24eZhs3rDUa4uKFCfhtKA+gUrpMI8w=; b=Qh5kV4ASx9nP4wgPQKk6XyStwUDzfT/IQiQEiJ4Dq87/Quy6FynzZRZx1g0kYL56fPDdrJ naGCXhvZVQOCVMg7g8yJ5QdTtvj3DSsANiw9FyM80hnOOAggXABYHHSYiSmU0IgP5vdXYI xAj5NK4e2BYDwJDzDUdlwVermmMhBvk1nY27BXLr9tkTizhDoR/Cyw8KrJif2tZk4o5kiA 3V7rjsE6157KE+hq3kGobeD+mECw1QzdMQZS/13DRBd0PmJd3iIU9/C8JGLs0syF6Bqkmm NjpfsYr0RJwSpFAwUv421NopAoF+nfdSWojl8lb2NouCk74Gbp+LV6HP29o2CQ== Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2103.outbound.protection.outlook.com [104.47.58.103]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id uk-mta-283-iDFuJ5M2Mwm6qBI4FMC3Gg-1; Tue, 08 Feb 2022 17:04:16 +0000 Received: from PH0PR08MB7225.namprd08.prod.outlook.com (2603:10b6:510:93::24) by CY4PR08MB2677.namprd08.prod.outlook.com (2603:10b6:903:fe::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12; Tue, 8 Feb 2022 17:04:13 +0000 Received: from PH0PR08MB7225.namprd08.prod.outlook.com ([fe80::80e8:ac22:95f1:c006]) by PH0PR08MB7225.namprd08.prod.outlook.com ([fe80::80e8:ac22:95f1:c006%4]) with mapi id 15.20.4951.019; Tue, 8 Feb 2022 17:04:12 +0000 From: Phil Archer To: "httpapi@ietf.org" Thread-Topic: [httpapi] I-D Action: draft-ietf-httpapi-linkset-07.txt Thread-Index: AQHYHQil860T6khnKEu8wVZJmU+LhKyJ4Ajw Date: Tue, 8 Feb 2022 17:04:11 +0000 Message-ID: References: <164433757713.27235.18360157893914327848@ietfa.amsl.com> In-Reply-To: <164433757713.27235.18360157893914327848@ietfa.amsl.com> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 32edea9f-131c-48e0-e058-08d9eb25076c x-ms-traffictypediagnostic: CY4PR08MB2677:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: W0rFpmYbqxXnMNlrdSqpRgsed5NV0GNk8tU3v24LoGJihu+YKEMJ4ltT9KtgBQ4AsJph4XBrJQMfw4nyup1wcQjXThczwceW3kA9djXyFqYRXEIaOeYbTMGhx7iQfg1wlSBkFVc9ovV7oloFN667SdC1h/xr0Z92pUpU8OWy6ozNyChRBO4DQSdya9RFodUaOwDbaSiBPViX2lvtkYZK9dJyeVV2QzRPF+o+g2MTupdoHfkydRRnes9yS+8s250VUgKxQB7h4WCaYsG2djFXwkbOxld0KffumIN31jXneZm9b6En0OKezEMRKyT8iTWXG8cxh2aZXEDTcNanndIpg+5qZcLOJSCmN4C3W/KE3I3MfC+GOp0PAEndnY2aPgKqhGA4PuKKyUxPLVptNdVKZIk60PcR1iGPGTYdlQMD/FNRmYyZGk4zfF7nJJhclb1N9/pdvDkbPPvRad/aMkviE2fx2qARJ+Bgwuy16pXwCYWo4F5kBitm+xCeRPXvo0LY4oJpTn+JRYswJPcJ2XMOm/LxUT9gq7PhTOnjCoVPwxib9DDxbHh9UQRmZjO4XaYUS9coe0hz6U1TxmMB4sxlT0NwqXM1I88ojfxWnYkyktQ0s4yhIktFbAa9X9LRZeSGs0bt9UX1bomgF0Ck7FSKq0xXKOM3HUyfkSRss6kfFFqEKYW3tM9ximsbqkJMCPetuG3NRi1NkTAMgGWWw4FNUJDASby8GEYX3H4xdUNyFrlB0wXiTmPCDVQXDSWGBBBd1OL7x4Rdz0OahxAEXaYUq4V4cDDBEJp/mQ7waNwhVNf+CXFMABn9LJpC25Rqr6XZ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR08MB7225.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(9686003)(122000001)(508600001)(66574015)(966005)(38100700002)(53546011)(5660300002)(38070700005)(55016003)(83380400001)(8936002)(64756008)(66946007)(8676002)(76116006)(66446008)(44832011)(6916009)(66556008)(186003)(6506007)(7696005)(33656002)(66476007)(71200400001)(86362001)(316002)(2906002)(52536014); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SkRrNTlNalNjWVhVUVo1SzE2YlVjWHpwdWd1YURsbkNGd0doQ0JrOU5kYXVX?= =?utf-8?B?OS9qb0hCcFRVTFFkekplb29CZ29yNkxKOWhNbmpNckczaUhLU0Jud2tJUERB?= =?utf-8?B?T3dDN2dnM3h3OWVpdXBQbnNKLzdtOVZZVWhITFRTTmZraGtMVHFVWUlXcjNp?= =?utf-8?B?b0pVcldEOUdOTHJINkZrdFVQbE9OZ2JkWXZwZW5KMnZmUkdCTDVKbHVEcm9z?= =?utf-8?B?cWZETzhRazVOL002R3B5cUJuMnBKZWtwUFBHd0dMMnFub3hEUlcxWHU3SWdY?= =?utf-8?B?OWRGY2NHenVtbUI5Yy9mVDAyd0REc0ZXZmtISGpYYzFJRitmUmpvZzk5WGFs?= =?utf-8?B?VUpDQys3WEVnZjdkM3ovSTkrdVZPc2ZWVmhGcUNnVEZobmg5c0lwVlRhOUZS?= =?utf-8?B?OC9PLy96MzRjNEhhU0ZaRWNjRnRydEZhOTFYTWVUeXN6WVo4RXFWWjJqUit2?= =?utf-8?B?V09GcEYrK3FibXlNOC9IRDM1R3FzcmdRZjJkRHdpUlFvcG9CQkNMSC8vNVBs?= =?utf-8?B?N0pkdHNxTFRjK01OYVZNaFp4TE9ocnhhRFdRWS9vY3RaL290aGZWbGpVVXZt?= =?utf-8?B?bTFVV2pzK3dVeHhxUGtyQlNsemdUeXR0RTRyNkdqQ0lySXdLMHZleXYzWm5D?= =?utf-8?B?cEdyVzZpQXRzMHR1M2Y4Z2xmbDJSNDd4Z2V6TGFOL0wySEtXOHJpbzBJYXVL?= =?utf-8?B?NEpscWo2VWJTNnRpQWVidThlMU12aDMrN092SmNNb1ZEY1VobW1aamtwKytH?= =?utf-8?B?OTFnQjY0enRyV25PZzBYcVBjMlI2OGdJTU1sYzNaTXBRQVdINlREOXgvNnNi?= =?utf-8?B?Z1RGenNabjZMTWZPMk82Vit4SWdTMDVWM2FhYjl3cVlqK1MwVVRKSmNaRWF3?= =?utf-8?B?cndETDIrSWpFaUpGczVMU1pLUVhVa2NlODVJVkVKdUxRK1FzREpzOU9OWUZG?= =?utf-8?B?dUs0VHl5bk9iQ2xQRkNvS2dqMG5xVXYzcVFKTWp0OHpmZ3RWbHFIeWZTTnBG?= =?utf-8?B?OVBhQVpYd2hLOWNqQXVQVVdLZjVQMURaN1dubWZWcGhqQjYrbVZEYnpIaDha?= =?utf-8?B?eHNUbFM1WmM0VFhydXQrNzNUaFFHWGpwLzB1L05ScC8vS0FjUlBKcFJhcVpE?= =?utf-8?B?VkYxUlhTcHBDSlJ3TUVsb0xWL0xKdUFZS0VWTjVJdUNwelhGS3VGSFg4M1I1?= =?utf-8?B?QzhUWjFyL3BGWXRhNzlVYnJoeEVacDhoL3NFK0hZQ1Y5OGUzckE0Wkt3SW9j?= =?utf-8?B?aDd6cnVPb0pLbHJMLzJ1aTFaWU5xUzBJVW5jZE5JYXZCcmZWLzRPbVEyMm4w?= =?utf-8?B?bDdVQ21VVjNSTW1Ld3pJUitibEtSUVVuQS9LbGcrVm1IdEJVbTBzVVZ3UW1a?= =?utf-8?B?N2V1dUNVekFRV3l5a0FKRFB4YUMycG9ka0wvZ2ZiNytQbUtIY0g2NnIvYUhI?= =?utf-8?B?a0d0eXE4RU92MTI0V2JkUXVpeFlOd0lqT2dZN25CNmtiMThkclpHeGd0SHdK?= =?utf-8?B?bHgwNVRsVTBhY2ZwWGR3SktJL2d1Mk9JWmNXaU5xcEQ0WHlWMWlhNkxUZWNp?= =?utf-8?B?OEVNM1RwcXFTc0crRzYwaUF6MDc1VDNHUm45enJXL0wrb3hOeERldTJ6d1dI?= =?utf-8?B?c2JWSzI1K1VyUnVpWlA4TDRmMEFiMGdyenNIdHo3eDZTRWJuSzhWLzdoaVNp?= =?utf-8?B?aVlkYmRHeUtCQ25lZCtKRjk1czNPTjM1d0YvT3g4bFN0SlAxaDFBMXQvMFlM?= =?utf-8?B?bjl0elJZUHllMnM5MGw1QVNvUE1PR3hHWlVTRFVUWC8rMkRCWHlCVDNsVy9v?= =?utf-8?B?bzJpc2hpUXVwQm1oT0wvNmhrSHFudFNidjRTRlgrNDFacXhmQmh4dUdFc2tv?= =?utf-8?B?OWV4aDdOSURoSkYrU2RVMWt4a2JBeEJDV0pqQ3B1dWhWOUhBQ3M5QXdXRzZ6?= =?utf-8?B?Q3hQSWQzM29UcXRuUkN5VW1GNC9mNVpYRk9mR2VNVE4vL2l4eWhFMWR2WkQ0?= =?utf-8?B?R2hsejF5NmVvYWJyRkFjdlo4Z0RWTVgrUXNXaWdCWVJ0bVNlMHBMUEwvM0k4?= =?utf-8?B?UWE4dDBrcElzUzMwbEM2bHZIOFRLWFJrMzZHL3R2OXdnOVVaUVJYYmlybFhY?= =?utf-8?B?YUV5aW9uZkxEVzAwNHRod1U4RU8zYVQ1N1NMbGRJc0IxMlZlNG9WN2ZVRzU1?= =?utf-8?B?SHhBMUhQS3JKcTFJd0Y1MFZQZU53TU1sWmx0blBrclVvMUI5bTB1cWpPSHVk?= =?utf-8?B?UWZLQTBTODArcVNlWkNiODcwM3NRPT0=?= x-mc-unique: iDFuJ5M2Mwm6qBI4FMC3Gg-1 x-originatororg: gs1.org x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: PH0PR08MB7225.namprd08.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 32edea9f-131c-48e0-e058-08d9eb25076c x-ms-exchange-crosstenant-originalarrivaltime: 08 Feb 2022 17:04:11.8978 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 3197754b-b3a7-45b5-b82c-c8bc62c25b58 x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: WzqIPwD+il5Q2WbkrH5FhA8ui82/EKUUoWi+pJYqpVw1LWF9abeeBMzQZhOusM8C3LnvZYt+7sM/4nEWS2O7KA== x-ms-exchange-transport-crosstenantheadersstamped: CY4PR08MB2677 MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUK75A19 smtp.mailfrom=phil.archer@gs1.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: gs1.org Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [httpapi] I-D Action: draft-ietf-httpapi-linkset-07.txt X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2022 17:04:26 -0000 R29vZCB0byBzZWUgdGhpcyBjb250aW51aW5nIGluIGl0cyBwcm9ncmVzcy4sIHRoYW5rIHlvdSB0 byBldmVyeW9uZSB3aG8gbWFkZSB0aGlzIGhhcHBlbi4NCg0KSnVzdCBhIGxpdHRsZSBuaXQgcGlj ay4gVGhlIHRvcCBvZiB0aGUgcGFnZSBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWh0dHBhcGktbGlua3NldC8gc3RhdGVzIHRoYXQsIGFzIHdlIGhhdmUgZGlz Y3Vzc2VkLCB0aGlzIGlzIGEgcHJvcG9zZWQgc3RhbmRhcmQuIEhvd2V2ZXIsIHRoZSBhY3R1YWwg ZG9jIHdpdGhpbiB0aGF0IHBhZ2UsIGFuZCB0aGUgSFRNTCB2ZXJzaW9uIGF0IGh0dHBzOi8vd3d3 LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaWV0Zi1odHRwYXBpLWxpbmtzZXQtMDcuaHRtbCwg c3RpbGwgc2hvd3MgdGhlIGludGVuZGVkIHN0YXR1cyBhcyBpbmZvcm1hdGlvbmFsLg0KDQpBbSBJ IG1pc3VuZGVyc3RhbmRpbmcgdGhpcyBvciBpcyB0aGVyZSBhbiBhY3R1YWwgKHNtYWxsLCBlbnRp cmVseSB1bmRlcnN0YW5kYWJsZSkgZXJyb3I/DQoNClBoaWwNCg0KUGhpbCBBcmNoZXINCldlYiBT b2x1dGlvbnMgRGlyZWN0b3IsIEdTMQ0KaHR0cHM6Ly93d3cuZ3MxLm9yZw0KDQpNZWV0IEdTMSBE aWdpdGFsIExpbmsgRGV2ZWxvcGVycyBhdA0KaHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9mb3J1 bS8jIWZvcnVtL2dzMS1kaWdpdGFsLWxpbmstZGV2ZWxvcGVycw0KDQpodHRwczovL3BoaWxhcmNo ZXIub3JnDQorNDQgKDApNzg4NyA3Njc3NTUNCkBwaGlsYXJjaGVyMQ0KU2t5cGU6IHBoaWxhcmNo ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGh0dHBhcGkgPGh0dHBhcGkt Ym91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0K U2VudDogMDggRmVicnVhcnkgMjAyMiAxNjoyNg0KVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0K Q2M6IGh0dHBhcGlAaWV0Zi5vcmcNClN1YmplY3Q6IFtodHRwYXBpXSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLWh0dHBhcGktbGlua3NldC0wNy50eHQNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMu DQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBCdWlsZGluZyBCbG9ja3MgZm9yIEhU VFAgQVBJcyBXRyBvZiB0aGUgSUVURi4NCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBMaW5r c2V0OiBNZWRpYSBUeXBlcyBhbmQgYSBMaW5rIFJlbGF0aW9uIFR5cGUgZm9yIExpbmsgU2V0cw0K ICAgICAgICBBdXRob3JzICAgICAgICAgOiBFcmlrIFdpbGRlDQogICAgICAgICAgICAgICAgICAg ICAgICAgIEhlcmJlcnQgVmFuIGRlIFNvbXBlbA0KICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBk cmFmdC1pZXRmLWh0dHBhcGktbGlua3NldC0wNy50eHQNCiAgICAgICAgUGFnZXMgICAgICAgICAg IDogMzQNCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAyMi0wMi0wOA0KDQpBYnN0cmFjdDoN CiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIHR3byBmb3JtYXRzIGFuZCByZXNwZWN0aXZl IG1lZGlhIHR5cGVzIGZvcg0KICAgcmVwcmVzZW50aW5nIHNldHMgb2YgbGlua3MgYXMgc3RhbmQt YWxvbmUgZG9jdW1lbnRzLiAgT25lIGZvcm1hdCBpcw0KICAgSlNPTi1iYXNlZCwgdGhlIG90aGVy IGFsaWduZWQgd2l0aCB0aGUgZm9ybWF0IGZvciByZXByZXNlbnRpbmcgbGlua3MNCiAgIGluIHRo ZSBIVFRQICJMaW5rIiBoZWFkZXIgZmllbGQuICBUaGlzIHNwZWNpZmljYXRpb24gYWxzbyBpbnRy b2R1Y2VzDQogICBhIGxpbmsgcmVsYXRpb24gdHlwZSB0byBzdXBwb3J0IGRpc2NvdmVyeSBvZiBz ZXRzIG9mIGxpbmtzLg0KDQpOb3RlIHRvIFJlYWRlcnMNCg0KICAgUGxlYXNlIGRpc2N1c3MgdGhp cyBkcmFmdCBvbiB0aGUgIkJ1aWxkaW5nIEJsb2NrcyBmb3IgSFRUUCBBUElzIg0KICAgbWFpbGlu ZyBsaXN0IChodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h0dHBhcGkpLg0K DQogICBPbmxpbmUgYWNjZXNzIHRvIGFsbCB2ZXJzaW9ucyBhbmQgZmlsZXMgaXMgYXZhaWxhYmxl IG9uIEdpdEh1Yg0KICAgKGh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXdnLWh0dHBhcGkvbGlua3Nl dCkuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQg aXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWh0dHBhcGkt bGlua3NldC8NCg0KVGhlcmUgaXMgYWxzbyBhbiBIVE1MIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1pZXRmLWh0dHBhcGktbGlua3Nl dC0wNy5odG1sDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJs ZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWh0dHBh cGktbGlua3NldC0wNw0KDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg cnN5bmMgYXQgcnN5bmMuaWV0Zi5vcmc6OmludGVybmV0LWRyYWZ0cw0KDQoNCi0tDQpodHRwYXBp IG1haWxpbmcgbGlzdA0KaHR0cGFwaUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9odHRwYXBpDQoNCkNPTkZJREVOVElBTElUWSAvIERJU0NMQUlNRVI6IFRo ZSBjb250ZW50cyBvZiB0aGlzIGUtbWFpbCBhcmUgIGNvbmZpZGVudGlhbCBhbmQgYXJlIG5vdCB0 byBiZSByZWdhcmRlZCBhcyBhIGNvbnRyYWN0dWFsIG9mZmVyIG9yIGFjY2VwdGFuY2UgZnJvbSBH UzEgKHJlZ2lzdGVyZWQgaW4gQmVsZ2l1bSkuIA0KSWYgeW91IGFyZSBub3QgdGhlIGFkZHJlc3Nl ZSwgb3IgaWYgdGhpcyBoYXMgYmVlbiBjb3BpZWQgb3Igc2VudCB0byB5b3UgaW4gZXJyb3IsIHlv dSBtdXN0IG5vdCB1c2UgZGF0YSBoZXJlaW4gZm9yIGFueSBwdXJwb3NlLCB5b3UgbXVzdCBkZWxl dGUgaXQsIGFuZCBzaG91bGQgaW5mb3JtIHRoZSBzZW5kZXIuIA0KR1MxIGRpc2NsYWltcyBsaWFi aWxpdHkgZm9yIGFjY3VyYWN5IG9yIGNvbXBsZXRlbmVzcywgYW5kIG9waW5pb25zIGV4cHJlc3Nl ZCBhcmUgdGhvc2Ugb2YgdGhlIGF1dGhvciBhbG9uZS4gDQpHUzEgbWF5IG1vbml0b3IgY29tbXVu aWNhdGlvbnMuIA0KVGhpcmQgcGFydHkgcmlnaHRzIGFja25vd2xlZGdlZC4gDQooYykgMjAyMC4N Cg== From nobody Tue Feb 8 09:22:14 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF913A1159; Tue, 8 Feb 2022 09:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 woXmLVmhmpmp; Tue, 8 Feb 2022 09:21:58 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 2A0DC3A10B9; Tue, 8 Feb 2022 09:21:52 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.1.2/8.16.1.2) with ESMTP id 218FUZKm010706; Tue, 8 Feb 2022 17:21:50 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=aT/YcioI6aagLP1rCUC4pTR1uNgO0j73w0og/0VFn7Q=; b=o4bPlFMCIO/ldQ3stL6d6NdpwsNi9Jwo/P4MwWqKZBr+YNuetADQs6fmF1640IpN1FJz vGjBQQEPDd60t0NPLGsj44EG5r09xi4/rdUQFk6KAp10Gr0lpeFll3zcKr+FrRaMySqe aKpSGKOXMDKirapwxn276tQyF8hOUAca9atBMLgGXIrvm+2lrZvv7CEnCFep9RCiZcn0 VipMqxA/eTFEq4N8sd3F9IlDVEU1olhxQvEWt/KFE2kRacuOAtRKBr0j+wRdQF83J6r3 i6CgXkZamAv1FoW3cYF+TBBkvJrRBbdnutN+jCMzMUF7KCKcrtFXlZqDb66R8eb/oJff TQ== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050096.ppops.net-00190b01. (PPS) with ESMTPS id 3e3pu1r2jn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Feb 2022 17:21:49 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 218HK2Rc016630; Tue, 8 Feb 2022 09:21:49 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint5.akamai.com with ESMTP id 3e1r3fd3ph-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 08 Feb 2022 09:21:49 -0800 Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag4mb4.msg.corp.akamai.com (172.27.91.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.922.19; Tue, 8 Feb 2022 12:21:48 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Tue, 8 Feb 2022 12:21:48 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.028; Tue, 8 Feb 2022 12:21:48 -0500 From: "Salz, Rich" To: Phil Archer , "httpapi@ietf.org" Thread-Topic: [httpapi] I-D Action: draft-ietf-httpapi-linkset-07.txt Thread-Index: AQHYHQi0l4hLvkTliU+mfJ3pGMKanqyKNYiA//+xGoA= Date: Tue, 8 Feb 2022 17:21:48 +0000 Message-ID: <75E1D705-0F26-4694-AC63-4A57CE1F6789@akamai.com> References: <164433757713.27235.18360157893914327848@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.58.22020202 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.118.139] Content-Type: text/plain; charset="utf-8" Content-ID: <1279E5751595EE4EB12441ACEFB0F3A5@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-02-08_06:2022-02-07, 2022-02-08 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 mlxscore=0 spamscore=0 malwarescore=0 mlxlogscore=885 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202080104 X-Proofpoint-ORIG-GUID: M_TxK0LulZ7rM2ELCw-dNLdBJcMwyswp X-Proofpoint-GUID: M_TxK0LulZ7rM2ELCw-dNLdBJcMwyswp X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-08_06,2022-02-07_02,2021-12-02_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 adultscore=0 spamscore=0 suspectscore=0 mlxscore=0 malwarescore=0 phishscore=0 impostorscore=0 lowpriorityscore=0 mlxlogscore=929 bulkscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202080104 Archived-At: Subject: Re: [httpapi] I-D Action: draft-ietf-httpapi-linkset-07.txt X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2022 17:22:11 -0000 DQoNCu+7v09uIDIvOC8yMiwgMTI6MDQgUE0sICJQaGlsIEFyY2hlciIgPHBoaWwuYXJjaGVyPTQw Z3MxLm9yZ0BkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQo+IHRoZSBhY3R1YWwgZG9jIHdpdGhpbiB0 aGF0IHBhZ2UsIGFuZCB0aGUgSFRNTCB2ZXJzaW9uIGF0IGh0dHBzOi8vd3d3LmlldGYub3JnL2Fy Y2hpdmUvaWQvZHJhZnQtaWV0Zi1odHRwYXBpLWxpbmtzZXQtMDcuaHRtbCwgc3RpbGwgc2hvd3Mg dGhlIGludGVuZGVkIHN0YXR1cyBhcyBpbmZvcm1hdGlvbmFsLg0KDQo+ICAgIEFtIEkgbWlzdW5k ZXJzdGFuZGluZyB0aGlzIG9yIGlzIHRoZXJlIGFuIGFjdHVhbCAoc21hbGwsIGVudGlyZWx5IHVu ZGVyc3RhbmRhYmxlKSBlcnJvcj8NCg0KVGhlIGNoYW5nZSBmcm9tIGNhdG9yZ3k9aW5mbyB0byBj YXRlZ29yeT1zdGQgc2hvdWxkIGhhdmUgYmVlbiBzdWZmaWNpZW50LCBidXQgUkZDIDc5OTEgd2hp Y2ggZGVmaW5lcyB0aGUgWE1MIHNheXMgaXRzIGRlcHJlY2F0ZWQuIEJ1dCBpdCBkb2Vzbid0IHNh eSBkby1ub3QtdXNlIHNvIEknbGwgdGFrZSBpdCB1cCB3aXRoIHRoZSByZmMtZGlzY3VzcyBsaXN0 LiAgRm9yIG5vdywgZG9uJ3Qgd29ycnkgYWJvdXQgaXQuDQoNCkdvb2QgY2F0Y2ghDQoNCg== From nobody Tue Feb 8 12:17:17 2022 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B89A3A117E; Tue, 8 Feb 2022 12:16:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: httpapi@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: httpapi@ietf.org Message-ID: <164435141608.27826.15739549520695135926@ietfa.amsl.com> Date: Tue, 08 Feb 2022 12:16:56 -0800 Archived-At: Subject: [httpapi] I-D Action: draft-ietf-httpapi-linkset-08.txt X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2022 20:16:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Building Blocks for HTTP APIs WG of the IETF. Title : Linkset: Media Types and a Link Relation Type for Link Sets Authors : Erik Wilde Herbert Van de Sompel Filename : draft-ietf-httpapi-linkset-08.txt Pages : 34 Date : 2022-02-08 Abstract: This specification defines two formats and respective media types for representing sets of links as stand-alone documents. One format is JSON-based, the other aligned with the format for representing links in the HTTP "Link" header field. This specification also introduces a link relation type to support discovery of sets of links. Note to Readers Please discuss this draft on the "Building Blocks for HTTP APIs" mailing list (https://www.ietf.org/mailman/listinfo/httpapi). Online access to all versions and files is available on GitHub (https://github.com/ietf-wg-httpapi/linkset). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpapi-linkset/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-httpapi-linkset-08.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-httpapi-linkset-08 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Feb 8 13:04:27 2022 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B33CF3A1107; Tue, 8 Feb 2022 13:04:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-httpapi-linkset@ietf.org, francesca.palombini@ericsson.com, httpapi-chairs@ietf.org, httpapi@ietf.org, rsalz@akamai.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <164435426462.3990.12183322099310111758@ietfa.amsl.com> Date: Tue, 08 Feb 2022 13:04:24 -0800 Archived-At: Subject: [httpapi] Second Last Call: (Linkset: Media Types and a Link Relation Type for Link Sets) to Proposed Standard X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2022 21:04:25 -0000 The IESG has received a request from the Building Blocks for HTTP APIs WG (httpapi) to consider the following document: - 'Linkset: Media Types and a Link Relation Type for Link Sets' as Proposed Standard This second Last Call is specifically on the intended RFC status change, which was set to Informational in the previous Last Call and changed to Proposed Standard following feedback from the community. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2022-02-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines two formats and respective media types for representing sets of links as stand-alone documents. One format is JSON-based, the other aligned with the format for representing links in the HTTP "Link" header field. This specification also introduces a link relation type to support discovery of sets of links. Note to Readers Please discuss this draft on the "Building Blocks for HTTP APIs" mailing list (https://www.ietf.org/mailman/listinfo/httpapi). Online access to all versions and files is available on GitHub (https://github.com/ietf-wg-httpapi/linkset). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-httpapi-linkset/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Feb 8 21:30:04 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8EA3A0CF6 for ; Tue, 8 Feb 2022 21:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.1 X-Spam-Level: X-Spam-Status: No, score=-7.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, 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=lowentropy.net header.b=DuivWVsS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QGzB4v8n 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 AzlpqOM6iJtB for ; Tue, 8 Feb 2022 21:29:57 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B75813A0CE8 for ; Tue, 8 Feb 2022 21:29:57 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 952E73201FCD for ; Wed, 9 Feb 2022 00:29:53 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Wed, 09 Feb 2022 00:29:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm1; bh=n zXYYvs9P5imJYquhsbqkmzuMa9CUzGRG+OxeedbKrE=; b=DuivWVsS7BhggtlO5 whQmkrJFOHZGYPhjoNTdr4ddcM3SUA1vyQMK1VpnAD2Q0oAecmYly6zL5mHshj4t qRKv3AMUaaqbkv+mrt+4O5jPTaYr1YWsPS7UExlorEXUuv1XmdGZLCioCGqxJFR4 iHReKbGeFTpwBkr4OONWlWfUIWtdVtR6XvLn/UUXUu0bE60UEAuNJ3DCIKfAfLVI jnWnYuNYqmtBEnvLU0SbAK/N3xrPYN6JsQK864Ay3LGFpU/F+UVIZfAon6Qqjf3L 2HytVakjctTC2rmXC2MYo4mdpAIkmVJLWl7pDbUq7pE+Z7DOe4/SROmCgCM+/tLW BVn3g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=nzXYYvs9P5imJYquhsbqkmzuMa9CUzGRG+OxeedbK rE=; b=QGzB4v8n0k13uzFSckig6KOoCRpB3M1nc10eXu3vzxtnwwLShUb3XctID QisV83oY6TAR4S3BtBYhj9GSxg4KffkgOiQPkeQeexyqWji0UWNwRUjD8cOPBJwF EoXBdA1QUltSFVmoZYqE0uof9YVwLFLF8ekW/bBUI6LtMAxgUxe+fbNWB8SiRZf/ LUHBR4xjdBRoefBhiJTO5r2SDA6d8MRUooh6oTGW8YkdINDo+satEd5mCQjPrUF+ tsxH7fi7TgUZvnFvRoZNO9hmTXEf1o+NqUxsG+/nzITDvgcrCxeD+8D0cMwkGpuo /V0rSxrP/VVWUw07Ia5vlIcqC9y4w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrheekgdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenuc fjughrpefofgggkfffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhhtihhn ucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtffrrg htthgvrhhnpeevjedtteeujeeugeekvdetgeejteejgeegtedtleelieejkeeuleeifeek veeghfenucffohhmrghinhepihgvthhfrdhorhhgpdhhthhtphifghdrohhrghdpghhith hhuhgsrdhiohenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E75133C00CF; Wed, 9 Feb 2022 00:29:52 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4748-g31a5b5f50e-fm-cal2020-20220204.001-g31a5b5f5 Mime-Version: 1.0 Message-Id: <054f7a17-d8df-42a6-9d36-0f3aca00c159@beta.fastmail.com> Date: Wed, 09 Feb 2022 16:29:33 +1100 From: "Martin Thomson" To: httpapi@ietf.org Content-Type: text/plain Archived-At: Subject: [httpapi] Using Date in requests X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2022 05:30:03 -0000 Hi Everyone, I've just posted https://www.ietf.org/archive/id/draft-thomson-httpapi-date-requests-00.html which talks about how to use Date in requests. This is not a typical thing you see, but some of the things we're doing elsewhere makes this relevant. For example, signing requests [1] and oblivious HTTP [2] - depending on circumstances - might want to use Date for managing anti-replay. I'm bring this here as I think that this group has more direct expertise and the work is related to some of the other stuff you are doing, like the idempotency-key, which is complementary. This also uses the problem details work (RFC 7807bis) for signaling when Date is missing or incorrect. I'm happy to go into the use case in more detail if the content of the draft isn't clear enough. Mostly, I'm just doing this so there is a complete and robust solution for how to manage replay for the aforementioned work. Cheers, Martin [1] https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html [2] https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html From nobody Tue Feb 8 23:25:32 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF5F3A0F29 for ; Tue, 8 Feb 2022 23:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iPF5K3F2RhV for ; Tue, 8 Feb 2022 23:25:26 -0800 (PST) Received: from mail.server.beonex.com (mail.server.beonex.com [144.76.227.234]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B0FA3A0F0E for ; Tue, 8 Feb 2022 23:25:23 -0800 (PST) Content-Type: multipart/alternative; boundary="------------9IZ305trB0GcewRDTjK1VFVv" Message-ID: <710c5984-6dd5-bdd7-af55-ea3e4d6c9b67@bucksch.org> Date: Wed, 9 Feb 2022 08:25:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.5.1 Content-Language: en-US To: httpapi@ietf.org References: <054f7a17-d8df-42a6-9d36-0f3aca00c159@beta.fastmail.com> From: Ben Bucksch Organization: Me, myself and I In-Reply-To: <054f7a17-d8df-42a6-9d36-0f3aca00c159@beta.fastmail.com> Archived-At: Subject: Re: [httpapi] Using Date in requests X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2022 07:25:31 -0000 This is a multi-part message in MIME format. --------------9IZ305trB0GcewRDTjK1VFVv Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Am 09.02.22 um 06:29 schrieb Martin Thomson: > I've just postedhttps://www.ietf.org/archive/id/draft-thomson-httpapi-date-requests-00.html which talks about how to use Date in requests. ... use Date for managing anti-replay. Hello Martin, thanks for posting this and asking for feedback. I appreciate that you acknowledge the problem of clock screw in the spec. Some clocks are so bad that they can easily be minutes out of sync. Yet others are simply set to the completely wrong time, but the user doesn't use that clock, so he doesn't know. This leads to serious problems in such systems that compare clocks of different systems, particularly if the systems are managed by different entities, like in most client/server scenarios. I ran into that very painfully with JWT [1]. It took multiple developers several days to debug a failure, which eventually turned out to be a simple clock screw. I came to the conclusion that any system that compares clocks of two different systems is inherently flawed. That general idea should be avoided in any system - be it a custom site-specific security measure, or an Internet standard. Rather, time should always be *relative*. Coincidentally, Einstein agreed ;-). So, what I would propose is rather something that works like a special browser cookie. For the sake of the discussion, I call it "time cookie", but it doesn't need to be technically a cookie, but it should have the same storage properties and lifetime as a cookie, for privacy and tracking purposes. This time cookie would contain a simple Integer, and the only special thing about it is that the browser stores the local time when it was received, and when it's sent, the browser adds the *time difference between receiving and sending*, in the form of the difference of Unixtime. For example, the server sends 1,000,000 . That's an arbitary Integer value, but let's say the server uses the Unixtime of its local server. When receiving, the browser stores this value, together with the current local time, on the client system, e.g. as Unixtime (which is let's say 1,001,000, i.e. client and server disagree by 1 000 seconds = 17 minutes, but that doesn't matter). 10 seconds later, the browser makes another request to the same server, and the browser sends the server-supplied value of 1,000,000 plus 10 (seconds) = 1,000,010. The server recieves this, the server compares it to its own local Unixtime (or any other base value), and it matches, and the request works. If you were to send the client time, the client would have sent 1,001,010, and the value would not have matched and the request would have failed. I believe that such a system that sends /only/ the time difference is inherently safer and more reliable, less prone to security attacks, and also eventually simpler to implement, if you consider all the counter-measures that a system based on absolute time would have to implement against clock screw and security attacks. I appreciate very much the thought that you put into all the problems of clock screw, security attacks manipulating local time, and even privacy threats that abuse the stored server-time for tracking. Very well done. But I believe that all of these could be avoided by a system and simply uses only relative time and never ever compares clocks between two systems. Due to these known problems, I would recommend to explicitly /avoid/ to use a format that uses an absolute date/time format and instead to intentionally specify that the browser sends the time difference in the form of seconds or milliseconds. You all have experienced first hand how often even the most simple things (like HTTP error codes) are implemented without reading the specs carefully, so I am concerned that many implementations will not consider the extensive thoughts about clock screw that you put in, or probably won't even read any part of the spec, but if there's a "Date" header in datetime format, many devs will simply send the current local time, without any adjustment or consideration. So, a system that is explicitly specced to transmit *only* the time *difference* and does not use the format of an absolute time is far more likely to be implemented correctly. Let's just forget the idea that there is an universally agreed absolute time. Repectfully, Ben Bucksch [1] Very painful experience with JWT We wrote a script to upload [something to a third-party server] as part of our build process. The code was working for [the dev who] wrote the script, but I just got "Invalid authentication credentials". We were debugging it for hours and hours, suspecting shell argument passing and parsing, OS differences and what not. We compared credentials and confirmed they are identical. Still, the result was different. During debugging, once, by coincidence, it worked. At a time when it should be expired. What was the reason? My clock on my computer was fast. I was screaming. Client server protocols must NEVER EVER compare client clocks with server clocks, because clocks are very often off. Even if it was originally set exactly right by the second, clocks always have a drift in one way or another. If you have 5 million users, you will surely have [many] users whose clocks are off... In my case, my clock was 95 seconds fast. That's not uncommon. I don't run ntpdate regularly, because ntp regularly has security problems, too. This is a fatal misdesign of the protocol. You simply cannot compare client clock with server clocks. That something that engineers generally know from experience. Often hard lessons, like mine above. Sometimes worse lessons, when 5 million people were hit by this problem. --------------9IZ305trB0GcewRDTjK1VFVv Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Am 09.02.22 um 06:29 schrieb Martin Thomson:
I've just posted https://www.ietf.org/archive/id/draft-thomson-httpapi-date-requests-00.html which talks about how to use Date in requests.  ... use Date for managing anti-replay.


Hello Martin,

thanks for posting this and asking for feedback.

I appreciate that you acknowledge the problem of clock screw in the spec. Some clocks are so bad that they can easily be minutes out of sync. Yet others are simply set to the completely wrong time, but the user doesn't use that clock, so he doesn't know. This leads to serious problems in such systems that compare clocks of different systems, particularly if the systems are managed by different entities, like in most client/server scenarios.

I ran into that very painfully with JWT [1]. It took multiple developers several days to debug a failure, which eventually turned out to be a simple clock screw.

I came to the conclusion that any system that compares clocks of two different systems is inherently flawed. That general idea should be avoided in any system - be it a custom site-specific security measure, or an Internet standard.

Rather, time should always be relative. Coincidentally, Einstein agreed ;-).

So, what I would propose is rather something that works like a special browser cookie. For the sake of the discussion, I call it "time cookie", but it doesn't need to be technically a cookie, but it should have the same storage properties and lifetime as a cookie, for privacy and tracking purposes. This time cookie would contain a simple Integer, and the only special thing about it is that the browser stores the local time when it was received, and when it's sent, the browser adds the time difference between receiving and sending, in the form of the difference of Unixtime.

For example, the server sends 1,000,000 . That's an arbitary Integer value, but let's say the server uses the Unixtime of its local server. When receiving, the browser stores this value, together with the current local time, on the client system, e.g. as Unixtime (which is let's say 1,001,000, i.e. client and server disagree by 1 000 seconds = 17 minutes, but that doesn't matter). 10 seconds later, the browser makes another request to the same server, and the browser sends the server-supplied value of 1,000,000 plus 10 (seconds) = 1,000,010. The server recieves this, the server compares it to its own local Unixtime (or any other base value), and it matches, and the request works.

If you were to send the client time, the client would have sent 1,001,010, and the value would not have matched and the request would have failed.

I believe that such a system that sends only the time difference is inherently safer and more reliable, less prone to security attacks, and also eventually simpler to implement, if you consider all the counter-measures that a system based on absolute time would have to implement against clock screw and security attacks.

I appreciate very much the thought that you put into all the problems of clock screw, security attacks manipulating local time, and even privacy threats that abuse the stored server-time for tracking. Very well done. But I believe that all of these could be avoided by a system and simply uses only relative time and never ever compares clocks between two systems.

Due to these known problems, I would recommend to explicitly avoid to use a format that uses an absolute date/time format and instead to intentionally specify that the browser sends the time difference in the form of seconds or milliseconds. You all have experienced first hand how often even the most simple things (like HTTP error codes) are implemented without reading the specs carefully, so I am concerned that many implementations will not consider the extensive thoughts about clock screw that you put in, or probably won't even read any part of the spec, but if there's a "Date" header in datetime format, many devs will simply send the current local time, without any adjustment or consideration. So, a system that is explicitly specced to transmit only the time difference and does not use the format of an absolute time is far more likely to be implemented correctly.

Let's just forget the idea that there is an universally agreed absolute time.

Repectfully,

Ben Bucksch




[1] Very painful experience with JWT

We wrote a script to upload [something to a third-party server] as part of our build process. The code was working for [the dev who] wrote the script, but I just got "Invalid authentication credentials".

We were debugging it for hours and hours, suspecting shell argument passing and parsing, OS differences and what not. We compared credentials and confirmed they are identical. Still, the result was different. During debugging, once, by coincidence, it worked. At a time when it should be expired.

What was the reason? My clock on my computer was fast.

I was screaming. Client server protocols must NEVER EVER compare client clocks with server clocks, because clocks are very often off. Even if it was originally set exactly right by the second, clocks always have a drift in one way or another. If you have 5 million users, you will surely have [many] users whose clocks are off... In my case, my clock was 95 seconds fast. That's not uncommon. I don't run ntpdate regularly, because ntp regularly has security problems, too.

This is a fatal misdesign of the protocol. You simply cannot compare client clock with server clocks. That something that engineers generally know from experience. Often hard lessons, like mine above. Sometimes worse lessons, when 5 million people were hit by this problem.


--------------9IZ305trB0GcewRDTjK1VFVv-- From nobody Wed Feb 9 04:04:33 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1513F3A144B for ; Wed, 9 Feb 2022 04:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 D3zj3MCOoxYW for ; Wed, 9 Feb 2022 04:04:17 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 616E73A149B for ; Wed, 9 Feb 2022 04:04:02 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id h7so2777514iof.3 for ; Wed, 09 Feb 2022 04:04:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K+dXIWIUdNqqjVtYpwsNNDq2mU7UEsOl+TANBIBs2is=; b=no5uGtDVwfCq+A+mZ7OGt07+p1SY6Uzxzr9sNaUAzfuyoq3G9yroJZaXiM+nFYeO7F 9QEGKz4Ng4Y8nxGvOziNsrUD9SAnIKe4nVdD4PJgJO2YcJwFem7PSQ8fsPuIwVJqXSWB 0eucMJIoBZp2LvD193IvAfpUHVLcCxeRPfxiCm16jgRVewOSYq3uFt8y4Jzo7hfqc9VC my6EH+Kt6pCZFYV2PheBK+b6/xopMtQ44MsQmr3Jegw8jVA4FNR0cGaxGlfabXLUVUIh 87mXUkyvUg5M7YnLDhttKPVOCzGGhi/b+CQC4v+9mvKcD05P9gPHQSfj3IOrIsSUxb8b rgqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K+dXIWIUdNqqjVtYpwsNNDq2mU7UEsOl+TANBIBs2is=; b=aQqgDw9oRSEq9/TILgK4YlFQ5WySQYQQ06mJVXi4C+2IgE8eRBQ7B5l01BTyD1Zt8p oXGc14j9e0UvhUzWmne9gemfRGgNMUEEC6y5/Jv7Q0uBGUXnsvgF0rIn/CFkdrNowikD f6TcodIyp/ntINzb5Et3juBfxakN5rD27JkoteDl3l4b18kunMe1Zz9fk0qA4XH8SI10 C/JKGGgHDgV6dxPMKHn48LBniTlvU5pK6ejU3aigKY+SZDyPthg6BzBCD33HNn/sv7N/ TCEBYmrnmGpFeeLKzJAD9GncOy4nsNEzxc7+mn4aVydV2IJy1DlAheJp3hB1T+Xu4nmM J3KQ== X-Gm-Message-State: AOAM531wUkMJ9RJtm+PPSItnVE6erXD6NK9ZR3yaJHyV46dgOti4MXt3 VAayjx+WjQBSXsxqmltVLEEVeITz1ac536h6BHlaJJl7t/0= X-Google-Smtp-Source: ABdhPJw1xZouoZMuzXXMCbE1SgYY9r8opfbIQqlqqNOt5B9vgUZ2To/46QOUWEHxSbrGQhLjfCozGX8p/74ydo2PCP4= X-Received: by 2002:a05:6638:1454:: with SMTP id l20mr915785jad.22.1644408240755; Wed, 09 Feb 2022 04:04:00 -0800 (PST) MIME-Version: 1.0 References: <054f7a17-d8df-42a6-9d36-0f3aca00c159@beta.fastmail.com> In-Reply-To: <054f7a17-d8df-42a6-9d36-0f3aca00c159@beta.fastmail.com> From: Roberto Polli Date: Wed, 9 Feb 2022 13:03:49 +0100 Message-ID: To: Martin Thomson Cc: "httpapi@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [httpapi] Using Date in requests X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2022 12:04:31 -0000 Hi Martin, Il giorno mer 9 feb 2022 alle ore 06:30 Martin Thomson ha scritto: > I've just posted https://www.ietf.org/archive/id/draft-thomson-httpapi-date-requests-00.html which talks about how to use Date in requests. Thanks for your draft, I think that the considerations are interesting, and are widely applicable when using Date. It seems to me to be a kind of BCP. Probably some of them would fit the `Date` field definition. > [...] signing requests [1] and oblivious HTTP [2] - depending on circumstances - might want to use Date for managing anti-replay. While I can't tell on oblivious HTTP, all the considerations in the document suggest to me that using the signature validity and timestamps expressed via JWT (iat, nbf, exp) or via Signature's created, expires parameters is more reliable than signing Date. > [..] the work is related to some of the other stuff you are doing, > like the idempotency-key, which is complementary. > This also uses the problem details work (RFC 7807bis) for signaling when Date is missing or incorrect. I am curious about whether this applies to the SF-Date proposal too (eg. to signal the presence of both SF-Date and Date eg when both fields are present in signatures, ...) > I'm happy to go into the use case in more detail Please, do! Thanks for your time and have a nice day, R. From nobody Wed Feb 9 06:48:45 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A4F3A0A0A for ; Wed, 9 Feb 2022 06:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 cgnfKloybrdp for ; Wed, 9 Feb 2022 06:48:37 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 3418B3A0147 for ; Wed, 9 Feb 2022 06:48:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1644418085; bh=V4zxrvAlqwwD2cfSia2uYesMTe1H8Y8sRZxem36o5fc=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=jfBHN6NHy4bH1p2tyj18NH6Lasi8QBCVpxpXlLDsLIzzsYGn0Fk9zQmA9ihklaK7A 8kLR9W2TCO67t4h2ekOoDm5KecM6Fl7IOyKr/pO2YdEWUqgmr4k9TMYIee20sIrNQr t7NfjO6Sz6AAEBA81X5mwjtEtkgGRiRA2P55FOHs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.143] ([5.10.171.186]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MtwUm-1oBhlp2MQu-00uJXp for ; Wed, 09 Feb 2022 15:48:05 +0100 Message-ID: Date: Wed, 9 Feb 2022 15:48:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 To: httpapi@ietf.org References: From: Julian Reschke In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:ft5Rw9U1F1fkM3Rt+FVUM3AwlB1L3U9Ju66YVMGSp+vCkF+bPxm FcGmhaB6qQN6NqTGIDc7ckWsEtfujNJnJlxLCZedr3ozHwvUxAtSFx0cCbTyxufTMy2cwt5 SQeR4Tlpfi3nr4uRyo07wKKQxBMTiUaMTLFkTyAcHxmduNzB0bxoss7UXCxpv/lkD+dcYyy rKdEseqp/09kHloEw0fhA== X-UI-Out-Filterresults: notjunk:1;V03:K0:gF1aUSwnSkc=:MEn0fLxjzqxNeECRBF62BC o97CFKEofwzqdBJGbLK3bsw0HUeuJnLsvv6VHwFdXeaVQ2ZooKeeJLbXVwYIklR6aXd+CszGY rZaZ5LVhKgS3aUm0vUfzyKvKK/17jZroMxujZzUSssEDzZ0X2I8HjukW6hRQTU5pJ2VPlYp38 gklbuFBsRgVO4fS71JLkuTV0rDu06BhseevG24Z8qlcqu/xIdSppnzQnTZP68rtydJREtxIwV e7RWF2Hz+ldEiv1EEuyp709pVCJM/XD7DYava8uB+eN1BEagAW6BUozq6Cuv2LMXwrwT4yz+8 EsAi1rmi/NmEhZMRcxkPXqS1ER30kqHWMvwa6GvjQD2+c07Ih5nlJvH/eyk7Iv+7CPGCuaJGy MaXLqjH8AV1wI+lSYFEYt3TJpb+9tpQ0EcMFZ4VC3MwbVNqaz51Qv5Aqx4d4KKNrLxd+a1Vry c+GsDOiDvMUb9VzG/o69MetfMrzM+fTJXt6p5HrHCkzJUw1/bCDKXFTafdVTaOHTXKw5QFEvX dc5zJJuRmpxJdo0U6GYkRu7IS0TNVu7vtOO0m8efxP/bwgBj5c9iw8x+RjAkE7wsC2qCBTX/7 bpjWKqYBkRPIVL7+iJWVh9bP8/3IWaMUo7McZmk0h76G3lBSHFRIsRQjrhyL4ldKKStIlsfcf vZWalF95ZZAapClORwRrABJP68cQhGnmfGDFUO6ex83G068TtJjbnVqQGELmZ4KSTgAKWEym2 OcLLdxaUp1x8eqKm3DUM8oduGlYOBjDZpFWznmhQucL/xUjG+2DPBc7PQab/WgviZ0y2gzBlN 3Z9Edo8xxqCdJE7OHGjUqPJ8ePgsRnDJkBM61f9gXDcC95hkCHBq/vts8eoa4oRh3w4KyYOty iQK9HLCrhxeLshJLUkKXexlRt7EFke67MvCrBg1Odyb8iR5Q7z+14kahV+Or0u7vGbtwnweDp z9aki7VEty2NKH5aioH/N8/GZncAJjrfxQI1GylW7rM2FtJfn5SzqOIjC+FZ3X7VNBc/NwJf3 rM96vGPhA7xqEcq1qUIqev5eh+Gp4RsXQZHads1U9c+MPGPXYNDRyxZCfdzM+7ifMApNqr9h7 AzGwX243YcHk0w= Archived-At: Subject: Re: [httpapi] Multiple Problems in RFC7807bis X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2022 14:48:43 -0000 Am 08.02.2022 um 00:54 schrieb Mark Nottingham: > Hi everyone, > > We've been discussing how to talk about conveying multiple problems in R= FC7807bis here: > https://github.com/ietf-wg-httpapi/rfc7807bis/issues/6 > > Towards the end of that conversation (as of now), we seem to be convergi= ng on how to do this. Copying my comments from there: > > ~~~ > We currently: > > =E2=80=A2 Describe how to design extensions to accommodate multiple ins= tances of the same type > =E2=80=A2 Describe how to use 207 Multi-Status to convey multiple probl= ems with different types/status codes > =E2=80=A2 Do not describe how one might convey multiple problems with d= ifferent types but the same status code. > > I think (1) is fine and good. > > Right now, (2) seems like it's recommending the pattern, but doesn't def= ine an actual type for use in that situation. That's not great. If we're g= oing to show that pattern, we should probably define the type for use in t= hat situation (especially since we have a registry now). However, I have s= erious doubts about the wisdom of recommending that pattern, and feel like= we should either remove that text, or at least heavily contextualise it. > > Regarding (3) -- again, if we want to document that, we should define a = type. I tend to think we shouldn't, though. > > If we retract (2) and don't attempt (3), we might want to add some text = along the lines of: > > When an API encounters multiple problems that do not share the same type= , it is RECOMMENDED that the most relevant or urgent problem be represente= d in the response. While it is possible to create generic "batch" problem = types that convey multiple, disparate types, they do not map well into HTT= P semantics. > ~~~ > > So far, there seems to be support for removing (2) and adding text simil= ar to that proposed. > > What do people think? I didn't have time to read all of the discussion, but one thing comes to mind: *if* status 207 is used, it needs to be consistent with the base definition from the WebDAV spec (*) . "A Multi-Status response conveys information about multiple resources in situations where multiple status codes might be appropriate." -- Using it for the case of "there are multiple issues with your request affecting a single resource" seems to bend that too much... Best regards, Julian (*) or the definition needs to be formally extended From nobody Wed Feb 9 18:59:27 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105BA3A12F9 for ; Wed, 9 Feb 2022 18:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lowentropy.net header.b=d69Sq/r2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iOdHsGwH 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 QfsBrcWUh3aO for ; Wed, 9 Feb 2022 18:59:21 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5EF3A12F5 for ; Wed, 9 Feb 2022 18:59:21 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 0E4DD3200F76 for ; Wed, 9 Feb 2022 21:59:20 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Wed, 09 Feb 2022 21:59:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=EVf8jvhQp9+CtN03TnXKlS2j83SMFP7gjXmTh6 FOy8k=; b=d69Sq/r2gWS0ObJyiPK2te5uW3bn5Figw+nzuTVjw4Eo3PlcpB18nM eK7gKmFhHBWhqi3e8/NbVpG+0BgMrNkSH2dCWy3BnbwtMzErnblc+OaOQZoOlU55 yszwPKNfZgHcVeaSXPgtEEE6i9UEUpZP+PSUkDEzBdcs/HoD1GLFNS6g5SW1qZVT ws7iJagoXJM3jnyi2UfDb/S1XdrIPPWPgRKJtmENVNdA5SgOERX2corCNQr577k9 XDmRpcRMKOYOroUhvwLh2hLY6X0TiNKrH+pMIDrSs/IAVuk6lo6WnM8hPWd6CaEU 5LUvFeOnYDSutkWXlJOpavqddRt4TlgA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=EVf8jvhQp9+CtN03T nXKlS2j83SMFP7gjXmTh6FOy8k=; b=iOdHsGwH5mJlV9W6npU4E4M6L0BORzcgC KnsCSfCU5Sk7Tflx6Pc8kJ9wfXS6rS6af9Uk/V01D0Hkf6TcQeGipng7Td9z38D8 CvV55XyaFZFdFOjbuqnZGGsS/ldRKYOahShF+3FsiTecGHMJUqR/Fzob31fQ1U3G JQXI+vfzNbhh9LgakewPtuoAbjV4u8VAX6yYl8ciQA/E+N1Y5HecHhUXT88Lgryk 0t2xt0jZGaMvgUekiVOvEzegMmAahmlW5xUAgjOFtZxIjaR4BE9bOI2rM3/IOz/Z 4e/BZ2K7lOpgJslOiELITd3wCwqJkHoapR/4DMsRVZ+P1zr0hnF4w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddriedtgdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnheptdevtddvgeevkeeiteekud fgffduieegvdfhffefgfdvleffkeetvefgfeeutdfhnecuffhomhgrihhnpehivghtfhdr ohhrghdpghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 654C13C0F8A; Wed, 9 Feb 2022 21:59:20 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4748-g31a5b5f50e-fm-cal2020-20220204.001-g31a5b5f5 Mime-Version: 1.0 Message-Id: In-Reply-To: <710c5984-6dd5-bdd7-af55-ea3e4d6c9b67@bucksch.org> References: <054f7a17-d8df-42a6-9d36-0f3aca00c159@beta.fastmail.com> <710c5984-6dd5-bdd7-af55-ea3e4d6c9b67@bucksch.org> Date: Thu, 10 Feb 2022 13:59:01 +1100 From: "Martin Thomson" To: httpapi@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [httpapi] Using Date in requests X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2022 02:59:26 -0000 Hi Ben, You will note that the system I describe is almost exactly like the one you have. It's just that the "arbitrary number" is formatted as a Date field. The resulting change (if any) is stored in the same way as a cookie, with all the same considerations. I agree that this is suboptimal, but we're dealing with a system that exists. More expansive solutions are less likely to get implemented, particularly for niche use cases. Not many people want to include dates in requests. Many of those that do can use something like JWT/JWS rather than a Date field (same problems of course). Spelling it differently won't change much, except make the change more disruptive. I'm looking to make a surgical tweak that many people won't notice in order to deal with the problem. I think that's an easier change to enact than a more comprehensive change, even if that change might be more principled. Also, for all those cases where people do use dates and get the problems you cite, the draft proposes a nice problem message ... and automated remediation strategy. Cheers, Martin p.s., Funny you should say that clocks might be wrong by minutes. I've seen years and have credible reports of *decades*. On Wed, Feb 9, 2022, at 18:25, Ben Bucksch wrote: > Am 09.02.22 um 06:29 schrieb Martin Thomson: >> I've just posted https://www.ietf.org/archive/id/draft-thomson-httpapi-date-requests-00.html which talks about how to use Date in requests. ... use Date for managing anti-replay. > > > Hello Martin, > > thanks for posting this and asking for feedback. > > I appreciate that you acknowledge the problem of clock screw in the > spec. Some clocks are so bad that they can easily be minutes out of > sync. Yet others are simply set to the completely wrong time, but the > user doesn't use that clock, so he doesn't know. This leads to serious > problems in such systems that compare clocks of different systems, > particularly if the systems are managed by different entities, like in > most client/server scenarios. > > I ran into that very painfully with JWT [1]. It took multiple > developers several days to debug a failure, which eventually turned out > to be a simple clock screw. > > I came to the conclusion that any system that compares clocks of two > different systems is inherently flawed. That general idea should be > avoided in any system - be it a custom site-specific security measure, > or an Internet standard. > > Rather, time should always be *relative*. Coincidentally, Einstein agreed ;-). > > So, what I would propose is rather something that works like a special > browser cookie. For the sake of the discussion, I call it "time > cookie", but it doesn't need to be technically a cookie, but it should > have the same storage properties and lifetime as a cookie, for privacy > and tracking purposes. This time cookie would contain a simple Integer, > and the only special thing about it is that the browser stores the > local time when it was received, and when it's sent, the browser adds > the *time difference between receiving and sending*, in the form of the > difference of Unixtime. > > For example, the server sends 1,000,000 . That's an arbitary Integer > value, but let's say the server uses the Unixtime of its local server. > When receiving, the browser stores this value, together with the > current local time, on the client system, e.g. as Unixtime (which is > let's say 1,001,000, i.e. client and server disagree by 1 000 seconds = > 17 minutes, but that doesn't matter). 10 seconds later, the browser > makes another request to the same server, and the browser sends the > server-supplied value of 1,000,000 plus 10 (seconds) = 1,000,010. The > server recieves this, the server compares it to its own local Unixtime > (or any other base value), and it matches, and the request works. > > If you were to send the client time, the client would have sent > 1,001,010, and the value would not have matched and the request would > have failed. > > I believe that such a system that sends *only* the time difference is > inherently safer and more reliable, less prone to security attacks, and > also eventually simpler to implement, if you consider all the > counter-measures that a system based on absolute time would have to > implement against clock screw and security attacks. > > I appreciate very much the thought that you put into all the problems > of clock screw, security attacks manipulating local time, and even > privacy threats that abuse the stored server-time for tracking. Very > well done. But I believe that all of these could be avoided by a system > and simply uses only relative time and never ever compares clocks > between two systems. > > Due to these known problems, I would recommend to explicitly *avoid* to > use a format that uses an absolute date/time format and instead to > intentionally specify that the browser sends the time difference in the > form of seconds or milliseconds. You all have experienced first hand > how often even the most simple things (like HTTP error codes) are > implemented without reading the specs carefully, so I am concerned that > many implementations will not consider the extensive thoughts about > clock screw that you put in, or probably won't even read any part of > the spec, but if there's a "Date" header in datetime format, many devs > will simply send the current local time, without any adjustment or > consideration. So, a system that is explicitly specced to transmit > *only* the time *difference* and does not use the format of an absolute > time is far more likely to be implemented correctly. > > Let's just forget the idea that there is an universally agreed absolute time. > > Repectfully, > > Ben Bucksch > > > > > > > > [1] Very painful experience with JWT > > > We wrote a script to upload [something to a third-party server] as part > of our build process. The code was working for [the dev who] wrote the > script, but I just got "Invalid authentication credentials". > > We were debugging it for hours and hours, suspecting shell argument > passing and parsing, OS differences and what not. We compared > credentials and confirmed they are identical. Still, the result was > different. During debugging, once, by coincidence, it worked. At a time > when it should be expired. > > What was the reason? My clock on my computer was fast. > > I was screaming. Client server protocols must NEVER EVER compare client > clocks with server clocks, because clocks are very often off. Even if > it was originally set exactly right by the second, clocks always have a > drift in one way or another. If you have 5 million users, you will > surely have [many] users whose clocks are off... In my case, my clock > was 95 seconds fast. That's not uncommon. I don't run ntpdate > regularly, because ntp regularly has security problems, too. > > This is a fatal misdesign of the protocol. You simply cannot compare > client clock with server clocks. That something that engineers > generally know from experience. Often hard lessons, like mine above. > Sometimes worse lessons, when 5 million people were hit by this problem. > > > > > -- > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi From nobody Wed Feb 9 19:06:37 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E41D3A12FE for ; Wed, 9 Feb 2022 19:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lowentropy.net header.b=Dx2a6kSb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J+vJmChi 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 lJ0m4nCaiMzL for ; Wed, 9 Feb 2022 19:06:31 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C793A12FA for ; Wed, 9 Feb 2022 19:06:31 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 095973200E5D; Wed, 9 Feb 2022 22:06:27 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Wed, 09 Feb 2022 22:06:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:cc:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; bh=yuqMMnamkax/Ng6m66HsiQv4n578Wc pwxURkgW+jpQ4=; b=Dx2a6kSbUbu3OMJyVVYZIcOUlGeQZaik1y+4QOSLbxl5Z2 LMozxBgq7A1OtdgBLHMKI3lulrzZ0ksvf8ugdgdBQ9o289sshASIn1diVS+57YNb S8buGUlSA6IObbpBRISddvEwN6J/6B4u70lXaMMNwYFotSbgQo0ZaI/L60qgPOXi iwW37boULzyT2QRQG6evJL/g8EvLmFxt6TtYUDDlzDdMPYeB2RyXh5HrI3f1lGvg xHosGi4EWlbQxs7Fq1M9J0RvNWaMC/URh9qPW1JMj42MIvirzVUejIWLu9VJqOxV 1ZcSOr4Pnr4KCuNOKD3fo2G4vZ55KBLkYszGoUJg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=yuqMMnamkax/Ng6m6 6HsiQv4n578WcpwxURkgW+jpQ4=; b=J+vJmChiVh2+dMC0ft9d+DftO4qU+1Npg KzCziQz12+dS3zQDAp+8jkdrrq8z9aVM2SJVFSa4Z9DsnzFEr9+1BXG2g+VCNzG/ 77v9BsFkj4qySY0f/xmycCRVwf5omf7N/FyKeuPgeMObcM2SXL0EzBJYOfkBgPm5 dr0Xjdbuci/PLue24yJltlzzRE9w5MiOjuuUq6/ZAa0B902fczKZJEiqHPZdt3F9 SoMtBp5JfecytuRbQpzRSZ5tE2QyYTjkC53Asf2jcg6fAuJgMd6x7UxG2Qs7aqDS XF7+xJtbt9cFrRnekedCUfyP1NahUx1W3nQBpMEXVTovLEwrjy46A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddriedtgdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtf frrghtthgvrhhnpeefudfggeejgeegvddvvdefudevieejffejvdeijeelkedvjeetieel hffhhfetveenucffohhmrghinhephhhtthhpshgvmhgrnhhtihgtshhithhishifvghllh dquggvfhhinhgvuggrnhgumhhoshhtshgvrhhvvghrshgsrhhorggutggrshhtihhtrghl rhgvrgguhidrihhtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 53ED03C0F8A; Wed, 9 Feb 2022 22:06:27 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4748-g31a5b5f50e-fm-cal2020-20220204.001-g31a5b5f5 Mime-Version: 1.0 Message-Id: <612e2098-c02c-4088-8da0-27d7c8485f3c@beta.fastmail.com> In-Reply-To: References: <054f7a17-d8df-42a6-9d36-0f3aca00c159@beta.fastmail.com> Date: Thu, 10 Feb 2022 14:06:07 +1100 From: "Martin Thomson" To: "Roberto Polli" Cc: "httpapi@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [httpapi] Using Date in requests X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2022 03:06:36 -0000 On Wed, Feb 9, 2022, at 23:03, Roberto Polli wrote: > While I can't tell on oblivious HTTP, all the considerations > in the document suggest to me that using the signature validity and > timestamps expressed > via JWT (iat, nbf, exp) or via Signature's created, expires parameters > is more reliable than signing Date. Probably true. Though I think the same considerations apply there as they do to Date. Oblivious HTTP doesn't really have the luxury of defining specific fields for this information. It is passing messages with generic HTTP semantics. For those cases where a server wants to do anti-replay, we want to have a place we can point to to say "here you need to have a monotonic sequence number that is roughly globally consistent (*cough* a Date) for the purposes of limiting the amount of state the server needs to maintain for anti-replay purposes". In discussing this problem for OHTTP we concluded that Date is an ideal fit for that requirement, modulo the clock skew issue. We considered minting our own field, but it just ended up being the same as Date anyway. It has simple HTTP semantics, it is well-defined, and most servers broadcast it already. It's nearly perfect, hence this draft. Date is also a pain to parse (an ongoing project to fix) and has some awkwardness involved, but I think all we need to do is improve comprehension of the problem. From nobody Fri Feb 11 07:17:43 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38BE3A11F5 for ; Fri, 11 Feb 2022 07:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 p4YLjc4-k4Vw for ; Fri, 11 Feb 2022 07:17:35 -0800 (PST) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 89DC03A083D for ; Fri, 11 Feb 2022 07:17:35 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id fj5so20695927ejc.4 for ; Fri, 11 Feb 2022 07:17:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YQqSx0gHlMskOoNlGfpuusllVJUHCgQmnfadZF+PSMM=; b=JALu5yWZzWuMoZxSNGFzhag7LVFV0P/bzgxxHdmvxRLQ3+sGcE3fQnsIbJ6O1DKZNu p7NV/KmAiUEApcqk5sM1LwE9Aru1d7E1lcWCsG5ifi0WJXzuZdN7lcn0nR4zX/pat2Lj LHxk2ydP5tDfxi8R7a1J7zr1CW2ha1HZSFxdQNkd1hgE/XHfHmymlWcVd4D1d944KniS HiL9PGDAiX3FbQMobmy2maEDiGe5NWLoI02+bls5y/boAUBk4DeiX6G5RzDyfjj6ZVAt nD2BLOLx20StE+LhLOP3c/Ap3OrOGaamEqxLrMdoACHNZqhdplwE5NfEE73ddfSNuyMc 5vzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YQqSx0gHlMskOoNlGfpuusllVJUHCgQmnfadZF+PSMM=; b=opVtWJC9PfG8ZnU++PK1dyb0yVY2cItd9+EP/20zyCFC65fL5T+itT49OCNk9RCAw2 t8T2DG+d5gMiS8xJq1eBPgNsuPD6ig9lLL4zgoYUyGl0RMHtdRb6748IY0CWggRV0l2c EXiZRRqQL+tJV+/c3YsX3D65bK1qhlXranTc6BlT0AReYZn1GVYyRt/OxTJOszYndj2R LILYV/Sjz4iTqcLORHCtPBPVY9+Fla99DvKwNupzD3m6jTc4tMlLn9EfyaiOafSHA1Je B3gm8HM7b2iyfkAF0g3WCZCzPZkW8/zDdskjRtWKuY+PWRpHPyYEdP/kXT0Hfj64642O +b9Q== X-Gm-Message-State: AOAM533XnOdL+h1gRV0axTX+WFpV7LBaSAZuPQ80P51UuDC3QEYBzo7h YJbLObvFetHF21xgBoQ3eAPVI0fJQfevFw== X-Google-Smtp-Source: ABdhPJzvxP/05VyQuJXiLOfuX9Lvic9JYiATA7YzypABedVh9syYjia0DfEQ67r8OzxZoMNzUIAhGA== X-Received: by 2002:a17:907:1b24:: with SMTP id mp36mr1799491ejc.519.1644592650936; Fri, 11 Feb 2022 07:17:30 -0800 (PST) Received: from smtpclient.apple ([2001:984:65b0:2:dde3:713a:6720:7c0c]) by smtp.gmail.com with ESMTPSA id ko9sm5696341ejc.60.2022.02.11.07.17.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Feb 2022 07:17:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: James In-Reply-To: <054f7a17-d8df-42a6-9d36-0f3aca00c159@beta.fastmail.com> Date: Fri, 11 Feb 2022 16:17:29 +0100 Cc: httpapi@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <15FBD3E4-D303-4E97-BAC2-7D06DBF4A286@gmail.com> References: <054f7a17-d8df-42a6-9d36-0f3aca00c159@beta.fastmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3693.40.0.1.81) Archived-At: Subject: Re: [httpapi] Using Date in requests X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2022 15:17:41 -0000 Hi Martin, Thanks for writing this up. I'm unsure if this was discussed elsewhere, = but another consideration about the Date header is its off-label use for = rough time synchronisation - in particular, phk wrote an = implementation[1], and later a rough specification[2] with an entry in = the well-known registry[3] using a different header aimed to either = synchronise, or validate a local clock. I both hope and doubt nobody is = using this approach, but its existence leads me to think that some = overall guidance on how people transmit time information more broadly in = HTTP messages and rely on it might be helpful for your audience. Happy = to help write that. - J 1: http://phk.freebsd.dk/time/20151212/ 2: http://phk.freebsd.dk/time/20151129/ 3: = https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml > On 9 Feb 2022, at 06:29, Martin Thomson wrote: >=20 > Hi Everyone, >=20 > I've just posted = https://www.ietf.org/archive/id/draft-thomson-httpapi-date-requests-00.htm= l which talks about how to use Date in requests. This is not a typical = thing you see, but some of the things we're doing elsewhere makes this = relevant. For example, signing requests [1] and oblivious HTTP [2] - = depending on circumstances - might want to use Date for managing = anti-replay. >=20 > I'm bring this here as I think that this group has more direct = expertise and the work is related to some of the other stuff you are = doing, like the idempotency-key, which is complementary. This also uses = the problem details work (RFC 7807bis) for signaling when Date is = missing or incorrect. >=20 > I'm happy to go into the use case in more detail if the content of the = draft isn't clear enough. Mostly, I'm just doing this so there is a = complete and robust solution for how to manage replay for the = aforementioned work. >=20 > Cheers, > Martin >=20 >=20 > [1] = https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.h= tml > [2] = https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html >=20 > --=20 > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi From nobody Sun Feb 13 15:19:52 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3623A09D0 for ; Sun, 13 Feb 2022 15:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=VpgqWFht; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TNKLpZ8P 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 0Fvq7VCZokCq for ; Sun, 13 Feb 2022 15:19:45 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9506C3A09C1 for ; Sun, 13 Feb 2022 15:19:45 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id DD5525C01AC; Sun, 13 Feb 2022 18:19:44 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Sun, 13 Feb 2022 18:19:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:cc:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; bh=hFh/yrKTfp3bMvJh4/01K36u4VirrZ fVxc4WcxBGi4Q=; b=VpgqWFhtkM8vA2paZugVwUxo1Xv9Y+YOV88/oOt/leGU0I ChPe/EuG0Uba6k+g2x0ZN1xG7DYHq2tzor6c7OGpT7NVkowRYytSKifyQwjgmJTW me23Ja6EYgeqeXqiRttLyQcQ2v1tKbQAm/kEcuQlvRMQ5MlmdyutUMxlT0OGVJA6 hiQr83lDI7QKl3Dp6spMQgJomDL/jjSxuqNNM/40pHA4WUT2/2JeyaFt8lTEgFtf 4ZK12E4h00Dbo7nK4eg5+YD3yKOaWzlZv12ooxd2imYHIzgUHq72H0lcUll5MhCk Y+SUfKvxNeaYJuTgJ3gKLfZRGSjj0ae1YVP3E66w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=hFh/yrKTfp3bMvJh4 /01K36u4VirrZfVxc4WcxBGi4Q=; b=TNKLpZ8PUYvb0JE8gSRaYP7LYksQYiYEq lBdu2q6yv35fNtMthKM/rAMbPo9pBEM8SaQdyWLGhpU3uLwf6H2w7bHkdab8gQ52 nmoVKgKeDN6h92VVB4YUqPVdLIXBAgNMhTtxQGEF0c/figbQlkDUn6onrH3hvDYt X0GNH6XoSyBbe+jEhpzI3cOvHCGO0OgVv26T1TKEqb78EwJtDVycj7v4CMMqiMt2 kTtpCF/5Yy9KAXjkul+VPNapviaHaOX3/tBBKGjy78GRij3zlFGuAhb8jhqRKAXO bLRtaBJmeyma/ILknexRYKU+9DCOtp6YHK7/tdUwtbtzxtpgzqMbg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrjedugddtlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtf frrghtthgvrhhnpeetieefffdvudfhleekvdfhteejgffggfeggeetuddvtdfhuedtvdej ueefudehveenucffohhmrghinhepfhhrvggvsghsugdrughkpdhirghnrgdrohhrghdpih gvthhfrdhorhhgpdhhthhtphifghdrohhrghdpghhithhhuhgsrdhiohenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrh hophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B3E733C0F92; Sun, 13 Feb 2022 18:19:44 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4748-g31a5b5f50e-fm-cal2020-20220204.001-g31a5b5f5 Mime-Version: 1.0 Message-Id: <2882ef9e-06c9-432f-8538-e292a9f9a75d@beta.fastmail.com> In-Reply-To: <15FBD3E4-D303-4E97-BAC2-7D06DBF4A286@gmail.com> References: <054f7a17-d8df-42a6-9d36-0f3aca00c159@beta.fastmail.com> <15FBD3E4-D303-4E97-BAC2-7D06DBF4A286@gmail.com> Date: Mon, 14 Feb 2022 10:19:27 +1100 From: "Martin Thomson" To: "james.ietf@gmail.com" Cc: httpapi@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [httpapi] Using Date in requests X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2022 23:19:51 -0000 Yeah, it seems like this is one of the major revelations from this discussion. That is, that times (or dates) might appear in multiple places and the considerations here aren't limited to the Date field. Any input regarding text would be greatly appreciated. I'll get around to doing something eventually, but my todo list keeps growing. On Sat, Feb 12, 2022, at 02:17, James wrote: > Hi Martin, > Thanks for writing this up. I'm unsure if this was discussed elsewhere, > but another consideration about the Date header is its off-label use > for rough time synchronisation - in particular, phk wrote an > implementation[1], and later a rough specification[2] with an entry in > the well-known registry[3] using a different header aimed to either > synchronise, or validate a local clock. I both hope and doubt nobody is > using this approach, but its existence leads me to think that some > overall guidance on how people transmit time information more broadly > in HTTP messages and rely on it might be helpful for your audience. > Happy to help write that. > > - J > > 1: http://phk.freebsd.dk/time/20151212/ > 2: http://phk.freebsd.dk/time/20151129/ > 3: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml > >> On 9 Feb 2022, at 06:29, Martin Thomson wrote: >> >> Hi Everyone, >> >> I've just posted https://www.ietf.org/archive/id/draft-thomson-httpapi-date-requests-00.html which talks about how to use Date in requests. This is not a typical thing you see, but some of the things we're doing elsewhere makes this relevant. For example, signing requests [1] and oblivious HTTP [2] - depending on circumstances - might want to use Date for managing anti-replay. >> >> I'm bring this here as I think that this group has more direct expertise and the work is related to some of the other stuff you are doing, like the idempotency-key, which is complementary. This also uses the problem details work (RFC 7807bis) for signaling when Date is missing or incorrect. >> >> I'm happy to go into the use case in more detail if the content of the draft isn't clear enough. Mostly, I'm just doing this so there is a complete and robust solution for how to manage replay for the aforementioned work. >> >> Cheers, >> Martin >> >> >> [1] https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html >> [2] https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html >> >> -- >> httpapi mailing list >> httpapi@ietf.org >> https://www.ietf.org/mailman/listinfo/httpapi From nobody Mon Feb 14 00:45:22 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBA93A0C97 for ; Mon, 14 Feb 2022 00:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 fb5i_Q7Yv_2V for ; Mon, 14 Feb 2022 00:45:15 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 2ECC23A0C87 for ; Mon, 14 Feb 2022 00:45:15 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id y84so19071751iof.0 for ; Mon, 14 Feb 2022 00:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zgfL9WswNM/JssionSLMY5kWzdODTFmv0p2jujv+J0Q=; b=AtzOqI/+FLLuhvYXDPrjZPBfVVrmXsbiM1crpmDhx6J4U7fcnJcwbH18XtU3LR03Nh sLRiebtNV8xegqfrKSay/NM8Hhm3vyEE1C3ObP4nQ3rMnZ63kcb3oL9vowRcf2JloP5N J1Dx0kbsfG9FhwZwkkcJd26KfEpd4a0gx/GT6kbd+fUV/npl6e08aJ0fVLfY6GVM+DU+ ctp+WgIIljx9k/csYR+kkiOAE+TxA2S2W7QqCVwssgkzpqI/ZEpidHlsaZITzomG5Iqr KJ4y33WVU5WFZ/prg1CuK9AN3NLeq6SgVZ8qENSpZFVcvr3BZiQOo0OAvJgdtMA4jiip ZmRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zgfL9WswNM/JssionSLMY5kWzdODTFmv0p2jujv+J0Q=; b=v10Up6H2XH0XoZ6UYSHYFyXE+B53+FXxU0l/KweCeq8Q9Dr6JqHmv8jGTUXMN8zcWm dLd2wUAcPBNvjrOuq+JfDrncf+EljX8IblXXFALiVifwaG75vPynen+V/NEUwzvLaL/h hq2mqyASwsBN3rO5J0GPLfnSS/BnQChNtB56WQso+0k5pvGIZlSwxmEianF0KRn42LcU WrjaHMv5dz8dCMxXR1bJCaP+SFnN+JlDpjFzRq/rI8YwZj0kH7ZYjZOEqNghezBszXwO uoZD8ioHGJIKB1XFLtaazS5+Cye+n6S6ur/O9MqTJRSTbMWhgncLKZjNPQCTvU2pzBda AxDg== X-Gm-Message-State: AOAM531EE0I8UgW9FPh81kIky+dJx8jH6X5lL/Jw0qv1O/br9AelGTPs V/nrYY/RMMWbmrf8SpxG3B7o5VX/rEspkivXZ2OKQXTo8ezIpw== X-Google-Smtp-Source: ABdhPJwlKGem9Pj/FwfCL6gYh76CAFwleoYpObrfIqmHjctd0AaBAFg9MjBKukuqFDAnAxKyO3Ik+/BeZ3k3oVyTAHM= X-Received: by 2002:a05:6602:2a48:: with SMTP id k8mr6596413iov.147.1644828313384; Mon, 14 Feb 2022 00:45:13 -0800 (PST) MIME-Version: 1.0 References: <054f7a17-d8df-42a6-9d36-0f3aca00c159@beta.fastmail.com> In-Reply-To: <054f7a17-d8df-42a6-9d36-0f3aca00c159@beta.fastmail.com> From: Herbert Van de Sompel Date: Mon, 14 Feb 2022 09:45:02 +0100 Message-ID: To: Martin Thomson Cc: HTTP APIs Working Group Content-Type: multipart/alternative; boundary="00000000000055fa6805d7f66fc7" Archived-At: Subject: Re: [httpapi] Using Date in requests X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 08:45:22 -0000 --00000000000055fa6805d7f66fc7 Content-Type: text/plain; charset="UTF-8" Dear Martin, Probably not really relevant for you but the Memento "Time Travel for the Web" protocol [1] uses dates in requests using the Accept-Datetime header as a means to do content negotiation in the datetime dimension. The major motivation for devising the protocol was achieving a level of interoperability across web archives. But the protocol can be supported by all systems that support datetime-based resource versioning such as wikis etc. Greetings Herbert Van de Sompel [1] HTTP framework for time-based access to resource states - Memento. Herbert Van de Sompel, Michael L. Nelson, Robert Sanderson. RFC 7089. http://www.rfc-editor.org/rfc/rfc7089.txt On Wed, Feb 9, 2022 at 6:30 AM Martin Thomson wrote: > Hi Everyone, > > I've just posted > https://www.ietf.org/archive/id/draft-thomson-httpapi-date-requests-00.html > which talks about how to use Date in requests. This is not a typical thing > you see, but some of the things we're doing elsewhere makes this relevant. > For example, signing requests [1] and oblivious HTTP [2] - depending on > circumstances - might want to use Date for managing anti-replay. > > I'm bring this here as I think that this group has more direct expertise > and the work is related to some of the other stuff you are doing, like the > idempotency-key, which is complementary. This also uses the problem > details work (RFC 7807bis) for signaling when Date is missing or incorrect. > > I'm happy to go into the use case in more detail if the content of the > draft isn't clear enough. Mostly, I'm just doing this so there is a > complete and robust solution for how to manage replay for the > aforementioned work. > > Cheers, > Martin > > > [1] > https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html > [2] > https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html > > -- > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi > -- ================== Herbert Van de Sompel https://hvdsomp.info https://orcid.org/0000-0002-0715-6126 --00000000000055fa6805d7f66fc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Martin,

Probably not re= ally relevant for you but the Memento "Time Travel for the Web" p= rotocol [1] uses dates in requests using the Accept-Datetime header as a me= ans to do content negotiation in the datetime dimension. The major motivati= on for devising the protocol was achieving a level of interoperability acro= ss web archives. But the protocol can be supported by all systems that supp= ort datetime-based resource versioning such as wikis etc.

Greetings

Herbert Van de Sompel
=
[1] HTTP framework for time-based access to resource states = - Memento.=20 Herbert Van de Sompel, Michael L. Nelson, Robert Sanderson. RFC 7089. http://www.rfc-editor.org/= rfc/rfc7089.txt

On Wed, Feb 9, 2022 at 6:30 AM Martin Thomson= <mt@lowentropy.net> wrote:<= br>
Hi Everyone,

I've just posted http= s://www.ietf.org/archive/id/draft-thomson-httpapi-date-requests-00.html= which talks about how to use Date in requests.=C2=A0 This is not a typical= thing you see, but some of the things we're doing elsewhere makes this= relevant.=C2=A0 For example, signing requests [1] and oblivious HTTP [2] -= depending on circumstances - might want to use Date for managing anti-repl= ay.

I'm bring this here as I think that this group has more direct expertis= e and the work is related to some of the other stuff you are doing, like th= e idempotency-key, which is complementary.=C2=A0 This also uses the problem= details work (RFC 7807bis) for signaling when Date is missing or incorrect= .

I'm happy to go into the use case in more detail if the content of the = draft isn't clear enough.=C2=A0 Mostly, I'm just doing this so=C2= =A0 there is a complete and robust solution for how to manage replay for th= e aforementioned work.

Cheers,
Martin


[1] https://httpwg.org/= http-extensions/draft-ietf-httpbis-message-signatures.html
[2] https://ietf-wg-ohai.git= hub.io/oblivious-http/draft-ietf-ohai-ohttp.html

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


--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Herbert Va= n de Sompel
--00000000000055fa6805d7f66fc7-- From nobody Mon Feb 14 01:22:51 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278E43A0D50 for ; Mon, 14 Feb 2022 01:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.101 X-Spam-Level: X-Spam-Status: No, score=-7.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=VtGQCdVq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=h3LnuB6t 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 p6rVFKKKn70e for ; Mon, 14 Feb 2022 01:22:41 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815293A0E42 for ; Mon, 14 Feb 2022 01:22:31 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id ADF8F5C0120; Mon, 14 Feb 2022 04:22:30 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Mon, 14 Feb 2022 04:22:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:cc:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; bh=sKdnSdG86YewF1//92YepUfwksM0sA QPIrGOKBtx3DM=; b=VtGQCdVqIj9nkGy/bKWQM7F798DQ22Dc4TsWhhJ2v95+20 AYB9y0DF7zYNrTF11ziJXZdMaOkKBLZQM4P7mqto6w4pkyFcxsW6pSuwBqEfrZiA NWY1+O6YYZT1oMW43RLQSxrm5830jKChXCh41rdm6Ci0GxsC6ZBEdzZ5TG9ABt1i d7eXbsVSq7xc8OMvov0Z3b/LzUuyzHXLK7HIT7p4mvhrvThqVA/7kaO9OcUMAABD IIDfxLQIxphBlq5BY0lFs09k/Hn81M4nHU02AkZPvuVXByN8Uzb2gQwon3nrZol+ M+6TOLoyoIz2IKp3BcQmMuUlD7U+9Y37+4O0F+iA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=sKdnSdG86YewF1//9 2YepUfwksM0sAQPIrGOKBtx3DM=; b=h3LnuB6t1dwHPApYxKR4C92PTMzw3o52D Bmv7BDWbRJLScjVisvJbGFZCY/ecpOLcNmTlu1wrQcipXuXgDIk9WrQo0Qps0Jb2 AhwD93rmGFBdAQV4h0dbWUQNVvYwM5Ma0t6CNry77zOcs9QT9EQJg9LgQejzrFCx vSK/AwkIYUKIq4CLS17qP+wqSo/wv0nulDZa1eosCWf0wtglWtam2n0BV2sRruC1 0f9eF1mx549RZISL9+nzUOvmkM/YKsgZA21dAYv7jr049FKeB6O2nA80OzAyXZgP gxF60OzuxuN+fgoQgfa5p6TX0N0JeGYD7wW9iJejUYhC7HtGgx5SQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrjedugddufedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepkeetueeikedtkeelfeekvefhkeffvedvvefgkefgleeugfdvjeej geffieegtdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5FF7B3C00CF; Mon, 14 Feb 2022 04:22:30 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4748-g31a5b5f50e-fm-cal2020-20220204.001-g31a5b5f5 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <054f7a17-d8df-42a6-9d36-0f3aca00c159@beta.fastmail.com> Date: Mon, 14 Feb 2022 20:22:13 +1100 From: "Martin Thomson" To: "Herbert Van de Sompel" Cc: "HTTP APIs Working Group" Content-Type: text/plain Archived-At: Subject: Re: [httpapi] Using Date in requests X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 09:22:50 -0000 On Mon, Feb 14, 2022, at 19:45, Herbert Van de Sompel wrote: > Probably not really relevant for you but the Memento "Time Travel for > the Web" protocol [1] Yeah, this is a different thing entirely. I might tweak the text to make that clearer. Memento asks about arbitrary times (with Accept-Datetime), whereas this is intended to capture the value of *now* and to address the problems that can arise when attempting to do that. From nobody Sun Feb 20 00:16:29 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330303A0EF5 for ; Sun, 20 Feb 2022 00:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=mnot.net header.b=Olh+AGXn; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=messagingengine.com header.b=iOE8DIuA 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 n2ym6px9VgKZ for ; Sun, 20 Feb 2022 00:15:55 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615EB3A0EFA for ; Sun, 20 Feb 2022 00:15:55 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id D3FD43200E42 for ; Sun, 20 Feb 2022 02:39:14 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 20 Feb 2022 02:39:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-type:date:from:from:in-reply-to:mime-version:reply-to :sender:subject:subject:to:to; s=fm2; bh=lFluJjUhAEAY3wX6c3CcnMr 4a0px7WuNfylgy6lTUBA=; b=Olh+AGXnFc+BTck4UCmjQ9Agky1B+k6STxexykK 3Yd1FqoduLY3NV7Jny7iOt7zIZHJQo8pS8AX5PGHblx3bGKGi+9z8eMrTYblHYXs jX0nVzXq3lTI47IgvUmOel0XM5TQ6Z8GLb8mZZgkjecX4stIMyTeJzAWtMcYqijz i7HwV1s+Ic63BreFsDuXMub89CsupUZvhNGE/B99lgVNW9E85HGIEUm3xtG2P3/8 UZUNPP90ecvcp3Zqy3qOtoRq19CHAs19sQjcwa90+ibDGaFWg3Bl67bsoyL2KbjU DUDqwEt6K37m/ExJlCh46Cggp1waLkIF5fzKx9zgJHoJIMA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:from :in-reply-to:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=lFluJjUhAEAY3wX6c3CcnMr4a0px7WuNfylgy6lTUBA=; b=iOE8DIuA ssn5rAEv1YaEppASmeLwUuzK1MMNAUO4qHip75klzrLAXmmrAPyVFQY+rpU09Fru eo0NNpp5B0MmbFe4tOMGEMTelYOKCbbCl3tRHx8flCn9B86gDCh/jTT4tF6EmBUZ G6jbCap1tEmUEwk4JXlf9o4Eqa8jnblxMA9EMjkD2s5PMpEbD5Kolwu+Fl0GXg4d uwmD9GmmnkUWBRIoItjOUdFecCKKBbeaAJ2keS0AkJb4IFVa3h5iU1N2JqDjElVF cKLKdkwYmYwXwVVHJ26+RZlnZzPGkKzn+I6B2KsisuWtXAO1tj/EsU9ONcp7YBvP sV9PUB7Lwezjjg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrkeefgddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 20 Feb 2022 02:39:14 -0500 (EST) Content-Type: multipart/alternative; boundary="===============6478372806416660369==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: httpapi@ietf.org Message-Id: <20220220081555.615EB3A0EFA@ietfa.amsl.com> Date: Sun, 20 Feb 2022 00:15:55 -0800 (PST) Archived-At: Subject: [httpapi] Weekly github digest (HTTPAPI WG Activity Summary) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2022 08:16:01 -0000 --===============6478372806416660369== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-httpapi/rfc7807bis (+0/-0/=F0=9F=92=AC1) 1 issues received 1 new comments: - #10 JSON-LD Context (1 by ioggstream) https://github.com/ietf-wg-httpapi/rfc7807bis/issues/10=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-httpapi/ratelimit-headers * https://github.com/ietf-wg-httpapi/wg-materials * https://github.com/ietf-wg-httpapi/idempotency * https://github.com/ietf-wg-httpapi/rfc7807bis * https://github.com/ietf-wg-httpapi/linkset * https://github.com/ietf-wg-httpapi/deprecation-header --===============6478372806416660369== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (HTTPAPI WG Activity Summary)

Sunday February 20, 2022

Events without label "editorial"

Issues

ietf-wg-httpapi/rfc7807bis (+0/-0/=F0=9F=92=AC1)

1 issues received 1 new comments:

Repositories tracked by this digest:
--===============6478372806416660369==-- From nobody Tue Feb 22 08:35:24 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2F63A0C46 for ; Tue, 22 Feb 2022 08:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.627 X-Spam-Level: X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Md0knuf3j-Ad for ; Tue, 22 Feb 2022 08:35:17 -0800 (PST) Received: from smtp.lax.icann.org (smtp.lax.icann.org [IPv6:2620:0:2d0:201::1:81]) (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 1F5D33A0C03 for ; Tue, 22 Feb 2022 08:35:17 -0800 (PST) Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp.lax.icann.org (Postfix) with ESMTP id 6D50DE8533; Tue, 22 Feb 2022 16:35:15 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id 4416020905; Tue, 22 Feb 2022 16:35:15 +0000 (UTC) RT-Owner: sabrina.tanamal From: "Sabrina Tanamal via RT" Reply-To: drafts-expert-review@iana.org In-Reply-To: References: <51EA85FA-E6D5-483C-BA6A-7B4A96E99D3A@acm.org> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1222622 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: sabrina.tanamal@icann.org CC: algermissen@acm.org, julian.reschke@greenbytes.de, mnot@mnot.net, httpapi@ietf.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Tue, 22 Feb 2022 16:35:15 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [httpapi] [IANA #1222622] expert review for draft-ietf-httpapi-linkset (link-relations) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2022 16:35:22 -0000 Hi Jan, Mark and Julian (cc: httpapi WG), I'm not sure if a re-review is required for this document, but you reviewed version -06, and now it's on version -08. Can you confirm that this is still OK? https://datatracker.ietf.org/doc/draft-ietf-httpapi-linkset/ Thanks, Sabrina Tanamal Lead IANA Services Specialist On Mon Jan 17 21:18:39 2022, algermissen@acm.org wrote: > Hi Sabrina, > > the registration looks good to me. > > (I must admit it took three turns to parse that sentence "The link > target of a link with the "linkset" relation type provides a set of > links, including links in which the link context of the link > participates." but the logic checks out as far as I can tell :-) > > Cheers, > > Jan > > > > On 17. Jan 2022, at 21:43, Sabrina Tanamal via RT > review-comment@iana.org> wrote: > > > > Mark, Julian and Jan, > > > > As the designated experts for the Link Relation Types registry, can > > you review the proposed registration in draft-ietf-httpapi-linkset > > for us? Please see > > > > https://datatracker.ietf.org/doc/draft-ietf-httpapi-linkset/ > > > > If this is OK, when the IESG approves the document for publication, > > we'll make the registration at > > > > https://www.iana.org/assignments/link-relations > > > > The IESG has asked us to set a two-week deadline for registration > > reviews. The due date for this request is January 31st. > > > > thanks, > > > > Sabrina Tanamal > > Lead IANA Services Specialist > > From nobody Tue Feb 22 09:35:07 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96613A1163 for ; Tue, 22 Feb 2022 09:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2Xx2M8GECL4 for ; Tue, 22 Feb 2022 09:34:59 -0800 (PST) Received: from mxout014.mail.hostpoint.ch (mxout014.mail.hostpoint.ch [IPv6:2a00:d70:0:e::314]) (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 A74D83A07E2 for ; Tue, 22 Feb 2022 09:34:58 -0800 (PST) Received: from [10.0.2.45] (helo=asmtp012.mail.hostpoint.ch) by mxout014.mail.hostpoint.ch with esmtp (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1nMZ3s-0008Si-2A; Tue, 22 Feb 2022 18:34:52 +0100 Received: from [185.110.187.108] (helo=[192.168.1.167]) by asmtp012.mail.hostpoint.ch with esmtpa (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nMZ3r-000Kyh-Us; Tue, 22 Feb 2022 18:34:52 +0100 X-Authenticated-Sender-Id: erik.wilde@dret.net Message-ID: <5844e3c6-1514-1606-2de5-37342ffd8cf2@dret.net> Date: Tue, 22 Feb 2022 18:34:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: drafts-expert-review@iana.org Cc: httpapi@ietf.org, mnot@mnot.net, algermissen@acm.org, julian.reschke@greenbytes.de References: <51EA85FA-E6D5-483C-BA6A-7B4A96E99D3A@acm.org> From: Erik Wilde In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [httpapi] [IANA #1222622] expert review for draft-ietf-httpapi-linkset (link-relations) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2022 17:35:05 -0000 hello all. On 2022-02-22 17:35, Sabrina Tanamal via RT wrote: > I'm not sure if a re-review is required for this document, but you reviewed version -06, and now it's on version -08. Can you confirm that this is still OK? > https://datatracker.ietf.org/doc/draft-ietf-httpapi-linkset/ because this is partly my fault: changing from -06 to -07 was to change the status from informational to standard. and then i made a mistake while submitting and had to submit again, which is why there now is -08. cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Tue Feb 22 09:37:49 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E093A3A0845 for ; Tue, 22 Feb 2022 09:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=akamai.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 zAlHg5M6Yc88 for ; Tue, 22 Feb 2022 09:37:42 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 9B24B3A0806 for ; Tue, 22 Feb 2022 09:37:40 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 21MEv0O9028717; Tue, 22 Feb 2022 17:37:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=UPtmHg7AcD9SPkhZNFKinXR5PtmYkdV4bRJ0IhNLIEM=; b=f49jKbr780vm2EqwVsBva9uAMHZQUK4LDRyVTXqVbCSZIAO4VwoXxWgHClfLs9/t5yGW WW2syXEbCBtRzDAYizAn3pnqWFJPaF48cjctmw0cTucVz14SpdixVY7tcDsncR24WHh1 TmCK+Ux57gxKoBOV8iPH2bmXT3jX+YGvLZbLF0rAa9V2SJrNE79HUaSwg8Fv46Etsuo4 FSbzMMfjCpJb4CbyZd/CkgMoI/m9McoplcL4Mke66c9wuDwjkjOsD9ivlM1r4WFEBXrv 1DgPZKeFAz6HU7DrL5biUY/dkuQTjetoB5VdbZujemZA4vt69jBh/4cgxy1JHg0NLD2R 0w== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com (PPS) with ESMTPS id 3ecug9epqb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Feb 2022 17:37:07 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 21MHYDsd012329; Tue, 22 Feb 2022 12:37:06 -0500 Received: from email.msg.corp.akamai.com ([172.27.91.20]) by prod-mail-ppoint1.akamai.com with ESMTP id 3eavs2wacb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Feb 2022 12:37:06 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.165.120) by usma1ex-dag4mb3.msg.corp.akamai.com (172.27.91.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.922.20; Tue, 22 Feb 2022 12:37:05 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Tue, 22 Feb 2022 11:37:05 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.028; Tue, 22 Feb 2022 11:37:04 -0600 From: "Salz, Rich" To: Erik Wilde , "drafts-expert-review@iana.org" CC: "algermissen@acm.org" , "mnot@mnot.net" , "httpapi@ietf.org" , "julian.reschke@greenbytes.de" Thread-Topic: [httpapi] [IANA #1222622] expert review for draft-ietf-httpapi-linkset (link-relations) Thread-Index: AQHYKAo2llJMnvCXX0myzoqO8lEoYKygOX6A//+sygA= Date: Tue, 22 Feb 2022 17:37:03 +0000 Message-ID: References: <51EA85FA-E6D5-483C-BA6A-7B4A96E99D3A@acm.org> <5844e3c6-1514-1606-2de5-37342ffd8cf2@dret.net> In-Reply-To: <5844e3c6-1514-1606-2de5-37342ffd8cf2@dret.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.58.22021501 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.118.139] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-02-22_05:2022-02-21, 2022-02-22 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=581 bulkscore=0 malwarescore=0 spamscore=0 adultscore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202220107 X-Proofpoint-GUID: guCV8SCiLx2yc-FaVztU9QP00SeB-mW2 X-Proofpoint-ORIG-GUID: guCV8SCiLx2yc-FaVztU9QP00SeB-mW2 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-22_05,2022-02-21_02,2021-12-02_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 priorityscore=1501 adultscore=0 mlxlogscore=565 suspectscore=0 phishscore=0 spamscore=0 malwarescore=0 bulkscore=0 impostorscore=0 lowpriorityscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202220107 Archived-At: Subject: Re: [httpapi] [IANA #1222622] expert review for draft-ietf-httpapi-linkset (link-relations) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2022 17:37:47 -0000 SW4gb3RoZXIgd29yZHMsIGR1ZSB0byBiYWQgcmV2aWV3IGJ5IHRoZSBXRyBjaGFpciAoZXIsIG1l KSwgdGhlIG9ubHkgZGlmZmVyZW5jZSBiZXR3ZWVuIC0wNiBhbmQgLTA4IGlzIHRoYXQgaXQgbW92 ZWQgZnJvbSBpbmZvcm1hdGlvbmFsIHRvIHByb3Bvc2VkIHN0YW5kYXJkLg0KDQoNCg== From nobody Fri Feb 25 17:38:48 2022 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 335A43A0E38; Fri, 25 Feb 2022 17:29:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: francesca.palombini@ericsson.com, httpapi@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164583895719.24617.6730995197488765116@ietfa.amsl.com> Date: Fri, 25 Feb 2022 17:29:17 -0800 Archived-At: Subject: [httpapi] httpapi - Requested session has been scheduled for IETF 113 X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2022 01:29:26 -0000 Dear Rich Salz, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. httpapi Session 1 (2:00 requested) Thursday, 24 March 2022, Morning Session I 1000-1200 Room Name: Grand Park Hall 2 size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/113/sessions/httpapi.ics Request Information: --------------------------------------------------------- Working Group Name: Building Blocks for HTTP APIs Area Name: Applications and Real-Time Area Session Requester: Rich Salz Number of Sessions: 1 Length of Session(s): Number of Attendees: 150 Conflicts to Avoid: People who must be present: Darrel Miller Francesca Palombini Mark Nottingham Rich Salz Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Feb 27 05:32:01 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FD53A10B3; Sun, 27 Feb 2022 05:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 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, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-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=akamai.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 1SVadiB9dG8v; Sun, 27 Feb 2022 05:31:54 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 432ED3A10B2; Sun, 27 Feb 2022 05:31:51 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 21RBnxSa001762; Sun, 27 Feb 2022 13:31:46 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ygYP8jlKcR5aLF3/l5q0xpEcAcJ15CNlIMI26i58HzE=; b=fhlLK3P3XC/KSGKWaoZ5oFciBwm7DiP1j/CvSd4kBL2MaJIxS3bSYtT0OwT8mR21Gp/v +8ycd4UPFGULBqeWP4D0YxoQ7JGYRtRjMXqrXPiBeme1GkmNqe6AMP6ok1AeaHh13YmR +4AQmCakc2eqSj1VoI2e3erNeTbCB7qNG3h1dlFq4Vcyh0tG/IV2eeCQkLMETLUpsBRk VPfPzN+ye3c0+86MR3cbC2rlaTXMZN1CkrHNs8MMlQpqw90+6zx1lEBaYJ8lAUbOAE0V Y2thJ7mgxC59o8erS49/PEihSjKxPVUcYfZAiLOrX4AV4HIHTVDcrRIau35PRYYMx4lP +A== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0a-00190b01.pphosted.com (PPS) with ESMTPS id 3efcbdeee2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 27 Feb 2022 13:31:45 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 21RDJLx6027564; Sun, 27 Feb 2022 05:31:44 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint5.akamai.com with ESMTP id 3efk2f1wj0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 27 Feb 2022 05:31:44 -0800 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by usma1ex-dag4mb1.msg.corp.akamai.com (172.27.91.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.922.20; Sun, 27 Feb 2022 08:31:43 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Sun, 27 Feb 2022 07:31:42 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.028; Sun, 27 Feb 2022 07:31:42 -0600 From: "Salz, Rich" To: "httpapi-chairs@ietf.org" , "francesca.palombini@ericsson.com" CC: "httpapi@ietf.org" Thread-Topic: HTTPAPI folks: will you be in Vienna? Thread-Index: AQHYK95bFcd2BkATvk6v873d6AABeA== Date: Sun, 27 Feb 2022 13:31:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.58.22021501 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: <6D0D0A88F4205C4F9BCBB2CF30DA965F@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-02-27_05:2022-02-26, 2022-02-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 mlxscore=0 mlxlogscore=776 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202270094 X-Proofpoint-GUID: Bo4SvJlAd9lMuUbPCqAS5ZZgcjQN31LX X-Proofpoint-ORIG-GUID: Bo4SvJlAd9lMuUbPCqAS5ZZgcjQN31LX X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-02-27_05,2022-02-26_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 mlxscore=0 malwarescore=0 phishscore=0 clxscore=1011 priorityscore=1501 suspectscore=0 spamscore=0 adultscore=0 bulkscore=0 impostorscore=0 mlxlogscore=766 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202270094 Archived-At: Subject: [httpapi] HTTPAPI folks: will you be in Vienna? X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2022 13:31:59 -0000 PiAgICBCZWxvdyBpcyB0aGUgc2NoZWR1bGVkIHNlc3Npb24gaW5mb3JtYXRpb24gZm9sbG93ZWQg YnkNCiAgICB0aGUgb3JpZ2luYWwgcmVxdWVzdC4gDQoNCg0KPiAgICAgICAgaHR0cGFwaSBTZXNz aW9uIDEgKDI6MDAgcmVxdWVzdGVkKQ0KICAgICAgICBUaHVyc2RheSwgMjQgTWFyY2ggMjAyMiwg TW9ybmluZyBTZXNzaW9uIEkgMTAwMC0xMjAwDQogICAgICAgIFJvb20gTmFtZTogR3JhbmQgUGFy ayBIYWxsIDIgc2l6ZTogMjAwDQoNCklzIGFueW9uZSBmcm9tIHRoZSBXRyBwbGFubmluZyBvbiBh dHRlbmRpbmcgSUVURiAxMTMgaW4gcGVyc29uPyAgSWYgeW91J3JlIGdvaW5nIHRvIGJlIHJlbW90 ZSwgeW91IERPIE5PVCBuZWVkIHRvIHJlcGx5LiAgQW5kIG9mIGNvdXJzZSwgc2F5aW5nICJZZXMs IEkgd2lsbCIgZG9lcyBub3Qgb2JsaWdhdGUgeW91IHRvIGFueXRoaW5nLCBhbmQgb2YgY291cnNl IGV2ZXJ5b25lIHJlY29nbml6ZXMgdGhhdCBwbGFucyBjb3VsZCBjaGFuZ2UuDQoNCg== From nobody Mon Feb 28 06:03:13 2022 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EC23A1223; Mon, 28 Feb 2022 06:03:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-httpapi-linkset@ietf.org, httpapi-chairs@ietf.org, httpapi@ietf.org, rsalz@akamai.com, rsalz@akamai.com X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <164605698398.11883.11626303105328798443@ietfa.amsl.com> Date: Mon, 28 Feb 2022 06:03:04 -0800 Archived-At: Subject: [httpapi] Robert Wilton's No Objection on draft-ietf-httpapi-linkset-08: (with COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2022 14:03:04 -0000 Robert Wilton has entered the following ballot position for draft-ietf-httpapi-linkset-08: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-httpapi-linkset/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for this document. The overriding question that I had when reading this document (and the shepherd writeup) is why are we defining two formats rather than one, given that defining a single format would seem to increase interop and standardization by obviously forcing everyone to do it only one way. I appreciate that the HTTP Link Document format is simpler, and closer to the "Link" header field, although I note that it is not exactly the same - it still has differences. I also appreciate that the HTTP Link Document format might be slightly easier for humans to read, but how important it that for a link document? Hence, I would prefer to see the IETF just standardizing a single format, but don't feel strongly enough to raise a discuss for it. However, I would suggest trying to expand section 3, or adding another section, to provide more guidance as to when one format should be used in preference to the other. Regards, Rob