From nobody Tue Jun 1 07:46:14 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD013A1AD7; Tue, 1 Jun 2021 07:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, 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_H2=-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=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYmosBOUlfVe; Tue, 1 Jun 2021 07:45:59 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2070.outbound.protection.outlook.com [40.107.22.70]) (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 2AA683A1AAB; Tue, 1 Jun 2021 07:45:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ODSOq8+aHevavlxPMteP4Cgopa1LSEN+WOYG+HUUzOkCtzXx/eRl4kXQo3QPio/jkVUntcNmuIIzghYYiYoyDNo3lO4rLnnZ2N7SJDirERGOpnS3APkcrgCfFQ9xOnuANfjNltkejtVa9/7pwz8kKvMgvZwgVnJ+mpCFAY8zeo0AuKp6WUvP+zPmkiEKv6AfI7nSOiuPWuRBmGSaO/KgKQ0IbVr3JdhaQ1j/HQhzCQRDSuElGA/BdP5xierXcw3t+W69fRZIcBsZBVU/Tc0zej955syqqGC15kjXVPQkA8JxkGzvdVx0DzbY61mSMXniyf47K2UXh9uhvdw8aUVjIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HLgQhmNrZwZYe0s0yq8t20virTkmKghuJiiQfvWKA+0=; b=GiXKWuKrOiVno6C0v5BeNAH+rzrD4DvfEFKsJ04R9DaIu0BNIVdx7LhoZGXqCewcqhk2qpyOnsa1JY+kWpxl+Ha8WNfKPoLE1o1NOnBlFmyg4l65zLhvdEnu6mIqCxoVLqbq4GLbhzI3r1qVJFL11QzV/3385VVjX3E9m+S+QQqaawAaW0LRwyjuYR832lRKmZWR27/ernf/o8k7MI0obOWKto/EY9kQ0UYo00CDUe1wmbP9DzgD3+esYQY2g9EDvNrLMb07vL5wWugMsVoK2zGWnNh/xADhO2/vJrQOeLA2JMbDw2hrg8fIhvXCaszg8tkfsMBMPWu7D1Zflm6fIA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HLgQhmNrZwZYe0s0yq8t20virTkmKghuJiiQfvWKA+0=; b=jOLG3BBvP+lEe/TkdWY1l+bV0hE4/mikIHRQ06Gagm/lTImuqxUV0Dcd5HCo58FOXxxgaYYF+Na1TEy6cMEE/dEP9JXRSJTqex7gDNcfb89gLpLAKXgUcImcsz1H8dUGsh4u2APKeh2bDvpxCSYZm9H2pHGVBRmSms69qMMoVIY= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR07MB3339.eurprd07.prod.outlook.com (2603:10a6:7:35::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.14; Tue, 1 Jun 2021 14:45:54 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::6ce5:7088:a9a8:15d9]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::6ce5:7088:a9a8:15d9%7]) with mapi id 15.20.4195.017; Tue, 1 Jun 2021 14:45:54 +0000 From: Francesca Palombini To: "sedate@ietf.org" CC: "dispatch@ietf.org" Thread-Topic: [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate) Thread-Index: AQHXVu6wZbNI3NXCDEWa+LFR/2FPPKr/XU6A Date: Tue, 1 Jun 2021 14:45:54 +0000 Message-ID: References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> In-Reply-To: <162255609215.5567.6852158423318065168@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050901 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:1ba8:147a:eb00:158c:31b4:f961:de7e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9fd154a6-f998-4c7a-6fe5-08d9250bf58e x-ms-traffictypediagnostic: HE1PR07MB3339: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: K+jjoHAK9jmYd4YLgH6G6cU5cmfIk0noDeXV+/ckL9Oz5JnFSi4XPlEfp8kShYNK6tjLwJHxyj/qjJB7jFmjp9DGc7DaDyYG3dds+uJ4vnNf+SYSk4APC4DiP7+ffNSJJCVWatC5j26XFVsujH2fjzQhNblTxikIapkYDKSr8TF6WQXjARxNR1oin0Dtede4Jre4m0og+gx1Un9hKry97rZuR9IZTudfbU/eAvyJbh6aVi/UhhUUMf3mw/xNwTDggBOA2C1iPw12LTyCtmz4IPacxm3tr9Iw5EdgWukwkwRB0YE4BLZoMt/ZlvMIBMy5zaG2y3SDiSDdae3AlhDNfwhI7ReqIlpqGV3PAlbSst0ZI8ycxCfLEkJyQbwFmzlxdrW2ulKweiDAN7vwEDHkljypp9+gedGhly29K2vOSsVDngOZX89IeK08sSPWgS8nq/K4XWISikb16i05Bb+oprQI4SsGXQqxiZ3BypBTel+dk/GpJBCohg41Sa6axQZFESc9x1IRE3Bhv0Up4yKqlAmRP6zMHs41D7Ic+9DECgR+CFTr8DzJekatgZbhFj8rUPD7qTxRA0gyTOS7pAva1L7l1rmIkpRPs5v3F44s79vooJ/rNeZIhdct/qWzqQnJe3UUkmQdLB4JU/3+2ftXfD5L1KcCvA3/9yaAYAkXcoy/KcNih4DJyN/bXLGSh44Sx3Tc6gIyA6oydKSC7zgxlfERv1dcsf97Cj5EvL7V5rUV56godS1vM/GBbSCQTXKIMhDcpB5LASyjsEG4kXFtRx9ONRsliwLqyAxaMQC/bzVA2c8BAnTesEP+IQSM7lwX x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(64756008)(450100002)(66556008)(66446008)(6506007)(122000001)(5660300002)(6512007)(83380400001)(966005)(4326008)(36756003)(2616005)(6486002)(8936002)(66476007)(44832011)(2906002)(186003)(76116006)(38100700002)(33656002)(66946007)(6916009)(8676002)(71200400001)(86362001)(498600001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?aVBxWEdmTHcyd0t1dm81TkdXejd6NXVtUkNSNW9PaWsxYml1UTBWNWV5OFNY?= =?utf-8?B?THp0UlZCZkpWcWhtSG9ySEhmWlNIa3NJcTllZGVHYzRYOXEzWnpyZVpodTEx?= =?utf-8?B?K28wWFk5dUxkVWNPRWZzbFJNV1BkNUFWUXNhQWhtQ1p3SGZrbHd4YlNyWGV3?= =?utf-8?B?WGpIbkNDM0lUcGRJQldTQVJtNEdhQ3AxbnQ1VUtPUlhkR3I2QTk5ZUR5eitm?= =?utf-8?B?RTdGTC96WkRBeW03K1AwTG1yWXJkb3dvTmNHdUwybUZtcG4wWDgzaEY0Y2or?= =?utf-8?B?QVFWb2orOHZCQmFNbXJaWmNMQjBZcnhGZkJsckJ3OXVVNnUyRkF0MVA3emRk?= =?utf-8?B?cnJ1MWJMdjFxU2Y1ZUV2ZXYzUDBnejRnRDhXcU9TT2YzVG9QbEZoTk1QTHFJ?= =?utf-8?B?eXY0cHBPKzRyUVRlMGZEOGpGMHMxNlU0d2lrZDRHL0pGYjZKQVFrcUhybGcv?= =?utf-8?B?Z1p3dW85N2M5NjcrQXNPdHBvUnJxSmNKb2s0NVJCbG9OYTBaeWJGL0p4cEJ5?= =?utf-8?B?akphWW01Y3RlTU5SWEx1Q0tEUmRnSGtWMEhjZWx2RnY1bm5EV3lPS0lIUm96?= =?utf-8?B?NkRHWGNqTkhtRnpIK3dFN1V6aHk5dDlaVHhwS1lNMDZ2eXkrRHdLVDlEUW5i?= =?utf-8?B?Vk8xb1RzMFpLbDVsYkpvN1I4aHJQVWFWRm5pTHF3ZjFZQmYvSys4N2dIcmVJ?= =?utf-8?B?dHBHRjVFc1p5WGxrd3F5elYrU3lBQWhkWjFxV1ZQbWNOdWUzQjliWklQMDB6?= =?utf-8?B?L0RDemxuR1lubnJucG15dmpxMjZObCs3UGg5dnpuYXFpNGY4UlV2bFU5VS96?= =?utf-8?B?MU5Xa0E3OHJ6NkVoNlNlcGVxdHFOSDh5N1VYWXRiZFltQnJyRmduWGdIeUZJ?= =?utf-8?B?Tkc4UUhGOExmYVZGZHYxWkpiZDEvRy9Vbjk1YkxYRFhsMEZNUVZLbEw3amJy?= =?utf-8?B?ZDE2b0JBSzNZQngxeWk2N2tVejVsbWw0NXRqNyt0bGN3NlBHZ0Y4Q0VxNm9N?= =?utf-8?B?QzhXMFFIeithdGhPelIwdkhneWdHN0VSUVRxdUs4Z1ExSUM1QjZNeTdwN1hp?= =?utf-8?B?KzhJZmVoTnp4bzZoV1NCMkRHS2dGSExwb1NYU2t0WDRQTGtvMkdrblJCczNV?= =?utf-8?B?TjJkZ0h3b2tpZ2NrQ0ZuaHJiRHdGNVFXSWYvZWxsUUM1RlpndHozU3N1VC9I?= =?utf-8?B?dlcrbkwvamJiK1JrQmZORDkzb3k2bTE3K1BDQlJlVXRrT2tJd0dmVU1weExj?= =?utf-8?B?R2lUMGtQY00xNC9aS0JsNkVjZC9NQXFPZjZERTNleG9UNkJrREtYWXV0UHZu?= =?utf-8?B?bEZKY3pIa2RjM2piSGJvU3NxTDUzRGNmQXZqRllPY21kYTA5RHN0WHZLbTgx?= =?utf-8?B?ZDBlbTNUUWU0TWlEZ3ZoNkxpTm5aRyt1UTJ1c0dITnJ3K0JQd0dycnpEdm5D?= =?utf-8?B?Rnk0Rzltc1l6S2EvMzJwaG5UTkpsNlFPZXlFTmlXWEIySWdmeGFpLzhjUzQz?= =?utf-8?B?U1VtYWNTSlI3bEZxbFpjSHhsZHF2bjd2SThZNTg1Q2NYVmlHeDRyUXhkVGkv?= =?utf-8?B?QXkrTVF0eUVncVVZU29vQjJPa3NCQ2VOeUdGbk9tcGdmemVUaTdUNzVhZ25j?= =?utf-8?B?S0ZRNnIySDl3LzE4dzNMTVdsRlFZR0lqK0NhTzQwV1VQMGlPa2xEUmtBUnhN?= =?utf-8?B?V0ZjcWdNT1A3ZDZjOXZSQ3l4empBWExIU05XL2FuNjhHUU9yOVN3SE82alRa?= =?utf-8?B?YU1oa2dTOXZRNXZaTDRhbW1EZmk3a1NZTmw5elZXSTdzc3FPaEhKOWFrVlhZ?= =?utf-8?B?TXdCOWQ2ZzVUdGlhb3JSYTZUT1o3WUNmTDYxU2laK0RQQ3c1NnVseHN4OUY5?= =?utf-8?B?LytSSFNsbE10a0FYOTNLYWxpSm1NZHluT2xwOXAvV2I5Vnc9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <681D923F66B02E44A6E4CA6C74D28FF0@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9fd154a6-f998-4c7a-6fe5-08d9250bf58e X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2021 14:45:54.2187 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7OO1fRh1GlTi43gbKgMBjBG+shFqgznIwt5D13uGGOq1I+G8jP1hN0K4vREmg2z+jp4ckC0JTdZlo0xXMvdPbiyBTQhtHa9SogeFXTvXla7CYvexpyC6xNjb5YiMr5N5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3339 Archived-At: Subject: Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2021 14:46:12 -0000 SGkgYWxsLA0KDQooQ0MgZGlzcGF0Y2ggZm9yIGluZm9ybWF0aW9uKQ0KDQpUaGUgY2hhcnRlciBm b3IgdGhlIFNlZGF0ZSB3b3JraW5nIGdyb3VwIGhhcyBwYXNzZWQgdGhlIGZpcnN0IHBoYXNlIGFu ZCBpcyBub3cgaW4gZXh0ZXJuYWwgcmV2aWV3LiBBZGRpdGlvbmFsbHksIHRoZSBzZWRhdGUgbWFp bGluZyBsaXN0IGhhcyBiZWVuIGNyZWF0ZWQuIERvIGdvIG92ZXIgdGhlcmUgYW5kIHN1YnNjcmli ZSBpZiB5b3UgYXJlIGludGVyZXN0ZWQuDQoNCk5vdyBpcyB0aGUgdGltZSB0byBsZXQgdGhlIElF U0cga25vdyBvZiBhbnkgY29tbWVudCB5b3UgbWlnaHQgaGF2ZSBvbiB0aGUgY2hhcnRlciB0ZXh0 Lg0KDQpJIGFtIGFsc28gbG9va2luZyBmb3Igdm9sdW50ZWVycyB0byBjaGFpciB0aGUgd2cuIEl0 IGlzIG9rIHRvIHZvbHVudGVlciBzb21lb25lIHlvdSB0aGluayB3b3VsZCBiZSBhIGdvb2QgZml0 LiBJIGhvcGUgdGhhdCwgZ2l2ZW4gdGhlIGludGVyZXN0IGluIHRoaXMgd29yaywgd2Ugd2lsbCBu b3QgaGF2ZSBwcm9ibGVtcyBmaW5kaW5nIGNoYWlycywgYnV0IGFzIGEgcmVtaW5kZXI6IHBsZWFz ZSBkbyBjb25zaWRlciB2b2x1bnRlZXJpbmcgaWYgeW91IHN1cHBvcnQgdGhpcyB3b3JrLCBhcyB3 aXRoIG5vIGNoYWlycyB0aGVyZSB3aWxsIGJlIG5vIHdvcmtpbmcgZ3JvdXAuDQoNClBsZWFzZSBy ZXBseSB0byB0aGlzIHRocmVhZCAoZHJvcHBpbmcgdGhlIGRpc3BhdGNoIG1haWxpbmcgbGlzdCks IG9yIHNlbmQgYW4gZW1haWwgdG8gdGhlIElFU0cgKGllc2dAaWV0Zi5vcmcpLCBvciBkaXJlY3Rs eSB0byBtZSB3aXRoIGFueSBjb21tZW50cyBvbiB0aGUgY2hhcnRlciwgb3Igdm9sdW50ZWVyaW5n IGFzIGNoYWlyLg0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg0K77u/T24gMDEvMDYvMjAyMSwgMTY6 MDIsICJTZWRhdGUgb24gYmVoYWxmIG9mIFRoZSBJRVNHIiA8c2VkYXRlLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIGllc2ctc2VjcmV0YXJ5QGlldGYub3JnPiB3cm90ZToNCg0KICAgIEEg bmV3IElFVEYgV0cgaGFzIGJlZW4gcHJvcG9zZWQgaW4gdGhlIEFwcGxpY2F0aW9ucyBhbmQgUmVh bC1UaW1lIEFyZWEuIFRoZQ0KICAgIElFU0cgaGFzIG5vdCBtYWRlIGFueSBkZXRlcm1pbmF0aW9u IHlldC4gVGhlIGZvbGxvd2luZyBkcmFmdCBjaGFydGVyIHdhcw0KICAgIHN1Ym1pdHRlZCwgYW5k IGlzIHByb3ZpZGVkIGZvciBpbmZvcm1hdGlvbmFsIHB1cnBvc2VzIG9ubHkuIFBsZWFzZSBzZW5k IHlvdXINCiAgICBjb21tZW50cyB0byB0aGUgSUVTRyBtYWlsaW5nIGxpc3QgKGllc2dAaWV0Zi5v cmcpIGJ5IDIwMjEtMDYtMTEuDQoNCiAgICBTZXJpYWxpc2luZyBFeHRlbmRlZCBEYXRhIEFib3V0 IFRpbWVzIGFuZCBFdmVudHMgKHNlZGF0ZSkNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIEN1cnJl bnQgc3RhdHVzOiBQcm9wb3NlZCBXRw0KDQogICAgQ2hhaXJzOg0KICAgICAgVEJEDQoNCiAgICBB c3NpZ25lZCBBcmVhIERpcmVjdG9yOg0KICAgICAgRnJhbmNlc2NhIFBhbG9tYmluaSA8ZnJhbmNl c2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20+DQoNCiAgICBBcHBsaWNhdGlvbnMgYW5kIFJlYWwt VGltZSBBcmVhIERpcmVjdG9yczoNCiAgICAgIE11cnJheSBLdWNoZXJhd3kgPHN1cGVydXNlckBn bWFpbC5jb20+DQogICAgICBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5p QGVyaWNzc29uLmNvbT4NCg0KICAgIE1haWxpbmcgbGlzdDoNCiAgICAgIEFkZHJlc3M6IHNlZGF0 ZUBpZXRmLm9yZw0KICAgICAgVG8gc3Vic2NyaWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NlZGF0ZQ0KICAgICAgQXJjaGl2ZTogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL2Jyb3dzZS9zZWRhdGUvDQoNCiAgICBHcm91cCBwYWdlOiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2dyb3VwL3NlZGF0ZS8NCg0KICAgIENoYXJ0ZXI6IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1zZWRhdGUvDQoNCiAgICBSRkMz MzM5IGRlZmluZXMgYSBmb3JtYXQgdGhhdCBjYW4gcmVsaWFibHkgZXhwcmVzcyBhbiBpbnN0YW50 IGluIHRpbWUsIGVpdGhlcg0KICAgIGluIFVUQyBvciBpbiBhIGxvY2FsIHRpbWUgYWxvbmcgd2l0 aCB0aGUgb2Zmc2V0IGFnYWluc3QgVVRDLiBIb3dldmVyLA0KICAgIGRhdGV0aW1lIGRhdGEgb2Z0 ZW4gaGFzIGFkZGl0aW9uYWwgY29udGV4dCwgc3VjaCBhcyB0aGUgdGltZXpvbmUgb3IgY2FsZW5k YXINCiAgICBzeXN0ZW0gdGhhdCB3YXMgaW4gdXNlIHdoZW4gdGhhdCBpbnN0YW50IHdhcyByZWNv cmRlZC4gUGFydGljdWxhcmx5IHdoZW4NCiAgICB1c2luZyB0aW1lcyBmb3IgaW50ZXJ2YWwsIHJl Y3VycmVuY2UsIG9yIG9mZnNldCBjYWxjdWxhdGlvbnMsIGl0IGlzIG5lY2Vzc2FyeQ0KICAgIHRv IGtub3cgdGhlIGNvbnRleHQgaW4gd2hpY2ggdGhlIHRpbWVwb2ludCBleGlzdHMuDQoNCiAgICBJ dCBpcyB2YWx1YWJsZSB0byBoYXZlIGEgc2VyaWFsaXNhdGlvbiBmb3JtYXQgdGhhdCByZXRhaW5z IHRoaXMgY29udGV4dCBhbmQNCiAgICBjYW4gcmVsaWFibHkgcm91bmQtdHJpcCB0aGUgYWRkaXRp b25hbCBjb250ZXh0IHRvIHN5c3RlbXMgdGhhdCB1bmRlcnN0YW5kIGl0LA0KICAgIHZpYSBpbnRl cm1lZGlhdGUgc3lzdGVtcyB0aGF0IG9ubHkgbmVlZCB0byBrbm93IGFib3V0IHRoZSBpbnN0YW50 IGluIHRpbWUuDQoNCiAgICBUaGUgVEMzOSB3b3JraW5nIGdyb3VwIGF0IEVDTUEgaGF2ZSBkZXZl bG9wZWQgYSBmb3JtYXQgdGhhdCBpcyBhIGdvb2QgYmFzaXMNCiAgICBmb3IgdGhpcyB3b3JrOiBk cmFmdC1yeXpva3VrZW4tZGF0ZXRpbWUtZXh0ZW5kZWQuDQoNCiAgICBJdCBpcyBhbnRpY2lwYXRl ZCB0aGF0IHRoaXMgZG9jdW1lbnQgd291bGQgYmUgYSBjb21wYW5pb24gdG8gUkZDMzMzOSByYXRo ZXINCiAgICB0aGFuIGEgcmVwbGFjZW1lbnQsIGVtYmVkZGluZyBhbiB1bmFsdGVyZWQgUkZDMzMz OSBpbnN0YW50IGFsb25nIHdpdGggdGhlDQogICAgY29udGV4dHVhbCBkYXRhLg0KDQogICAgSXQg aXMgYWxzbyB3aXRoaW4gc2NvcGUgZm9yIHRoaXMgd29ya2luZyBncm91cCB0byBjb25zaWRlciBh IG1pbm9yIHVwZGF0ZSB0bw0KICAgIFJGQzMzMzkgdG8gYWxsb3cgbGFyZ2VyIHRoYW4gZm91ci1k aWdpdCBzaWduZWQgeWVhcnMsIHRvIGVuYWJsZSByZXByZXNlbnRpbmcNCiAgICB0aW1lcyBmdXJ0 aGVyIGludG8gdGhlIHBhc3QgYW5kIGZ1dHVyZS4NCg0KICAgIEl0IGlzIGFudGljaXBhdGVkIHRo YXQgdGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgcHVibGlzaCBvbmUgb3IgdHdvIGRvY3VtZW50cw0K ICAgIG9uIHRoZSB3b3JrIG1lbnRpb25lZCBhYm92ZS4gQWZ0ZXIgdGhhdCwgdGhlIHdvcmtpbmcg Z3JvdXAgd2lsbCBjbG9zZSBkb3duIG9yDQogICAgcmVjaGFydGVyLg0KDQogICAgVGhlIHdvcmtp bmcgZ3JvdXAgd2lsbCBjb29yZGluYXRlIHdpdGggRUNNQSBJbnRlcm5hdGlvbmFsIFRDMzkgYW5k IElTTyBUQzE1NC4NCg0KICAgIE1pbGVzdG9uZXM6DQoNCiAgICAgIERlYyAyMDIxIC0gU3VibWl0 IGV4dGVuZGVkIGRhdGUgYW5kIHRpbWUgZHJhZnQgdG8gdGhlIElFU0cgZm9yIHB1YmxpY2F0aW9u DQoNCg0KDQogICAgLS0gDQogICAgU2VkYXRlIG1haWxpbmcgbGlzdA0KICAgIFNlZGF0ZUBpZXRm Lm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2VkYXRlDQoN Cg== From nobody Wed Jun 2 20:56:28 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1F33A279C for ; Wed, 2 Jun 2021 20:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_KAM_HTML_FONT_INVALID=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=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 UPoa1x0hCFl2 for ; Wed, 2 Jun 2021 20:56:20 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 3C4173A2797 for ; Wed, 2 Jun 2021 20:56:20 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id l25so2290089vsb.9 for ; Wed, 02 Jun 2021 20:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vle/Wu43Gj9gZ158Kr4GofsJU/TVG3E7qNGROToMnlo=; b=QaJ8E60mVdLNVBz+IfGuL+vcddeJcd5Gn+9IEP8oyHx6sAtEYbtlvvs0G9eXFsilV4 OFE6igbRrrVJADu3xo6lS2TCPkV4AiCzeF5q4gPPqVFTmDFI32FIbKg+GQpa4p1f6gO5 6nXiIC/zqr/W+pIZe/CkP/35AXm9QL+A5lY1GnEjRLG8Jk4RXDMtBJafOQiWxdxHo/DO fh84sBa3o5sly2cl+NNG1Bi7KloxAqp0PN2OFSKOEPVas87//Snv1tABpeLl1xI8DUr3 pGBWD2OD8lA40AHRn2/7nExlYgk5ZgVFDNJQZ5hRww0baveK9QbIZ1ra90TGQAU0PHZE C6oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vle/Wu43Gj9gZ158Kr4GofsJU/TVG3E7qNGROToMnlo=; b=AyqaktHNxcnEdRiJt0yK2stiJ3y7E90Wrn/erNHSfnkXAI2poWBX1Awx2AX2ZkzHBG 8BoZ0e0F/WIY7xN5gMuBQr2z97fsJC8bG4WZi73mEaaC6wKGkRkAQeWqO/u6iw4hrNu7 p0o8sksVQedVNa9dNSu+paid+UqdmSOIlD9KfbKof8cv0pwU+ow0J5D4tOlHlY/AUfbC 0lUbpkLWHyRqm2IWTyTB9Jk/hTX0tojFLwTmBah1jDlB4xIhG6oyBE79QRzCWF7ALWXz 2NqdbPuNBb1rjV4Ui57v5s+4MfdqOufgOLvPXvXwDdlGt8GtcyzpzQo2VyrjfPCDrIzx iHew== X-Gm-Message-State: AOAM533+OeMWsEbuWQckf3LvJnLReCY2KMqVmz1p1Ct8yl6s9khAt8C2 ihgmX/R8+VPNIw2kodJZ31ETLLV7Z9J/g2lwWpcBWy/k10+kEg== X-Google-Smtp-Source: ABdhPJwg7sRbunyhlnmgnwZgRet/ARCWS+ytAhYveUshn9tYZKK3AX0NBLCZFYf9u8QYKFPzjF7a0eceoJgdBzQzVMQ= X-Received: by 2002:a67:7782:: with SMTP id s124mr12786933vsc.40.1622692578429; Wed, 02 Jun 2021 20:56:18 -0700 (PDT) MIME-Version: 1.0 References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> In-Reply-To: <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> From: "Murray S. Kucherawy" Date: Wed, 2 Jun 2021 20:56:07 -0700 Message-ID: To: Mark Nottingham Cc: Ned Freed , DISPATCH list Content-Type: multipart/alternative; boundary="000000000000b78ee005c3d48e94" Archived-At: Subject: Re: [dispatch] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 03:56:26 -0000 --000000000000b78ee005c3d48e94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Revised based on feedback. If we're good to go here, I can put it on the next review cycle. -MSK Media Type Maintenance (=E2=80=9CMEDIAMAN=E2=80=9D) Working Group Charter [= DRAFT v2] The IETF maintains a registry of media types and subtypes that are used to identify particular payloads and their semantics as they are transported via application level protocols such as messaging (=E2=80=9Cemail=E2=80=9D)= and the web (HTTP). The core structure and use of media types is the MIME framework, defined in RFCs 2045 through 2049, and amended by various later documents. Registration of new media types is defined by BCP 13, which was last updated in 2013. Several topics have appeared in the interim that are large enough in scope and importance to warrant the formation of a working group to develop and process them. This working group will therefore take up the following work, in this order (or as otherwise negotiated with the supervising Area Director): - Develop and process the pending =E2=80=98haptics=E2=80=99 top-level medi= a type request, based on draft-muthusamy-dispatch-haptics. - Consider any issues around media types for programming languages. - Develop a reviewer=E2=80=99s checklist regarding Security Considerations sections in media type applications. - Review the format of the media types registry itself. - Consider whether and how to permit multiple media type suffixes. - Investigate the possibility of using GitHub as both a registration interface and a queue for managing the processing of requests, based on = the model used for link relations and well-known URIs ( https://github.com/protocol-registries/link-relations and https://github.com/protocol-registries/well-known-uris respectively). Input Document(s): - draft-muthusamy-dispatch-haptics Proposed milestones (target dates TBD): - draft-muthusamy-dispatch-haptics (or equivalent) to the IESG for approval (Proposed Standard) - RFC6838bis to the IESG for approval (BCP) based on the last work item listed above, if needed. On Sat, May 15, 2021 at 9:41 PM Mark Nottingham wrote: > Agreeing with Ned's comments. > > One thing that I'd like to see discussed (not necessarily in this propose= d > WG, although that might be an appropriate venue for it) is whether the > interface for registration (from the perspective of a prospective > registrant) can be updated (or augmented). In particular, many in the W3C > still finds the registration process painful and bewildering, and I > strongly suspect that others do not undertake registrations for the same > reasons. > > We've now had a fair amount of experience using GitHub as both a > registration interface and for managing the processing of requests, both > for link relations and well-known URIs: > > https://github.com/protocol-registries/link-relations > https://github.com/protocol-registries/well-known-uris > > I think the media subtype registry is a good candidate for this approach > too; its audience is much larger than those who are familiar with the IET= F, > and so effectively what we're doing is adding a web-based registration > request flow to make it easier and more transparent for those people. > > Thoughts? > > > > On 13 May 2021, at 4:53 am, Ned Freed wrote: > > > >> Comments welcome, including my late-night choice of name. > > > > The name is fine. The rest... I'm afraid I have a lot of problems with > it. > > > >> -MSK > > > >> Media Type Maintenance (=E2=80=9CMEDIAMAN=E2=80=9D) Working Group Char= ter [DRAFT] > > > >> The IETF maintains a registry of media types and subtypes that are use= d > to > >> identify particular payloads and their semantics as they are transport= ed > >> via application level protocols such as messaging (=E2=80=9Cemail=E2= =80=9D) and the web > >> (HTTP). The core structure and use of media types is the MIME > framework, > >> defined in RFCs 2045 through 2049, and amended by various later > documents. > >> Registration of new media types is defined by BCP 13, which was last > >> updated in 2013. > > > >> Several topics have appeared in the interim that are large enough in > scope > >> and importance to warrant the formation of a working group to develop > and > >> process them. In particular, we have for the first time a request for= a > >> new top-level media type, and such requests are sufficiently rare that > our > >> current processes don=E2=80=99t make it clear how this request should = be > evaluated > >> and dispatched. > > > > It's not the first top-level type we've added: > > > > font - RFC 8081 - 2017 > > example - RFC 4735 - 2006 > > model - RFC 2077 - 1997 > > > > AFAICR the process for font went fairly smoothly - which is why I keep > pointing > > to RFC 8081 as a model for how to do it - so I'm not sure there's a cas= e > to be > > made that we don't know how to do this. > > > >> This working group will therefore, under this instance of the charter, > take > >> up the following work. The working group has discretion to order thes= e > as > >> appropriate. > > > > Strongly disagree. If the haptics work is time-sensitive - and I think > there's a > > consensus that it is - the charter needs to say it comes first and will > be > > completed before starting the other work. > > > >> Establish criteria and procedures for registering top-level media > >> types. In particular, specify whether these requests can be handled > by the > >> current IANA media type review team, require IETF Consensus, or shou= ld > >> follow some other process. > > > > RFC 6838 is pretty clear on the process: New top-level types require a > > standards-track RFC. AFAIK nobody has argued that we need to revisit th= is > > approach; especially if we're concerned about getting haptics done in a > timely > > way. > > > > As for criteria, I guess we could try and codify some, but again, > > timing. > > > >> Develop and process the pending =E2=80=98haptics=E2=80=99 top-level = media type > request, > >> based on draft-muthusamy-dispatch-haptics. > > > > +1 > > > >> Consider whether and how to permit multiple media type suffixes. > > > > I think this one is likely to be the most contentious by far, and shoul= d > come > > last. > > > >> Consider any issues around media types for programming languages. > > > > +1 > > > >> Determine revised criteria regarding Security Considerations section= s > in > >> media type applications. > > > > Not what I proposed. I've used a checklist to evaluate security > considerations > > for media types for years; in one of his registrations Eric > Prud'hommeaux noted > > this and essentially suggested that it would be good to expose a more > general > > version of it. (Actually, he suggested doing it in the form itself, but= a > > checklist needs to come first.) > > > > So the task is to develop such a checklist, not to revise the criteria > > themselves. > > > >> Review the format of the media types registry itself. > > > >> It is expected that the working group will produce a document updating > RFC > >> 6838 (BCP 13) as a result of the points above, and a =E2=80=9Chaptics= =E2=80=9D standards > >> track registration RFC. Any other work is out of scope. > > > > Strongly disagree. The only work I think this group should do that migh= t > > possibly necessitate a revision to BCP 13 is the multiple suffix work. > In the > > past we managed to add suffixes to media types without needing to revis= e > the > > core specification; I don't think we should assume a revision is needed > for > > this. > > > >> On completion of these goals, the working group will discuss whether i= t > >> would be appropriate for this to become a standing (perhaps usually > >> dormant) working group containing the expertise needed to repeat these > >> reviews periodically, and/or to handle those applications such as the > >> top-level request that are too large in scope for the IANA media type > >> review team. If so, the working group will negotiate a new charter > >> accordingly. > > > > OK... Maybe this is just me remembering things past that don't apply > > to the brave new IETF world, but I was under the impression that > > We Just Don't Do This. And if we're going to do this, we need > > to consider the alternatives (mailing list, directorate, ?) first. > > > >> Input Document(s): > > > >> - > > > >> draft-muthusamy-dispatch-haptics > > > > > >> Proposed milestones (target dates TBD): > > > >> - > > > >> draft-muthusamy-dispatch-haptics (or equivalent) to the IESG for > >> approval (Proposed Standard) > >> - > > > >> RFC6838bis to the IESG for approval (BCP) > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > -- > Mark Nottingham https://www.mnot.net/ > > --000000000000b78ee005c3d48e94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Revised based on feedback.=C2=A0 If we're good to= go here, I can put it on the next review cycle.

-= MSK

Media Type Maintenance (=E2=80=9CMEDIAMAN=E2=80=9D) Working Gr= oup Charter [DRAFT v2]


The IETF maintains a registry of media types and= subtypes that are used to identify particular payloads and their semantics= as they are transported via application level protocols such as messaging = (=E2=80=9Cemail=E2=80=9D) and the web (HTTP).=C2=A0 The core structure and = use of media types is the MIME framework, defined in RFCs 2045 through 2049= , and amended by various later documents.=C2=A0 Registration of new media t= ypes is defined by BCP 13, which was last updated in 2013.


Several topi= cs have appeared in the interim that are large enough in scope and importan= ce to warrant the formation of a working group to develop and process them.= =C2=A0 This working group will therefore take up the following work, in thi= s order (or as otherwise negotiated with the supervising Area Director):

  • Develop a= nd process the pending =E2=80=98haptics=E2=80=99 top-level media type reque= st, based on draft-muthusamy-dispatch-haptics.

  • Conside= r any issues around media types for programming languages.

    • <= li dir=3D"ltr" style=3D"list-style-type:disc;font-size:11pt;font-family:Ari= al;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style= :normal;font-variant:normal;text-decoration:none;vertical-align:baseline;wh= ite-space:pre">

    Develop a reviewer=E2=80=99s checklist regarding Security Consideratio= ns sections in media type applications.

  • Review the for= mat of the media types registry itself.

  • Consider wheth= er and how to permit multiple media type suffixes.

  • I= nvestigate the possibility of using GitHub as both a registration interface= and a queue for managing the processing of requests, based on the model us= ed for link relations and well-known URIs (http= s://github.com/protocol-registries/link-relations and https://github.com/protocol-registries/well-known-uris<= span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;font-weight:400;font-style:normal;font-variant:normal;tex= t-decoration:none;vertical-align:baseline;white-space:pre-wrap"> respective= ly).


Input Document(s):

  • draft-muthusamy-dispatch-haptics

    • <= /ul>

    Pr= oposed milestones (target dates TBD):

    • draft-muthusamy-dispatch-haptics (or equivalent) = to the IESG for approval (Proposed Standard)

    • RFC6838bi= s to the IESG for approval (BCP) based on the last work item listed above, = if needed.


<= div dir=3D"ltr" class=3D"gmail_attr">On Sat, May 15, 2021 at 9:41 PM Mark N= ottingham <mnot@mnot.net> wrote:=
Agreeing with N= ed's comments.

One thing that I'd like to see discussed (not necessarily in this propo= sed WG, although that might be an appropriate venue for it) is whether the = interface for registration (from the perspective of a prospective registran= t) can be updated (or augmented). In particular, many in the W3C still find= s the registration process painful and bewildering, and I strongly suspect = that others do not undertake registrations for the same reasons.

We've now had a fair amount of experience using GitHub as both a regist= ration interface and for managing the processing of requests, both for link= relations and well-known URIs:

https://github.com/protocol-registries/link-rel= ations
https://github.com/protocol-registries/well-kn= own-uris

I think the media subtype registry is a good candidate for this approach to= o; its audience is much larger than those who are familiar with the IETF, a= nd so effectively what we're doing is adding a web-based registration r= equest flow to make it easier and more transparent for those people.

Thoughts?


> On 13 May 2021, at 4:53 am, Ned Freed <ned.freed@mrochek.com> wrote:
>
>> Comments welcome, including my late-night choice of name.
>
> The name is fine. The rest... I'm afraid I have a lot of problems = with it.
>
>> -MSK
>
>> Media Type Maintenance (=E2=80=9CMEDIAMAN=E2=80=9D) Working Group = Charter [DRAFT]
>
>> The IETF maintains a registry of media types and subtypes that are= used to
>> identify particular payloads and their semantics as they are trans= ported
>> via application level protocols such as messaging (=E2=80=9Cemail= =E2=80=9D) and the web
>> (HTTP).=C2=A0 The core structure and use of media types is the MIM= E framework,
>> defined in RFCs 2045 through 2049, and amended by various later do= cuments.
>> Registration of new media types is defined by BCP 13, which was la= st
>> updated in 2013.
>
>> Several topics have appeared in the interim that are large enough = in scope
>> and importance to warrant the formation of a working group to deve= lop and
>> process them.=C2=A0 In particular, we have for the first time a re= quest for a
>> new top-level media type, and such requests are sufficiently rare = that our
>> current processes don=E2=80=99t make it clear how this request sho= uld be evaluated
>> and dispatched.
>
> It's not the first top-level type we've added:
>
>=C2=A0 =C2=A0font - RFC 8081 - 2017
>=C2=A0 =C2=A0example - RFC 4735 - 2006
>=C2=A0 =C2=A0model - RFC 2077 - 1997
>
> AFAICR the process for font went fairly smoothly - which is why I keep= pointing
> to RFC 8081 as a model for how to do it - so I'm not sure there= 9;s a case to be
> made that we don't know how to do this.
>
>> This working group will therefore, under this instance of the char= ter, take
>> up the following work.=C2=A0 The working group has discretion to o= rder these as
>> appropriate.
>
> Strongly disagree. If the haptics work is time-sensitive - and I think= there's a
> consensus that it is - the charter needs to say it comes first and wil= l be
> completed before starting the other work.
>
>>=C2=A0 =C2=A0Establish criteria and procedures for registering top-= level media
>>=C2=A0 =C2=A0types.=C2=A0 In particular, specify whether these requ= ests can be handled by the
>>=C2=A0 =C2=A0current IANA media type review team, require IETF Cons= ensus, or should
>>=C2=A0 =C2=A0follow some other process.
>
> RFC 6838 is pretty clear on the process: New top-level types require a=
> standards-track RFC. AFAIK nobody has argued that we need to revisit t= his
> approach; especially if we're concerned about getting haptics done= in a timely
> way.
>
> As for criteria, I guess we could try and codify some, but again,
> timing.
>
>>=C2=A0 =C2=A0Develop and process the pending =E2=80=98haptics=E2=80= =99 top-level media type request,
>>=C2=A0 =C2=A0based on draft-muthusamy-dispatch-haptics.
>
> +1
>
>>=C2=A0 =C2=A0Consider whether and how to permit multiple media type= suffixes.
>
> I think this one is likely to be the most contentious by far, and shou= ld come
> last.
>
>>=C2=A0 =C2=A0Consider any issues around media types for programming= languages.
>
> +1
>
>>=C2=A0 =C2=A0Determine revised criteria regarding Security Consider= ations sections in
>>=C2=A0 =C2=A0media type applications.
>
> Not what I proposed. I've used a checklist to evaluate security co= nsiderations
> for media types for years; in one of his registrations Eric Prud'h= ommeaux noted
> this and essentially suggested that it would be good to expose a more = general
> version of it. (Actually, he suggested doing it in the form itself, bu= t a
> checklist needs to come first.)
>
> So the task is to develop such a checklist, not to revise the criteria=
> themselves.
>
>>=C2=A0 =C2=A0Review the format of the media types registry itself.<= br> >
>> It is expected that the working group will produce a document upda= ting RFC
>> 6838 (BCP 13) as a result of the points above, and a =E2=80=9Chapt= ics=E2=80=9D standards
>> track registration RFC.=C2=A0 Any other work is out of scope.
>
> Strongly disagree. The only work I think this group should do that mig= ht
> possibly necessitate a revision to BCP 13 is the multiple suffix work.= In the
> past we managed to add suffixes to media types without needing to revi= se the
> core specification; I don't think we should assume a revision is n= eeded for
> this.
>
>> On completion of these goals, the working group will discuss wheth= er it
>> would be appropriate for this to become a standing (perhaps usuall= y
>> dormant) working group containing the expertise needed to repeat t= hese
>> reviews periodically, and/or to handle those applications such as = the
>> top-level request that are too large in scope for the IANA media t= ype
>> review team.=C2=A0 If so, the working group will negotiate a new c= harter
>> accordingly.
>
> OK... Maybe this is just me remembering things past that don't app= ly
> to the brave new IETF world, but I was under the impression that
> We Just Don't Do This. And if we're going to do this, we need<= br> > to consider the alternatives (mailing list, directorate, ?) first.
>
>> Input Document(s):
>
>>=C2=A0 =C2=A0-
>
>>=C2=A0 =C2=A0draft-muthusamy-dispatch-haptics
>
>
>> Proposed milestones (target dates TBD):
>
>>=C2=A0 =C2=A0-
>
>>=C2=A0 =C2=A0draft-muthusamy-dispatch-haptics (or equivalent) to th= e IESG for
>>=C2=A0 =C2=A0approval (Proposed Standard)
>>=C2=A0 =C2=A0-
>
>>=C2=A0 =C2=A0RFC6838bis to the IESG for approval (BCP)
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

--000000000000b78ee005c3d48e94-- From nobody Thu Jun 3 07:05:52 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8053A12EF for ; Thu, 3 Jun 2021 07:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psZXKK2xYqFS for ; Thu, 3 Jun 2021 07:05:46 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 C0D673A12EC for ; Thu, 3 Jun 2021 07:05:46 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RZPZV6XN5C00IHB9@mauve.mrochek.com> for dispatch@ietf.org; Tue, 1 Jun 2021 11:13:10 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RZMX49RI1S0085YQ@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dispatch@ietf.org; Tue, 1 Jun 2021 11:13:07 -0700 (PDT) From: ned+dispatch@mrochek.com Cc: "sedate@ietf.org" , "dispatch@ietf.org" Message-id: <01RZPZV5ELIY0085YQ@mauve.mrochek.com> Date: Tue, 01 Jun 2021 09:43:53 -0700 (PDT) In-reply-to: "Your message dated Tue, 01 Jun 2021 14:45:54 +0000" References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> To: Francesca Palombini Archived-At: Subject: Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 14:05:52 -0000 I have to object to a working being chartered with this remit. The main problem is that the charter specifies that a variant of RFC 3339 is to be embedded in this new specification, with no consideration given to the alternate approach of incorporating either RFC 3339 or an RFC 3339bis by reference. This really isn't the time or place to get into all of the reasons why incorporation by reference is a much better way to do this, so I'll simply note that even if you ignore the confusion this can cause, having text in two places that describes the same thing has proved to be a maintenance nightmare on many previous occasions. At an absolute minimum the choice of reference versus embedding should be left to the working group, rather than being effectively chosen by the charter, and this needs to be made very clear from the outset. The charter also says that: > It is anticipated that this document would be a companion to RFC3339 rather > than a replacement, embedding an unaltered RFC3339 instant along with the > contextual data. Except the current draft cited as a "good basis" for this work doesn't actually do this. Rather, it preemptively extends RFC 3339 in not one but two ways: (1) Years are extended to six digits (2) Local offsets are extended to allow seconds and fractions of seconds. Given the ability of the metadata (what the draft calls the "informative suffix") to specify complex time zone rules, I question the need for (2), but again, this is neither the time nor the place to get into these sorts of details. The point is that this isn't "an unaltered RFC3339", and if this work were to end up specifying this new format but not updating RFC 3339, we will then have have two incompatible formats for basic timestamps. Another problem is that the current draft makes a number of unnecessary changes to the RFC 3339 ABNF, e.g., full-time becomes time-full, full-date becomes date-full, date-fullyear becomes date-year, etc. Even granting that the new names are in some sense "better", the problem is that other specifications can and do reference specific rules in specifications like RFC 3339, and when you change the the rule names, you complicate the update process for all of these RFCs. Finally, I concur with Carsten Bormann's point about noting that this is exclusively a *text* format for date time values. Simply inserting the word "text" in a couple of places would sufficient. And FWIW, I don't think extending the current charter to cover binary formats is a good idea. If such a thing is to be done, it should be accomplished via a recharter. Ned > Hi all, > (CC dispatch for information) > The charter for the Sedate working group has passed the first phase and is now > in external review. Additionally, the sedate mailing list has been created. Do > go over there and subscribe if you are interested. > Now is the time to let the IESG know of any comment you might have on the > charter text. > I am also looking for volunteers to chair the wg. It is ok to volunteer > someone you think would be a good fit. I hope that, given the interest in this > work, we will not have problems finding chairs, but as a reminder: please do > consider volunteering if you support this work, as with no chairs there will be > no working group. > Please reply to this thread (dropping the dispatch mailing list), or send an > email to the IESG (iesg@ietf.org), or directly to me with any comments on the > charter, or volunteering as chair. > Thanks, > Francesca > On 01/06/2021, 16:02, "Sedate on behalf of The IESG" wrote: > A new IETF WG has been proposed in the Applications and Real-Time Area. The > IESG has not made any determination yet. The following draft charter was > submitted, and is provided for informational purposes only. Please send your > comments to the IESG mailing list (iesg@ietf.org) by 2021-06-11. > Serialising Extended Data About Times and Events (sedate) > ----------------------------------------------------------------------- > Current status: Proposed WG > Chairs: > TBD > Assigned Area Director: > Francesca Palombini > Applications and Real-Time Area Directors: > Murray Kucherawy > Francesca Palombini > Mailing list: > Address: sedate@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/sedate > Archive: https://mailarchive.ietf.org/arch/browse/sedate/ > Group page: https://datatracker.ietf.org/group/sedate/ > Charter: https://datatracker.ietf.org/doc/charter-ietf-sedate/ > RFC3339 defines a format that can reliably express an instant in time, either > in UTC or in a local time along with the offset against UTC. However, > datetime data often has additional context, such as the timezone or calendar > system that was in use when that instant was recorded. Particularly when > using times for interval, recurrence, or offset calculations, it is necessary > to know the context in which the timepoint exists. > It is valuable to have a serialisation format that retains this context and > can reliably round-trip the additional context to systems that understand it, > via intermediate systems that only need to know about the instant in time. > The TC39 working group at ECMA have developed a format that is a good basis > for this work: draft-ryzokuken-datetime-extended. > It is anticipated that this document would be a companion to RFC3339 rather > than a replacement, embedding an unaltered RFC3339 instant along with the > contextual data. > It is also within scope for this working group to consider a minor update to > RFC3339 to allow larger than four-digit signed years, to enable representing > times further into the past and future. > It is anticipated that this working group will publish one or two documents > on the work mentioned above. After that, the working group will close down or > recharter. > The working group will coordinate with ECMA International TC39 and ISO TC154. > Milestones: > Dec 2021 - Submit extended date and time draft to the IESG for publication > -- > Sedate mailing list > Sedate@ietf.org > https://www.ietf.org/mailman/listinfo/sedate > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Jun 3 07:57:21 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19953A150A for ; Thu, 3 Jun 2021 07:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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_BLOCKED=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=mrochek.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 1kPLLE7vVcP1 for ; Thu, 3 Jun 2021 07:57:13 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 9EE343A1500 for ; Thu, 3 Jun 2021 07:57:13 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RZSLCU4W4W00FP66@mauve.mrochek.com> for dispatch@ietf.org; Thu, 3 Jun 2021 07:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1622731794; bh=+Mryj7GaEL38wbKRRiODZAmCxdY7PIVeGc8jP/iaiKI=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=S5VU1Af+R6Y0aSVsWCL8o5Qci6kKnpxa+uw9WLqomERbvvDJhW22yjNo6rhZ+a5u8 i6c+xuKEf50ewgeViVlpmPiUolYfSKSkTOjR87UvFKBB1R2KQYpShWfLuzltS0zZB1 WNSosBdoZIXD5RGUFEG8NQ2k9Ba9azJDlyvE2q9U= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=UTF-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RZPZYN3BE800IM2V@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dispatch@ietf.org; Thu, 3 Jun 2021 07:49:49 -0700 (PDT) From: ned+dispatch@mrochek.com Cc: Mark Nottingham , DISPATCH list , Ned Freed Message-id: <01RZSLCQGG9Y00IM2V@mauve.mrochek.com> Date: Thu, 03 Jun 2021 07:25:41 -0700 (PDT) In-reply-to: "Your message dated Wed, 02 Jun 2021 20:56:07 -0700" References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> To: "Murray S. Kucherawy" Archived-At: Subject: Re: [dispatch] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 14:57:20 -0000 > Revised based on feedback. If we're good to go here, I can put it on the > next review cycle. Better, but still some issues. My significant concerns are: (1) This doesn't prioritize the haptics work. (But if it's the consensus is not to do that so be it.) (2) Unnecessarily reopening RFC 6838. Details comments below. > -MSK > Media Type Maintenance (“MEDIAMAN”) Working Group Charter [DRAFT v2] > The IETF maintains a registry of media types and subtypes that are used to > identify particular payloads and their semantics as they are transported > via application level protocols such as messaging (“email”) and the web > (HTTP). The core structure and use of media types is the MIME framework, > defined in RFCs 2045 through 2049, and amended by various later documents. > Registration of new media types is defined by BCP 13, which was last > updated in 2013. "The IETF" -> "The IANA"? > Several topics have appeared in the interim that are large enough in scope > and importance to warrant the formation of a working group to develop and > process them. This working group will therefore take up the following > work, in this order (or as otherwise negotiated with the supervising Area > Director): > - Based on the degree of urgency I've seen expressed in various comments, I'd recommend reordering this to haptics, then suffixes, then sec-cons checklist, then programming languages, then registry format, and finally github. List order is important even when the text doesn't require item ordering by the WG. > Develop and process the pending ‘haptics’ top-level media type request, > based on draft-muthusamy-dispatch-haptics. > - > Consider any issues around media types for programming languages. > - > Develop a reviewer’s checklist regarding Security Considerations > sections in media type applications. > - > Review the format of the media types registry itself. > - > Consider whether and how to permit multiple media type suffixes. > - > Investigate the possibility of using GitHub as both a registration > interface and a queue for managing the processing of requests, based on the > model used for link relations and well-known URIs ( > https://github.com/protocol-registries/link-relations and > https://github.com/protocol-registries/well-known-uris respectively). While I don't have a problem with doing this if IANA doesn't, and if it makes things easier for IANA so much the better, I am dubious that this actually solves the problems people have with registering media types. The complaints I've heard about the media type registration process concern the lack of guidance as to how to fill in the various fields. I took a look at the two examples, and I don't see how using what appears to be a completely free form interface will address that. At a minimum some justification needs to be given as to why this approach will be an improvement. > Input Document(s): > - > draft-muthusamy-dispatch-haptics Shouldn't draft-w3cdidwg-media-types-with-multiple-suffixes also be listed here? > Proposed milestones (target dates TBD): > - > draft-muthusamy-dispatch-haptics (or equivalent) to the IESG for > approval (Proposed Standard) > - > RFC6838bis to the IESG for approval (BCP) based on the last work item > listed above, if needed. Nothing in RFC 6838 assumes a particular approach to providing the necessary information to specify a new media type. If github replaces the existing form I would hope that the existing form address could be changed to redirect to Github, but having it display a note with the new URL is always a possibility. Bottom line: I see no reason why a RFC 6838 bis should be needed here, and if it is, I think that indicates a change in scope that will need to be evaluated in its own right. Ned From nobody Thu Jun 3 08:20:16 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB43B3A15F6; Thu, 3 Jun 2021 08:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 Cuwo4hsweIL1; Thu, 3 Jun 2021 08:20:02 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB983A15FC; Thu, 3 Jun 2021 08:20:02 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lop8b-000Mf4-3s; Thu, 03 Jun 2021 11:20:01 -0400 Date: Thu, 03 Jun 2021 11:19:55 -0400 From: John C Klensin To: ned+dispatch@mrochek.com, Francesca Palombini cc: dispatch@ietf.org, sedate@ietf.org Message-ID: <48D3CA53295C2C8C1045A23D@PSB> In-Reply-To: <01RZPZV5ELIY0085YQ@mauve.mrochek.com> References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <01RZPZV5ELIY0085YQ@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 15:20:08 -0000 FWIW, I completely agree with Ned, especially wrt the issues of the confusion and potential interoperability issues associated with creating inconsistent standards and terminology. To further complicate things, RFC 3339 is based on on the 1988 version (or perhaps, given an additional reference that is not cited, the 2000 one) of ISO 9601. There is now a 2019 version of ISO 8601, with the scope of the 1988 version extended and split into two parts, the second specifically concerned with extensions. Any charter that proposes to tinker with RFC 3339, potentially even including incorporating it by reference as Ned suggests should have, as its first charter item, a careful review of the current version of ISO 8601-1 and 8601-2 to understand if, or how, they might affect the rest of the effort. Failure to do so could lead us to three inconsistent ways of doing things, not just two (which is one too many). john --On Tuesday, June 1, 2021 09:43 -0700 ned+dispatch@mrochek.com wrote: > I have to object to a working being chartered with this remit. >=20 > The main problem is that the charter specifies that a variant > of RFC 3339 is to be embedded in this new specification, with > no consideration given to the alternate approach of > incorporating either RFC 3339 or an RFC 3339bis by reference. >=20 > This really isn't the time or place to get into all of the > reasons why incorporation by reference is a much better way to > do this, so I'll simply note that even if you ignore the > confusion this can cause, having text in two places that > describes the same thing has proved to be a maintenance > nightmare on many previous occasions. >=20 > At an absolute minimum the choice of reference versus > embedding should be left to the working group, rather than > being effectively chosen by the charter, and this needs to be > made very clear from the outset. >=20 > The charter also says that: >=20 >> It is anticipated that this document would be a companion >> to RFC3339 rather than a replacement, embedding an >> unaltered RFC3339 instant along with the contextual data. >=20 > Except the current draft cited as a "good basis" for this work > doesn't actually do this. Rather, it preemptively extends RFC > 3339 in not one but two ways: >=20 > (1) Years are extended to six digits > (2) Local offsets are extended to allow seconds and fractions > of seconds. >=20 > Given the ability of the metadata (what the draft calls the > "informative suffix") to specify complex time zone rules, I > question the need for (2), but again, this is neither the time > nor the place to get into these sorts of details. The point is > that this isn't "an unaltered RFC3339", and if this work were > to end up specifying this new format but not updating RFC > 3339, we will then have have two incompatible formats for > basic timestamps. >=20 > Another problem is that the current draft makes a number of > unnecessary changes to the RFC 3339 ABNF, e.g., full-time > becomes time-full, full-date becomes date-full, date-fullyear > becomes date-year, etc. Even granting that the new names are > in some sense "better", the problem is that other > specifications can and do reference specific rules in > specifications like RFC 3339, and when you change the the rule > names, you complicate the update process for all of these = RFCs. >=20 > Finally, I concur with Carsten Bormann's point about noting > that this is exclusively a *text* format for date time values. > Simply inserting the word "text" in a couple of places would > sufficient. And FWIW, I don't think extending the current > charter to cover binary formats is a good idea. If such a > thing is to be done, it should be accomplished via a = recharter. >=20 > Ned >=20 >=20 >> Hi all, >=20 >> (CC dispatch for information) >=20 >> The charter for the Sedate working group has passed the first >> phase and is now in external review. Additionally, the sedate >> mailing list has been created. Do go over there and subscribe >> if you are interested. >=20 >> Now is the time to let the IESG know of any comment you might >> have on the charter text. >=20 >> I am also looking for volunteers to chair the wg. It is ok to >> volunteer someone you think would be a good fit. I hope that, >> given the interest in this work, we will not have problems >> finding chairs, but as a reminder: please do consider >> volunteering if you support this work, as with no chairs >> there will be no working group. >=20 >> Please reply to this thread (dropping the dispatch mailing >> list), or send an email to the IESG (iesg@ietf.org), or >> directly to me with any comments on the charter, or >> volunteering as chair. >=20 >> Thanks, >> Francesca >=20 >> =EF=BB=BFOn 01/06/2021, = 16:0=E4=A8=B3=E3=B8=80=E3=B8=80=E2=80=80=E0=A0=80 From nobody Thu Jun 3 08:22:18 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F053A160C for ; Thu, 3 Jun 2021 08:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_BLOCKED=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 (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 2ryl1LxOcR1V for ; Thu, 3 Jun 2021 08:22:09 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 167723A1304 for ; Thu, 3 Jun 2021 08:22:08 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id s22so3170228vsl.10 for ; Thu, 03 Jun 2021 08:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SaLEZTHlFREjx5B7tZa8Wjjk7f9oH01L94gMJWhFACk=; b=eE4AjjoT9nglmtNrdZIoQROU+qnHZzZzY0adwxTNyLsOXckQbh4J33ZPtx22G2UyxM Rs2MpzT33lfeWPEAAlHlT7ZEtWIHp60kwES3uFhxjNhwMxl87L1iOt0bIoOYk9PlTwyR IZ5X9AO2w3yzEQMHVLOIQKoaDnvY5bS2F2qLGhBawODIHUsTBfx4KqhEH5W8YHfAmlVM aC4JOaPLNEcXWP3nhg/JSekpQaW3FKg6xg2i86F7tc2SfGiLpk+DNCsyBHHIyMaGfrkp naVDqXdMddFnlDwkh+jbgeeg1JiZ/JdP3R2VTxpUDuNen9V90otwEv1KNfztbaYzgyEG MZXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SaLEZTHlFREjx5B7tZa8Wjjk7f9oH01L94gMJWhFACk=; b=rWxTG7uOn+gH3MBWG9A1AuAHaBJPeHWuCXT+lIg61dWX8Icy5VV2Brm5fWl5Ib0u0Z R52+E4ga2UYCTIodJ9Te67ml88GgQHRT7UDmhzal1OOqTnNNuZc8k7r3F9A28Eu5vgUZ 8SnjZVS6LiWqCyuiMLBSAqK2heoWB3hV8nfzyNbIv6JyxvEKRRTttN2ePO6FvWaTAfA1 qZbn5SYSWNRkGYyAmb3tdBnGGTgATn6QUmT/wub84NzOW9zq8XzKf/SHMHqVH0RJCAVW PKQZa1YGOWuy6ZB2OuMxntt2yof1PywF8kNflyyh3KMa++qt4T3yT1joR6mzBg1f+fuX 2KsA== X-Gm-Message-State: AOAM531SJFsb5LIfsa1aCMM1JlFP9PYDRU0SdqYeuTO8027hKZIcjlTk sFzYPcctHlNfpH/7+8xBXLCysA6iY7GW8Ee+JhMDDcV10OITSg== X-Google-Smtp-Source: ABdhPJzi55Tr2ghj0v7q0zYwUFxUKIWTuQHpdNOJGDn9tAf+Mq/+UVyAXBIZUymxWZtE54fe/7Zinx5zaVJxy1rppEE= X-Received: by 2002:a67:1a45:: with SMTP id a66mr164041vsa.15.1622733727384; Thu, 03 Jun 2021 08:22:07 -0700 (PDT) MIME-Version: 1.0 References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> <01RZSLCQGG9Y00IM2V@mauve.mrochek.com> In-Reply-To: <01RZSLCQGG9Y00IM2V@mauve.mrochek.com> From: "Murray S. Kucherawy" Date: Thu, 3 Jun 2021 08:21:55 -0700 Message-ID: To: Ned Freed Cc: Mark Nottingham , DISPATCH list Content-Type: multipart/alternative; boundary="00000000000062c7f305c3de236d" Archived-At: Subject: Re: [dispatch] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 15:22:15 -0000 --00000000000062c7f305c3de236d Content-Type: text/plain; charset="UTF-8" On Thu, Jun 3, 2021 at 7:57 AM Ned Freed wrote: > > Revised based on feedback. If we're good to go here, I can put it on the > > next review cycle. > > Better, but still some issues. My significant concerns are: > > (1) This doesn't prioritize the haptics work. (But if it's the consensus > is not > to do that so be it.) > It's the first thing on the list. I can't move it up any higher. Would you suggest doing not only that, but explicitly saying nothing else can be done until this ships? [...] > "The IETF" -> "The IANA"? > OK. Based on the degree of urgency I've seen expressed in various comments, I'd > recommend reordering this to haptics, then suffixes, then sec-cons > checklist, > then programming languages, then registry format, and finally github. > Upthread you said: "I think this one is likely to be the most contentious by far, and should come last." ...hence the current ordering. I'll change it to this new ordering and see how we all like it. While I don't have a problem with doing this if IANA doesn't, and if it > makes > things easier for IANA so much the better, I am dubious that this actually > solves the problems people have with registering media types. > > The complaints I've heard about the media type registration process > concern the > lack of guidance as to how to fill in the various fields. I took a look at > the > two examples, and I don't see how using what appears to be a completely > free > form interface will address that. > > At a minimum some justification needs to be given as to why this approach > will be an improvement. > There were two proponents for adding this to the charter, so I'll let them pipe up here. Shouldn't draft-w3cdidwg-media-types-with-multiple-suffixes also > be listed here? > Sure, I just wasn't aware of its existence. I'll add it. > RFC6838bis to the IESG for approval (BCP) based on the last work item > > listed above, if needed. > > Nothing in RFC 6838 assumes a particular approach to providing the > necessary > information to specify a new media type. If github replaces the existing > form I > would hope that the existing form address could be changed to redirect to > Github, but having it display a note with the new URL is always a > possibility. > > Bottom line: I see no reason why a RFC 6838 bis should be needed here, and > if it is, I think that indicates a change in scope that will need to be > evaluated in its own right. > I'll remove it as a milestone in the charter. If it ends up being appropriate, we can always recharter or at least re-add the milestone. I've now added this to the datatracker: https://datatracker.ietf.org/doc/charter-ietf-mediaman/ -MSK --00000000000062c7f305c3de236d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 3, 2021 at 7:57 AM Ned Freed = <ned.freed@mrochek.com> = wrote:
> Revised based on feedback.=C2=A0 If we're good t= o go here, I can put it on the
> next review cycle.

Better, but still some issues. My significant concerns are:

(1) This doesn't prioritize the haptics work. (But if it's the cons= ensus is not
=C2=A0 =C2=A0 to do that so be it.)

It&= #39;s the first thing on the list.=C2=A0 I can't move it up any higher.=

Would you suggest doing not only that, but explic= itly saying nothing else can be done until this ships?

[...]
"The IETF" -> "The IANA"?

<= /div>
OK.

Based on the degree of urgency I've seen expressed in variou= s comments, I'd
recommend reordering this to haptics, then suffixes, then sec-cons checklis= t,
then programming languages, then registry format, and finally github.

Upthread you said:

"I think this= one is likely to be the most contentious by far, and should come last.&quo= t;

...hence t= he current ordering.=C2=A0 I'll change it to this new ordering and see = how we all like it.

While I don't have a problem with doing this if IANA doe= sn't, and if it makes
things easier for IANA so much the better, I am dubious that this actually<= br> solves the problems people have with registering media types.

The complaints I've heard about the media type registration process con= cern the
lack of guidance as to how to fill in the various fields. I took a look at = the
two examples, and I don't see how using what appears to be a completely= free
form interface will address that.

At a minimum some justification needs to be given as to why this approach will be an improvement.

There were two = proponents for adding this to the charter, so I'll let them pipe up her= e.

Shouldn't draft-w3cdidwg-media-types-with-multiple-suffixes also
be listed here?

Sure, I just wasn't= aware of its existence.=C2=A0 I'll add it.

>=C2=A0 =C2=A0 RFC6838bis to the IESG for approval (BCP) based on the la= st work item
>=C2=A0 =C2=A0 listed above, if needed.

Nothing in RFC 6838 assumes a particular approach to providing the necessar= y
information to specify a new media type. If github replaces the existing fo= rm I
would hope that the existing form address could be changed to redirect to <= br> Github, but having it display a note with the new URL is always a possibili= ty.

Bottom line: I see no reason why a RFC 6838 bis should be needed here, and<= br> if it is, I think that indicates a change in scope that will need to be
evaluated in its own right.

I'll re= move it as a milestone in the charter.=C2=A0 If it ends up being appropriat= e, we can always recharter or at least re-add the milestone.

=
I've now added this to the datatracker:
https://datatracker.ietf= .org/doc/charter-ietf-mediaman/

-MSK
=
--00000000000062c7f305c3de236d-- From nobody Thu Jun 3 10:46:17 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EFB3A113B for ; Thu, 3 Jun 2021 10:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 kzFXe-W00Yal for ; Thu, 3 Jun 2021 10:46:10 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CCFE3A1137 for ; Thu, 3 Jun 2021 10:46:10 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lorPx-000MxY-7P; Thu, 03 Jun 2021 13:46:05 -0400 Date: Thu, 03 Jun 2021 13:45:59 -0400 From: John C Klensin To: "Murray S. Kucherawy" , Ned Freed cc: DISPATCH list Message-ID: <186D8E4B026BA2F7C3D54B2F@PSB> In-Reply-To: References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> <01RZSLCQGG9Y00IM2V@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 17:46:16 -0000 --On Thursday, June 3, 2021 08:21 -0700 "Murray S. Kucherawy" wrote: > On Thu, Jun 3, 2021 at 7:57 AM Ned Freed > wrote: > >> > Revised based on feedback. If we're good to go here, I can >> > put it on the next review cycle. >> >> Better, but still some issues. My significant concerns are: >> >> (1) This doesn't prioritize the haptics work. (But if it's >> the consensus is not >> to do that so be it.) > It's the first thing on the list. I can't move it up any > higher. > > Would you suggest doing not only that, but explicitly saying > nothing else can be done until this ships? >... I was about to make exactly the opposite argument. Stepping back a few paces... (1) I believe that, at the time 6838 and it predecessors were written, there was a shared assumption that proliferation of top-level media types was not a good idea. The several rounds of discussion around haptics lead me to believe that assumption is now less generally shared and * that people who want top-level types, even if only because it makes them feel their work is important, should be able to have them and/or * that the argument that, if we don't allow people to register whatever they want, they will just squat on the names, causing potential uniqueness problems should prevail over more subtle considerations and tradeoffs. While haptics might well be appropriate as a top-level type under any criteria we might come up with, it seems that a key part of the work of the proposed WG is necessarily a review of those criteria (both explicit and oral tradition) and determining whether revisions or more explicit specifications are needed. Approving haptics as a top-level type and only then doing that review seems wholly inappropriate if only because haptics would presumably then be a precedent to be considered. (2) The main argument for putting haptics first in spite of the above is that doing so is a matter of urgency because of the interactions with pending ISO action. That argument might have been reasonable a couple of years ago, but is now OBE: the ISO actions and decisions are essentially set in stone and the window for IETF action having any effect on them has closed. If there are any substantive interactions left, we are playing catch-up. The squatting we would normally like to avoid has already occurred. While it would be better to catch up sooner rather than later, it is hard to believe that several months one way or the other will make any difference. Because a media type name structure has apparently already appeared in the ISO documents, we may have no choice other than to approve the registration. However, it still makes a difference whether we approve it as consistent with the policies we are developing or as an exception based on use and standardization elsewhere. So, to me. it needs to be "criteria review first, then specific cases, haptics included" not "haptics first and above all". Additional observation, which I have said before: if getting haptics registered is really of very high priority and the ISO work that would, in a better world, reference it, is, as we have been told, past the point where it can be changed, then my understanding of Section 3.1, option 2 of RFC 6838 allows a procedure that could be _very_ fast: (Step 1): If it has not already done so, IESG identifies the relevant ISO TC as a "recognized standards body". It is has already so identified all of ISO that way, this step is a no-op. (Step 2): The ISO TC or ISO/CS point to a specification (which need not be an RFC or I-D leading to on) and asks up to register the thing. (Step 3): The expert review process and/or IANA get to dicker with the ISO body about the adequacy of the specification if they conclude that is necessary. No WG required to address that particular registration (nor the time needed to set one up and have it reach decisions). So, to me, there are only two cases. Either this is urgent and ISO wants it or it doesn't. In the latter case, I don't see the case for urgency rather than due process and consideration by a WG. best, john john From nobody Thu Jun 3 14:10:27 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBE53A1A70 for ; Thu, 3 Jun 2021 14:10:24 -0700 (PDT) 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_DNSWL_BLOCKED=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=mrochek.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 vsrTNZXQTIha for ; Thu, 3 Jun 2021 14:10:20 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 EA8753A1A6C for ; Thu, 3 Jun 2021 14:10:19 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RZSYH80Q1C00DC8W@mauve.mrochek.com> for dispatch@ietf.org; Thu, 3 Jun 2021 14:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1622754316; bh=edy79YF75L0saUWdYocJ+41x95KxJX29aSvHvMfdJO8=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=WCi1A9k3qNfFw8Sr2L6He+jmEGxlXuJWzf/Qn7+WqWS6p8a41MCs+jdAfOY41hA/2 8m9SeoAj2/OcXyfW15sJLZi3iE/Z1w6n1/Vo/4q+yVPQ7IW2AEi8KniekM1avhIRig itoKu48O9lYgScePat0wy3XrE5fq6peefFjq9UuA= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RZPZYN3BE800IM2V@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dispatch@ietf.org; Thu, 3 Jun 2021 14:05:10 -0700 (PDT) From: ned+dispatch@mrochek.com Cc: ned+dispatch@mrochek.com, Francesca Palombini , dispatch@ietf.org, sedate@ietf.org Message-id: <01RZSYH3BXYS00IM2V@mauve.mrochek.com> Date: Thu, 03 Jun 2021 12:35:38 -0700 (PDT) In-reply-to: "Your message dated Thu, 03 Jun 2021 11:19:55 -0400" <48D3CA53295C2C8C1045A23D@PSB> References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <01RZPZV5ELIY0085YQ@mauve.mrochek.com> <48D3CA53295C2C8C1045A23D@PSB> To: John C Klensin Archived-At: Subject: Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 21:10:25 -0000 I should have discussed ISO 8601 in my original response - my apologies for not having done so. My (lame) excuse is that I have no good suggestions as to how to handle it. First, I take John's point that less is better, and having three specifications with overlapping goals that are syntactically and semantically inconsistent would be a really bad outcome. That said, I'm very concerned by the fact that the revised ISO 8601 specifications are not freely available, and the cost to obtain them is nothing short of outrageous: 336 CHF ($371 at today's exchange rate). These are also hugely complex highly technical specifications, IMO incapable of being summarized in any useful way. This means that anyone wishing to participate in significant technical discussion involving them is going to need to purchase copies. This represents a very significant burden to anyone wishing to participate in the discussion without a corporate sponser willing to bear the cost. To be blunt, if the IETF decides that a review of ISO 8601 is required, either as part of revising RFC 3339 or as part of developing the details of the informative suffix, and is truly sincere about trying to lower the barriers to participation in its technical discussions, some sort of arrangement needs to be made with the ISO to make these documents available to WG participants at reduced or no cost. I also note that the current draft contains this requirement for specifications defining additional suffix information: * The specification of valid keys MUST be available over the Internet and at no cost. * The specification MUST be in the public domain or available via a royalty-free license acceptable to the IETF and specified in the RFC. * The specification MUST be versioned, and each version of the specification MUST be numbered, dated, and stable. These requirements would seem to make incorporation by reference of additional information specified in ISO 8601-2 very difficult. On the technical side of things, and ignoring for the moment the possibility of ISO-8601 inspired changes in RFC 3339 - the only information suffix information actually defined by the current draft is the ability to specify a time zone rule: time-zone-char = ALPHA / "." / "_" time-zone-part = time-zone-char *13(time-zone-char / DIGIT / "-" / "+") ; but not "." or ".." time-zone-id = time-zone-part *("/" time-zone-part) time-zone = "[" time-zone-id "]" (I note in passing that this ABNF appears to omit the possibility of there being a tzidprefix as part of the time-zone-id.) And as it happens, time zone rule specification is, AFAICT, addressed nowhere in ISO 8601. So the question becomes one of whether ISO 8601 - part 2 in particular - specifies anything that makes sense to put in the information suffix. And the answer to that is some things clearly qualify, some clearly do not, and others... hard to say. For example, since we're still describing an instant in time, things like durations and sets of dates pretty clearly don't fit. Seasons, OTOH, do fit. But what about precision? (I don't think the way ISO 8601-2 specifies precision is going to be particularly useful, but let's ignore that for now.) On the one hand, this is about specifying an instant in time. On the other hand, things are rarely that precise. And there's also the not-insignificant fact that precision is really data, not metadata, so does it belong in the information suffix? One takeaway here is that the specification needs to be a lot more precise about what can go in the informative suffix and what can't. It seems to me that an obvious dividing line is nothing in the suffix can move the instant in time around, but beyond that things get a little sticky. Beyond that, it seems clear that any review of ISO 8601-2 is going to get close to, and may actually cross over into defining additional suffix information. (Which, FWIW, I think would be a good thing - I think specifications defining registries are almost always improved by specifying at least one initial entry in the registry.) But this may be more work that the WG is prepared to do. Ned > FWIW, I completely agree with Ned, especially wrt the issues of > the confusion and potential interoperability issues associated > with creating inconsistent standards and terminology. To > further complicate things, RFC 3339 is based on on the 1988 > version (or perhaps, given an additional reference that is not > cited, the 2000 one) of ISO 9601. There is now a 2019 version > of ISO 8601, with the scope of the 1988 version extended and > split into two parts, the second specifically concerned with > extensions. Any charter that proposes to tinker with RFC 3339, > potentially even including incorporating it by reference as Ned > suggests should have, as its first charter item, a careful > review of the current version of ISO 8601-1 and 8601-2 to > understand if, or how, they might affect the rest of the effort. > Failure to do so could lead us to three inconsistent ways of > doing things, not just two (which is one too many). > john > --On Tuesday, June 1, 2021 09:43 -0700 ned+dispatch@mrochek.com > wrote: > > I have to object to a working being chartered with this remit. > > > > The main problem is that the charter specifies that a variant > > of RFC 3339 is to be embedded in this new specification, with > > no consideration given to the alternate approach of > > incorporating either RFC 3339 or an RFC 3339bis by reference. > > > > This really isn't the time or place to get into all of the > > reasons why incorporation by reference is a much better way to > > do this, so I'll simply note that even if you ignore the > > confusion this can cause, having text in two places that > > describes the same thing has proved to be a maintenance > > nightmare on many previous occasions. > > > > At an absolute minimum the choice of reference versus > > embedding should be left to the working group, rather than > > being effectively chosen by the charter, and this needs to be > > made very clear from the outset. > > > > The charter also says that: > > > >> It is anticipated that this document would be a companion > >> to RFC3339 rather than a replacement, embedding an > >> unaltered RFC3339 instant along with the contextual data. > > > > Except the current draft cited as a "good basis" for this work > > doesn't actually do this. Rather, it preemptively extends RFC > > 3339 in not one but two ways: > > > > (1) Years are extended to six digits > > (2) Local offsets are extended to allow seconds and fractions > > of seconds. > > > > Given the ability of the metadata (what the draft calls the > > "informative suffix") to specify complex time zone rules, I > > question the need for (2), but again, this is neither the time > > nor the place to get into these sorts of details. The point is > > that this isn't "an unaltered RFC3339", and if this work were > > to end up specifying this new format but not updating RFC > > 3339, we will then have have two incompatible formats for > > basic timestamps. > > > > Another problem is that the current draft makes a number of > > unnecessary changes to the RFC 3339 ABNF, e.g., full-time > > becomes time-full, full-date becomes date-full, date-fullyear > > becomes date-year, etc. Even granting that the new names are > > in some sense "better", the problem is that other > > specifications can and do reference specific rules in > > specifications like RFC 3339, and when you change the the rule > > names, you complicate the update process for all of these RFCs. > > > > Finally, I concur with Carsten Bormann's point about noting > > that this is exclusively a *text* format for date time values. > > Simply inserting the word "text" in a couple of places would > > sufficient. And FWIW, I don't think extending the current > > charter to cover binary formats is a good idea. If such a > > thing is to be done, it should be accomplished via a recharter. > > > > Ned > > > > > >> Hi all, > > > >> (CC dispatch for information) > > > >> The charter for the Sedate working group has passed the first > >> phase and is now in external review. Additionally, the sedate > >> mailing list has been created. Do go over there and subscribe > >> if you are interested. > > > >> Now is the time to let the IESG know of any comment you might > >> have on the charter text. > > > >> I am also looking for volunteers to chair the wg. It is ok to > >> volunteer someone you think would be a good fit. I hope that, > >> given the interest in this work, we will not have problems > >> finding chairs, but as a reminder: please do consider > >> volunteering if you support this work, as with no chairs > >> there will be no working group. > > > >> Please reply to this thread (dropping the dispatch mailing > >> list), or send an email to the IESG (iesg@ietf.org), or > >> directly to me with any comments on the charter, or > >> volunteering as chair. > > > >> Thanks, > >> Francesca > > > >> On 01/06/2021, 16:0䨳㸀㸀 ࠀ From nobody Thu Jun 3 15:16:01 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0D33A1C91; Thu, 3 Jun 2021 15:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 (2048-bit key) header.d=igalia.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 Lph7hOy3_luI; Thu, 3 Jun 2021 15:15:54 -0700 (PDT) Received: from fanzine.igalia.com (fanzine.igalia.com [178.60.130.6]) (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 4D10A3A1C90; Thu, 3 Jun 2021 15:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=O+hFObihp04TEYpsXMv77ABlBn3V3sZQeCFvpd3AIi0=; b=UGk9Ej9Is7YEENl6QQhExOci+6Uihtidehr4VAl9mOt82Hg4SWhPbjj1qVgtkJIsSIs4/HxFr3fDel8ypFDJ8UTTd+EnvFmdVIlh618H5fORwwYSTkxgn6pvqdJyiAHKXi0HGCPH3gotvrmYjKevb2Pulf3KQm5L1V9xRtxayHskcMHYIcnoj7zwhOfV7Xb3GTeRn3OKq4/oX+HRhirTHGjWEKxwTlneOWZk4bTTXYMbjk0/HUYfa4eFP/DHNrGxPYvEx0oG3WAMAQlLRBEYZt51BmwXnEfVnq01YvgrGZ8aRTz16OKacTyWRhI9l/j5QAswVWNYnwPOw7/50PC/aQ==; Received: from [183.83.213.107] (helo=[192.168.0.190]) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1lovcv-0003j2-UZ; Fri, 04 Jun 2021 00:15:46 +0200 To: ned+dispatch@mrochek.com, Francesca Palombini Cc: "dispatch@ietf.org" , "sedate@ietf.org" References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <01RZPZV5ELIY0085YQ@mauve.mrochek.com> From: Ujjwal Sharma Organization: Igalia S.L. Message-ID: Date: Fri, 4 Jun 2021 03:45:33 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <01RZPZV5ELIY0085YQ@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 22:16:00 -0000 Hey Ned! On 01/06/2021 22.13, ned+dispatch@mrochek.com wrote: > The main problem is that the charter specifies that a variant of RFC 3339 is to > be embedded in this new specification, with no consideration given to the > alternate approach of incorporating either RFC 3339 or an RFC 3339bis by > reference. The draft is the way it is right now because the original idea was to obsolete RFC 3339 in favor of it, and I haven't managed to set apart enough time to properly update it. > This really isn't the time or place to get into all of the reasons why > incorporation by reference is a much better way to do this, so I'll simply note > that even if you ignore the confusion this can cause, having text in two places > that describes the same thing has proved to be a maintenance nightmare on many > previous occasions. I don't have any opinions on the matter, but I agree with the principle. > At an absolute minimum the choice of reference versus embedding should be left > to the working group, rather than being effectively chosen by the charter, and > this needs to be made very clear from the outset. Right, I suppose we should change the charter... Is there someone who strongly feels that the charter *should* mandate this? > The charter also says that: > >> It is anticipated that this document would be a companion to RFC3339 rather >> than a replacement, embedding an unaltered RFC3339 instant along with the >> contextual data. > > Except the current draft cited as a "good basis" for this work doesn't actually > do this. Rather, it preemptively extends RFC 3339 in not one but two ways: > > (1) Years are extended to six digits > (2) Local offsets are extended to allow seconds and fractions of seconds. I think your comment here highlights how the charter might be a tad inconsistent with itself since above we talked about "a variant" of RFC 3339 being acceptable. Talking more specifically about the two changes here, they were done just to reflect the changes that have landed in ISO 8601 over the last couple of years. ECMA TC39 used ISO 8601 as the basis and added the extensions on top of it, so I snuck these two changes in to make the final result consistent. That said, I'd be fine to drop them if needed (or make a second draft that does replace RFC 3339 and *just* has these two changes which we could then reference in the draft with the extensions). > Another problem is that the current draft makes a number of unnecessary changes > to the RFC 3339 ABNF, e.g., full-time becomes time-full, full-date becomes > date-full, date-fullyear becomes date-year, etc. Even granting that the new > names are in some sense "better", the problem is that other specifications can > and do reference specific rules in specifications like RFC 3339, and when you > change the the rule names, you complicate the update process for all of these > RFCs. This is just feedback for the draft, nothing to do with the charter. As I mentioned previously, the original idea was to obsolete RFC 3339 and also nobody else raised this concern before. I would be happy to revert to the old ABNF, which would especially make sense if we split the draft into two, one obsoleting RFC 3339 and the other referencing the former. > Finally, I concur with Carsten Bormann's point about noting that this is > exclusively a *text* format for date time values. Simply inserting the word > "text" in a couple of places would sufficient. And FWIW, I don't think extending > the current charter to cover binary formats is a good idea. If such a thing is > to be done, it should be accomplished via a recharter. I agree that binary formats are out of scope here. I'd be happy if the charter were updated to reflect that. Hope I've managed to address your concerns, Best, Ujjwal -- Ujjwal "Ryzokuken" Sharma (he/him) Compilers Hacker, Node.js Core Collaborator and Speaker From nobody Thu Jun 3 16:01:24 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986C63A1E01; Thu, 3 Jun 2021 16:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_FAIL=0.001, SPF_HELO_NONE=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 pJsoW8BUaBB6; Thu, 3 Jun 2021 16:01:17 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::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 42EDB3A1DFD; Thu, 3 Jun 2021 16:01:17 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Fx1bY22gSz316G; Fri, 4 Jun 2021 01:01:13 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <01RZSYH3BXYS00IM2V@mauve.mrochek.com> Date: Fri, 4 Jun 2021 01:01:12 +0200 Cc: John C Klensin , DISPATCH , sedate@ietf.org, ned+dispatch@mrochek.com, Francesca Palombini X-Mao-Original-Outgoing-Id: 644454072.878088-71877965fe042f016206ea3e77a353b0 Content-Transfer-Encoding: quoted-printable Message-Id: References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <01RZPZV5ELIY0085YQ@mauve.mrochek.com> <48D3CA53295C2C8C1045A23D@PSB> <01RZSYH3BXYS00IM2V@mauve.mrochek.com> To: ned+sedate@mrochek.com X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 23:01:22 -0000 On 2021-06-03, at 21:35, ned+sedate@mrochek.com wrote: >=20 > That said, I'm very concerned by the fact that the revised ISO 8601 > specifications are not freely available, and the cost to obtain them = is nothing > short of outrageous: 336 CHF ($371 at today's exchange rate). These = are also > hugely complex highly technical specifications, IMO incapable of being > summarized in any useful way. This means that anyone wishing to = participate in > significant technical discussion involving them is going to need to = purchase > copies. This represents a very significant burden to anyone wishing to > participate in the discussion without a corporate sponser willing to = bear the > cost. To be blunt, I=E2=80=99d suggest we (almost) entirely ignore ISO = 8601:2019. My spies tell me ISO 8601-2:2019 was created as a container for a number = of the ideas that aren=E2=80=99t so relevant for text-based date-times = (uncertainties? Spring Northern Hemisphere? Quadrimesters?). ISO 8601-1:2019 seems to have 6-digit years (=C2=B1NNNNNN, so it=E2=80=99s= +002021-06-03T22:44:37.095927Z here right now), which we should adopt = (but certainly not century or decade references and lots of other = innovations that are great for library managers but not so much on the = Internet). I think there should be a really high burden of proof for anyone wanting = to bring anything else that hasn=E2=80=99t been part of the version of = ISO 8601 that was used at the time RFC 3339 was published. (This should be in the charter, and the details can then be discussed in = the WG.) The Temporal proposal in TC39, however, is highly relevant. However, it seems it is at stage 2... Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jun 3 23:12:19 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD933A2AE8; Thu, 3 Jun 2021 23:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 (2048-bit key) header.d=igalia.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 Fu0bZoCg17zz; Thu, 3 Jun 2021 23:12:12 -0700 (PDT) Received: from fanzine.igalia.com (fanzine.igalia.com [178.60.130.6]) (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 90B243A2ABE; Thu, 3 Jun 2021 23:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=SnElsK9XY6sHEB0nmePpWfZBBC9BYtn5GrwnV8qK90g=; b=kxRV570D83bD/vmrhRdXDcNOI7Ye7JhD+hDDV9Ev4MElwzgP/gz2e1YQUj4E6Hi1rULp7lIEWFAdGbLFKYaQeL7Hn7GpJb827zpyMpxJLfmKWhpMYKaXpObYLD8CKgNiHMt9vp2moYeM/U+j12pboSm8Q6ecinVKCkLzqep4BytRo2ixhleRYXZBlzeRfe0ZcssbaDJmxgE90PSflC9Jbg1C9gEEFhX1IgZFT110tH7u2leG+7a9w1/rbMXTeX2uCbYE3YjBPBNEa3stZdIoAj5BNE99/zBi3jYkwvA2Ubkhzpsaw6Y0j/HAJUwwNQfD2eFFRG/G0RbAewGVDhKEiQ==; Received: from [183.83.213.107] (helo=[192.168.0.190]) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1lp33r-0005cr-OC; Fri, 04 Jun 2021 08:12:03 +0200 To: Carsten Bormann , ned+sedate@mrochek.com Cc: DISPATCH , sedate@ietf.org, Francesca Palombini References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <01RZPZV5ELIY0085YQ@mauve.mrochek.com> <48D3CA53295C2C8C1045A23D@PSB> <01RZSYH3BXYS00IM2V@mauve.mrochek.com> From: Ujjwal Sharma Organization: Igalia S.L. Message-ID: Date: Fri, 4 Jun 2021 11:41:51 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 06:12:17 -0000 Hey Carsten! On 04/06/2021 04.31, Carsten Bormann wrote: > My spies tell me ISO 8601-2:2019 was created as a container for a number of the ideas that aren’t so relevant for text-based date-times (uncertainties? Spring Northern Hemisphere? Quadrimesters?). > ISO 8601-1:2019 seems to have 6-digit years (±NNNNNN, so it’s +002021-06-03T22:44:37.095927Z here right now), which we should adopt (but certainly not century or decade references and lots of other innovations that are great for library managers but not so much on the Internet). > > I think there should be a really high burden of proof for anyone wanting to bring anything else that hasn’t been part of the version of ISO 8601 that was used at the time RFC 3339 was published. > (This should be in the charter, and the details can then be discussed in the WG.) I agree here. There were parts of ISO 8601 that were excluded from RFC 3339 and we should adopt a similar strategy here, avoiding anything that seems to be excessive. As a matter of fact, I chose to only include the expanded year format as well as sub-minute offsets because they were the only additions that seemed reasonable to me at the time. I'd be happy to consider further additions, but I agree that they should be well-justified to make the cut. > The Temporal proposal in TC39, however, is highly relevant. > However, it seems it is at stage 2... This is no longer true, since Temporal has reached Stage 3 in the TC39 process and many delegates are already working on implementing it in various engines. However, none of the implementations would ship unflagged until we move ahead with this work since the format might still be in flux... Hope this helps, Best, Ujjwal -- Ujjwal "Ryzokuken" Sharma (he/him) Compilers Hacker, Node.js Core Collaborator and Speaker From nobody Fri Jun 4 01:24:25 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2023A2EC1; Fri, 4 Jun 2021 01:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_FAIL=0.001, SPF_HELO_NONE=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 YbLWfVavyOAI; Fri, 4 Jun 2021 01:24:12 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::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 A62DA3A2EBB; Fri, 4 Jun 2021 01:24:12 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FxG545nZzz2xFs; Fri, 4 Jun 2021 10:24:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Fri, 4 Jun 2021 10:24:08 +0200 Cc: ned+sedate@mrochek.com, DISPATCH , sedate@ietf.org, Francesca Palombini X-Mao-Original-Outgoing-Id: 644487848.400376-c57c71df79dba13dcbf4725a2c0a06ef Content-Transfer-Encoding: quoted-printable Message-Id: <74F05F98-1733-4D38-BC89-0612EC788CBB@tzi.org> References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <01RZPZV5ELIY0085YQ@mauve.mrochek.com> <48D3CA53295C2C8C1045A23D@PSB> <01RZSYH3BXYS00IM2V@mauve.mrochek.com> To: Ujjwal Sharma X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 08:24:16 -0000 >> I think there should be a really high burden of proof for anyone = wanting to bring anything else that hasn=E2=80=99t been part of the = version of ISO 8601 that was used at the time RFC 3339 was published. >> (This should be in the charter, and the details can then be discussed = in the WG.) >=20 > I agree here. There were parts of ISO 8601 that were excluded from RFC > 3339 and we should adopt a similar strategy here, avoiding anything = that > seems to be excessive. >=20 > As a matter of fact, I chose to only include the expanded year format = as > well as sub-minute offsets because they were the only additions that > seemed reasonable to me at the time. I=E2=80=99m ignorant here: What are the use cases for sub-minute TZ = offsets? (And where in ISO 8601:2019 are they specified?) > I'd be happy to consider further > additions, but I agree that they should be well-justified to make the = cut. OK, so we do have some agreement here. >> The Temporal proposal in TC39, however, is highly relevant. >> However, it seems it is at stage 2... >=20 > This is no longer true, since Temporal has reached Stage 3 in the TC39 > process and many delegates are already working on implementing it in > various engines. However, none of the implementations would ship > unflagged until we move ahead with this work since the format might > still be in flux... The question is really whose work will be the leading one here. Do we follow ECMA or does ECMA follow us? Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Jun 5 15:35:25 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005AF3A32EB for ; Sat, 5 Jun 2021 15:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ureavhfVejHb for ; Sat, 5 Jun 2021 15:35:08 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0: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 49FCE3A32ED for ; Sat, 5 Jun 2021 15:35:08 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id 11so6529377plk.12 for ; Sat, 05 Jun 2021 15:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=+zLMmcmEyHfL5g/+eyTAuvidhwRWFfNRT4R/A++9suk=; b=TBPPO2D8kpWax/BoRAOlcrjTr1sBPENikznPcSWh3UqM3yrp4E6gWs/k2NPe6hhrvg /qdg3Gpt0JCZ2nvXohhi6k/JUsSR0dSnz+dsYriVbh42X9/fb9TyhC4ZMx2YgNEjlv4N GRrqxHBFhYSrK0GTXU8W5SBT5dIJl5ce+kTHrmaxo95EKm9GQMRptmA1PGc9QJVAkmjy 463EsKG4/5igUt6hyUfohFbitlVud1SNrGr/KUhVz/zHIogMJ6ZttqmcG5CKeK9qE80N T2DTuaG4MrqDfxHAkyI/i7IUObTh9otO13cu3x21PhYXTJy+OViilPQQer6oKkJLuKKS Rd9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:subject:date:message-id :mime-version:thread-index:content-language; bh=+zLMmcmEyHfL5g/+eyTAuvidhwRWFfNRT4R/A++9suk=; b=eN40K/iRb1Za2im4wzIF+oAtbiKEUgYytJ/s+WHe9YgWNc96zFwPlJ3GeRzdpPc8wg ZdOQGT1DMfWrRdHClgouMdGR+8pLfZnX24H9OjlpZ10gvCJ7EopOw7O2PMggGw7TSBy/ 0NyPBDvz4Yw2MCT50gNdaws040rLCvUVQpHsopyH+6/8tez/sDWIiogK6T/3RtKDBfMu 8FjR1hGczDDJNYaOd3C0iZT5xG/rErVAKGqdVAzgk/bWcXBvMyKUgmPi3UKPnF295jgB 3SvmH6toCeKv3eHDhpNe8rTtOIEBTT4zO4gQDkdVJ/cNSYyGypB3JqsvSxEmcjgEAUYO 6jCg== X-Gm-Message-State: AOAM530zDAlXdSW6/nY1oV6LBFcSO2HoxLVRUl++xt9/0+je5X/uAk80 a5f8YIIAwxGd/FuVsO3ZW42DqqDpePM= X-Google-Smtp-Source: ABdhPJyAtO1ZpcZCLYAxPAKjilXsAMupTIr6y+QmqnQGTIX+XEHE9weEbqLb7Yoj1bJ7qj3yKxYo/g== X-Received: by 2002:a17:90a:8d12:: with SMTP id c18mr24776833pjo.161.1622932506277; Sat, 05 Jun 2021 15:35:06 -0700 (PDT) Received: from TVPC (c-73-158-116-21.hsd1.ca.comcast.net. [73.158.116.21]) by smtp.gmail.com with ESMTPSA id r9sm4763474pfq.158.2021.06.05.15.35.05 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Jun 2021 15:35:05 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: Date: Sat, 5 Jun 2021 15:35:05 -0700 Message-ID: <002501d75a5b$08694740$193bd5c0$@acm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01D75A20.5C0B0B80" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AddaWfrhkLO3fg+UQKyf8VcZPCTUwQ== Content-Language: en-us Archived-At: Subject: [dispatch] RFC 3896 and 3987 vs WHATWG URL Living Standard X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2021 22:35:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0026_01D75A20.5C0B0B80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Recent progress on WHATWG's URL spec led me to suggest a BOF on the topic for IETF 111 Provide a succinct grammar for valid URL strings . Issue #479 . whatwg/url (github.com) But I didn't get an ack, and perhaps this belongs in DISPATCH/ART etc. -- https://LarryMasinter.net https://interlisp.org ------=_NextPart_000_0026_01D75A20.5C0B0B80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Recent progress on = WHATWG’s URL spec led me to suggest a BOF on the topic for IETF = 111

Provide a succinct = grammar for valid URL strings · Issue #479 · whatwg/url = (github.com)

 

But I = didn’t get an ack, and perhaps this belongs in DISPATCH/ART = etc.

 

 

--

https://LarryMasinter.net https://interlisp.org

 

------=_NextPart_000_0026_01D75A20.5C0B0B80-- From nobody Sat Jun 5 19:21:28 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513923A0C03 for ; Sat, 5 Jun 2021 19:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 YkxH_ss7SS44 for ; Sat, 5 Jun 2021 19:21:23 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9AB93A0C06 for ; Sat, 5 Jun 2021 19:21:22 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lpiPg-0006o5-Rk; Sat, 05 Jun 2021 22:21:20 -0400 Date: Sat, 05 Jun 2021 22:21:14 -0400 From: John C Klensin To: Larry Masinter , dispatch@ietf.org Message-ID: In-Reply-To: <002501d75a5b$08694740$193bd5c0$@acm.org> References: <002501d75a5b$08694740$193bd5c0$@acm.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] RFC 3896 and 3987 vs WHATWG URL Living Standard X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2021 02:21:27 -0000 --On Saturday, June 5, 2021 15:35 -0700 Larry Masinter wrote: > Recent progress on WHATWG's URL spec led me to suggest a BOF > on the topic for IETF 111 > > Provide a succinct grammar for valid URL strings > . Issue #479 . > whatwg/url (github.com) > > But I didn't get an ack, and perhaps this belongs in > DISPATCH/ART etc. Larry, This is a question rather than a statement of preference because I have not thought about it in some time, but are you thinking it may be time to either revise or deprecate 3896 and 3897? I may not have enough information but it seems clear to me that, in terms of the specs to which implementers are paying attention, the action has shifted toward WHATWG (and, to a lesser extent, W3C) and away from the IETF documents. If deprecating the IETF URI and IRI specs is really the question (or part of it), I'd think either a BOF or a well-prepared presentation and a rather large block of time in DISPATCH would be appropriate. best, john From nobody Mon Jun 7 03:45:01 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003983A0E94 for ; Mon, 7 Jun 2021 03:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=J0cWBLq3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Xfpv+/E0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkOD_MYKh4Qt for ; Mon, 7 Jun 2021 03:44:54 -0700 (PDT) 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 A347B3A0E8D for ; Mon, 7 Jun 2021 03:44:54 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5BCFC5C0056 for ; Mon, 7 Jun 2021 06:44:53 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Mon, 07 Jun 2021 06:44:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=uB7Zwyi YoTJl0CA4Nu5YkQi2rjSNM09Wfjaoig01Oow=; b=J0cWBLq3cWlYH/GqqYtYWqE wv/FeP7F8LaHmS/tmy/2xcRKTlonfWzO5O7w0jrx9D7xwr/XLLyok6ZXrdjVM9aA 7J6C0ehWju/ikeyH7Rn7ZXKsptaTAaBpF85/V0POhd+OfR96LdqRB7A5LO0OvbXf SxRAvwd07FUCX/IEbXumXZcLFHgtfcmlIT/2/r7h8+JgC4Nz7IVs9BHXplNjinkW N4WqdScbd/wcGKUCsSwlKas6vcOk4D2yYkOOM44sQyRFPIKdwZoPAkIeD6WNZeZ0 TQnnCLueiMjr4nac0FNE5EspnYbcjIZ3uNcjd6fYnIXfmZZzOHFX27ItiKzhPNQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=uB7Zwy iYoTJl0CA4Nu5YkQi2rjSNM09Wfjaoig01Oow=; b=Xfpv+/E0i1tzHmlQr/vjC1 OvWpZPYtEYKZDvQ68mu2PEPXeKdZeiAqUdyMAYrNO9zfNiMHAgo4pPpYzotfZwBm RrKOkqHsar/TDT53cWXhzlQPixR3Rf8W2S1TTyMmbWYBVNeuNUdwYEfC2AjOp4IL NsTWjvqP+sjAzzAI37gqjwnePxomCh3szlByGloX5KhU+SXt0euqgjGsg9fSKl6o YT3XjrMrz8HisX2PZF1rp6qwETRCmopXlHUiQOFrKmbFRqCYD05+ptiHhMY5AVvh 6Mg5Mrm1RLeiXz4LGp+NjJIEQ0v1bJXOQG7HoWcsqSPjVAtxYgrp/xMZCVSqGa/w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtjedgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedtheetgeefve etudffveetheffgfehhfdvveekuefhheeuteduhefggeeikeejteenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrg hilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B35E0AC0062; Mon, 7 Jun 2021 06:44:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-701-g78bd539edf-fm-ubox-20210517.001-g78bd539e Mime-Version: 1.0 Message-Id: In-Reply-To: <01RZPZV5ELIY0085YQ@mauve.mrochek.com> References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <01RZPZV5ELIY0085YQ@mauve.mrochek.com> Date: Mon, 07 Jun 2021 20:44:31 +1000 From: "Bron Gondwana" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=5ce0dab7564a42c58ab63258103dceb2 Archived-At: Subject: Re: [dispatch] =?utf-8?q?=5BSedate=5D_WG_Review=3A_Serialising_Exten?= =?utf-8?q?ded_Data_About_Times_and_Events_=28sedate=29?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 10:45:00 -0000 --5ce0dab7564a42c58ab63258103dceb2 Content-Type: text/plain On Wed, Jun 2, 2021, at 02:43, ned+dispatch@mrochek.com wrote: > The main problem is that the charter specifies that a variant of RFC 3339 is to > be embedded in this new specification, with no consideration given to the > alternate approach of incorporating either RFC 3339 or an RFC 3339bis by > reference. I take a lot of responsibility for this - and it's this way *because* of the feedback in DISPATCH last time, which was "don't try messing with RFC3339". But I think maybe you also looked at the draft as it was proposed back then because - again - I didn't push hard enough to have an actual draft uploaded which specified basically that this would look something like: "RFC3339{bis}-point-in-time{extended context}" (exact encoding TBD) And that we wouldn't mess with 3339 OR we would BIS 3339 for the first part, and produce another document which referenced RFC3339 or RFC3339bis as the definition for the point-in-time part. This is how I understand the goals of this intended group to be - and if that's not adequately represented in the proposed charter text then I would welcome clarifying edits! Thanks, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --5ce0dab7564a42c58ab63258103dceb2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, Jun 2, 2021, at 02:43, ned+dispatch@mrochek.com wrote:
<= blockquote type=3D"cite" id=3D"qt" style=3D"">
The main problem is that the charter specifies that a variant of= RFC 3339 is to
be embedded i= n this new specification, with no consideration given to the
alternate approach of incorporating eith= er RFC 3339 or an RFC 3339bis by
reference.
<= br>
I take a lot of responsibilit= y for this - and it's this way *because* of the feedback in DISPATCH las= t time, which was "don't try messing with RFC3339".  But I think ma= ybe you also looked at the draft as it was proposed back then because - = again - I didn't push hard enough to have an actual draft uploaded which= specified basically that this would look something like:

"RFC3339{bis}-point-in-time{extended context}" (exact encoding TBD)
=

And that we wouldn't mess with 3339 OR we would BIS 3339 for= the first part, and produce another document which referenced RFC3339 o= r RFC3339bis as the definition for the point-in-time part.

This is how I understand the goals of this intended group to be - and = if that's not adequately represented in the proposed charter text then I= would welcome clarifying edits!

Thanks,

B= ron.


--
  Bron Gondwana, CEO, F= astmail Pty Ltd
  brong@fastmailt= eam.com


--5ce0dab7564a42c58ab63258103dceb2-- From nobody Mon Jun 7 07:47:20 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D853A190C for ; Mon, 7 Jun 2021 07:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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=mrochek.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 ZtZqz7n1ixmG for ; Mon, 7 Jun 2021 07:47:13 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 548FD3A1901 for ; Mon, 7 Jun 2021 07:47:13 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RZY69KAJ4000GUV9@mauve.mrochek.com> for dispatch@ietf.org; Mon, 7 Jun 2021 07:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1623076927; bh=g3rKqa6gBIbJzS14Cl/Oc60DQKX2IjMWHYa7WyaXeUw=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=EZLUh8jmjElUnPS/oKYiGbzsU2lW+EbXq8mv/J0GNX4W7nP5d3OwiqBJ4IJGo9zt4 d3WR33E1F+/YPRr4cudl5v3rzLgQCZavrZG0ihSGPSiLfi7GkR8sKWZCHPaL+XSoEQ yHiwfK7oYyoPoLEAzMR5C1QiLIPq6YMgnoWyFmuI= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RZSK5M2ZAO0085YQ@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dispatch@ietf.org; Mon, 7 Jun 2021 07:42:02 -0700 (PDT) From: ned+dispatch@mrochek.com Cc: dispatch@ietf.org Message-id: <01RZY69GSAQA0085YQ@mauve.mrochek.com> Date: Mon, 07 Jun 2021 06:19:17 -0700 (PDT) In-reply-to: "Your message dated Mon, 07 Jun 2021 20:44:31 +1000" References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <01RZPZV5ELIY0085YQ@mauve.mrochek.com> To: Bron Gondwana Archived-At: Subject: Re: [dispatch] =?utf-8?q?=5BSedate=5D_WG_Review=3A_Serialising_Exten?= =?utf-8?q?ded_Data_About_Times_and_Events_=28sedate=29?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 14:47:18 -0000 > On Wed, Jun 2, 2021, at 02:43, ned+dispatch@mrochek.com wrote: > > The main problem is that the charter specifies that a variant of RFC 3339 is to > > be embedded in this new specification, with no consideration given to the > > alternate approach of incorporating either RFC 3339 or an RFC 3339bis by > > reference. > I take a lot of responsibility for this - and it's this way *because* of the > feedback in DISPATCH last time, which was "don't try messing with RFC3339". But > I think maybe you also looked at the draft as it was proposed back then because > - again - I didn't push hard enough to have an actual draft uploaded which > specified basically that this would look something like: I looked at the draft that cited in the charter as being, and I quote, "A good basis for this work." Nothing more, nothing less. What you are now saying is that wasn't true. And more generally, you asked people to spend time reviewing an obsolete version of the proposed work. This is a good time to point out that the IETF depends on large amounts or work being undertaken by volunteers, corporate sponsored at best, but in many cases, aside from an occasional mention in an acknowledgements section, entirely uncompensated. There has been a lot of talk recently about how to make the IETF more welcoming to newcomers, as well as how to retain people after the work that attracted them to the IETF is finished. I'm afraid I can think of few things more disheartening than a demonstrable lack of concern for wasting people's time. Indeed, in a curious way it's more disrespectful than a direct personal attack, since at least when someone attacks you it's clear that they care about whatever it is you said or did. In any case, in the future, when you propose a charter, please try and make sure it accurately represents the work you want to do. > "RFC3339{bis}-point-in-time{extended context}" (exact encoding TBD) > And that we wouldn't mess with 3339 OR we would BIS 3339 for the first part, > and produce another document which referenced RFC3339 or RFC3339bis as the > definition for the point-in-time part. > This is how I understand the goals of this intended group to be - and if > that's not adequately represented in the proposed charter text then I would > welcome clarifying edits! We are way past this being a matter that can be resolved by a few edits. First, the current charter proposal needs to be withdrawn. You then need to produce two drafts: (1) RFC 3339bis (2) Extended context You then may want to get some preliminary review of these documents, to make sure they track with your intended goals. Or not - it may be that the people working on these specifications have a clear shared understanding of what's needed. Once this is done a new charter needs to be submitted that describes the work to be done, with these two new drafts as a starting point. Given the wide use of RFC 3339, it needs to be very specific about what is or isn't in scope for the revision of that specification. As I said in a previous comment, I have no idea what, if anything, to do about the revised versions of ISO 8601, so I leave that to you to figure out. That said, some of the subsequent comments about ECMA International TC39 and ISO TC154, as well as statements like "Temporal proposal having reached stage 3" and "delegates are already working on implementing it in various engines" seem to me to be even more of a cause for concern. If this work really is as advanced as these statements seem to imply, and is in any way constraining on what we're doing here, then the WG needs access to these specifications. In case it isn't clear, the situation I want to avoid is where someone in the WG comes up with some proposal, only to be told, "Sorry, that's not the TC39 way, and no, I don't have anything to show you what that way actually is." I think that covers it. Ned From nobody Mon Jun 7 08:18:15 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB3F3A1A10 for ; Mon, 7 Jun 2021 08:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=igalia.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 uRW_Y865m0Ac for ; Mon, 7 Jun 2021 08:18:07 -0700 (PDT) Received: from fanzine.igalia.com (fanzine.igalia.com [178.60.130.6]) (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 AE0413A18C6 for ; Mon, 7 Jun 2021 08:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=yrT3ZWVGfE10bCbhyU3b/l58kAS7/gXJr1BJWsDWGx4=; b=JB+ksKhC5qC85m3j/sIYOvFblzeEsRJ8KaZ4C3BHAFw0tKLwWdZaHIP/dxkkdPQSLpQFrzXxD+SMcZ/HGSyB7GHCWlFvPPxC5dVfE990sCORDFJYbC0QBh/AaJMeVrT5vZ+YqSuWwLpbglulq1Pn89K+tFwg+HIiP+VaZb8vNZeHT5nGlQN7Gse+eAGGSJj83MYeJPk2w1cb7BcnqIyX7s4Oyw/2CFMEfXn09aQPwpCVWpsGQIBlE/OILHm5TvfWohIhPpnoJ44g5bHZzk3RKdZvfR+gxLnqotkt15G3kPon6o4CrBtuufsAgW/1JFh2NkyrpipA4PasIYNrNRuQFw==; Received: from [183.83.213.107] (helo=[192.168.0.190]) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1lqH0r-0003xm-T6; Mon, 07 Jun 2021 17:18:02 +0200 To: ned+dispatch@mrochek.com, Bron Gondwana Cc: dispatch@ietf.org References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <01RZPZV5ELIY0085YQ@mauve.mrochek.com> <01RZY69GSAQA0085YQ@mauve.mrochek.com> From: Ujjwal Sharma Organization: Igalia S.L. Message-ID: Date: Mon, 7 Jun 2021 20:47:50 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <01RZY69GSAQA0085YQ@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 15:18:13 -0000 Hi Ned! On 07/06/2021 18.49, ned+dispatch@mrochek.com wrote: > You then may want to get some preliminary review of these documents, to make > sure they track with your intended goals. Or not - it may be that the people > working on these specifications have a clear shared understanding of what's > needed. > > Once this is done a new charter needs to be submitted that describes the work to > be done, with these two new drafts as a starting point. Given the wide use of > RFC 3339, it needs to be very specific about what is or isn't in scope for the > revision of that specification. Pardon my relative inexperience with IETF, but I suppose by RFC 3339bis you mean "a document detailing the updates to RFC 3339 but not the extension format". This document already exists at https://github.com/ryzokuken/draft-ryzokuken-datetime-updated (source), https://ryzokuken.dev/draft-ryzokuken-datetime-updated/documents/rfc-3339.html (rendered) and https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-updated/. The (relatively) smaller diff can be found at https://github.com/ryzokuken/draft-ryzokuken-datetime-updated/compare/original...main (look in the sources folder). The draft that you reviewed is just a version of this RFC 3339bis that also includes the extension format. As mentioned before, this was done because there was not enough clarity around how we could best get consensus around the format. If you prefer that the extension format refer to (and not extend) the RFC 3339bis, then that would work just fine and I suppose we could discuss that in great detail within the WG (personally, I'd be happy either way). > That said, some of the subsequent comments about ECMA International TC39 and ISO > TC154, as well as statements like "Temporal proposal having reached stage 3" and > "delegates are already working on implementing it in various engines" seem to me > to be even more of a cause for concern. If this work really is as advanced as > these statements seem to imply, and is in any way constraining on what we're > doing here, then the WG needs access to these specifications. > > In case it isn't clear, the situation I want to avoid is where someone in the WG > comes up with some proposal, only to be told, "Sorry, that's not the TC39 way, > and no, I don't have anything to show you what that way actually is." You are already aware of the situation around ISO 8601, but all the ECMA TC39 specs and proposals are published freely on the internet. Everything relevant to this work is contained in the "Temporal" proposal which is published at https://tc39.es/proposal-temporal/. Hope this clarifies everything, feel free to ask for further clarification, Ujjwal -- Ujjwal "Ryzokuken" Sharma (he/him) Compilers Hacker, Node.js Core Collaborator and Speaker From nobody Mon Jun 7 11:02:25 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F56A3A184C for ; Mon, 7 Jun 2021 11:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 2iyOAQbMDKPu for ; Mon, 7 Jun 2021 11:02:19 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E523A4013 for ; Mon, 7 Jun 2021 11:02:19 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lqJZm-000Dz0-N4; Mon, 07 Jun 2021 14:02:14 -0400 Date: Mon, 07 Jun 2021 14:02:09 -0400 From: John C Klensin To: ned+dispatch@mrochek.com, Bron Gondwana cc: dispatch@ietf.org Message-ID: <2709CC919F79613418800AEC@PSB> In-Reply-To: <01RZY69GSAQA0085YQ@mauve.mrochek.com> References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <01RZPZV5ELIY0085YQ@mauve.mrochek.com> <01RZY69GSAQA0085YQ@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 18:02:24 -0000 Bron, I largely (almost completely) agree with Ned's comments, especially about moving targets and people's time, but let me add one thing. --On Monday, June 7, 2021 06:19 -0700 ned+dispatch@mrochek.com wrote: > That said, some of the subsequent comments about ECMA > International TC39 and ISO TC154, as well as statements like > "Temporal proposal having reached stage 3" and "delegates are > already working on implementing it in various engines" seem to > me to be even more of a cause for concern. If this work really > is as advanced as these statements seem to imply, and is in > any way constraining on what we're doing here, then the WG > needs access to these specifications. > In case it isn't clear, the situation I want to avoid is where > someone in the WG comes up with some proposal, only to be > told, "Sorry, that's not the TC39 way, and no, I don't have > anything to show you what that way actually is." Having parallel, unsynchronized, efforts among standards bodies with very different work styles and keeping them coordinated is extremely difficult -- not impossible, but difficult and requiring significant energy. Agreements that establish clear "who does what" boundaries and that are accepted by all SDO parties can help a lot, sometimes even solve the potential problems, but I have see no sign of such clear and agreed boundaries in anything I have seen so far of this WG proposal. Without either such boundaries or very significant coordination, the odds are very high of ending up with either the situation Ned describes above or the closely related one of ending up with two standards that conflict, perhaps only in minor ways but sufficient to confuse everyone (IIR, Ned mentioned that earlier too). So I would like to see something else considered. Is it possible to consider, and explain clearly (and without the specific details of an extension specification or 3339 update) to both the IETF and to the relevant ECMA and ISO groups, what we (the Internet and/or the IETF) need in dates and times that is not covered by ISO 8601-1:2019 or ISO 8601-2:2019 (let's just ignore 3339 for the moment)? If the goals of this proposed WG are understood well enough, it ought to be possible to describe those requirements in a succinct and clear way without needing a WG. If they are not, then, IMO, a WG charter is premature. With such a description in hand, it becomes possible to ask another question, which is whether such work is best done in the IETF (and, if so why) or whether it should simply be developed and processed in ECMA and ISO, via a New Work Item for either an Amendment or something that might evolve into 8601-3 as appropriate? Presumably that would come with arrangements for IETF participants to provide input who are not already involved in 8601* via some national member body, ECMA, or some other organization. If that sort of approach made sense, the next step would be to produce a 3339bis that was just a summary or profile of 8601*, working with ISO to quote sufficiently from their standards to make 3339bis essentially self-contained. I'm not sure that approach is the right answer but, noting that RFC 3339 is about conventions for use on the network but is not, itself, a network protocol or piece of network engineering and that ISO 8601* has far, far, broader uses and applications than the Internet, I think it should be examined before we either try to do that coordination work or decide we can proceed on informal relationships and otherwise without it. best, john\ From nobody Mon Jun 7 21:31:15 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF7B3A2059 for ; Mon, 7 Jun 2021 21:31:13 -0700 (PDT) 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_H4=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=NsSvmcIQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=L1awhLYe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKka5a-ssF_i for ; Mon, 7 Jun 2021 21:31:07 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B75A63A2054 for ; Mon, 7 Jun 2021 21:31:07 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 6A4F85C015E; Tue, 8 Jun 2021 00:31:04 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 08 Jun 2021 00:31:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=y 8NHqbYhOdGfQmfkGIdrIwqQi9yoMpVuGaPsFoytGxU=; b=NsSvmcIQMcTAlQ77M /lSW/BmDVfXmqmdDB/Gi3M/+TLmkUjBMVEvtrLGXgPJNHRiCuaMoGxMkeH6I1coF ICWaMGtfN/+SKvzLM9O4qp1fWbV1+agZlbR+IMmbO5sVjNobY27QXer4r9pALvX3 M4e9IiM5+746m+p9KGfe2lobqsWgZP/L27f1q93aUROSHrz73QHNognSsGZJJseG KqFqmmYYta4FpaVjvlrGMThquagsF0q8mBK9jOQG6x7e6QEMLvpHl563cbClMZWT Ac0wlQjmfpWiZyiFQlU0WPkwXABKQZI7KVMmBI7dBbJT/JrZK9VxMNl6XbnjR3SE /sayw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=y8NHqbYhOdGfQmfkGIdrIwqQi9yoMpVuGaPsFoytG xU=; b=L1awhLYeAO0Y735nYaC/VsveTgYhScQnWUxwp51eep1XiwkHVVEs3vCtd dWZkPz0HvacqI0AUTlq7DJenNYWy0oJ0GxQ7oeOkztqX3zfFD5zj9scYHvwTYyp2 2bTVOEhJaZlclX7BY6TiXTSZb1D2bG+tEulJY2KJBPnp9cPboe+AUaQ7uQzawF2z v3K9GcOF47KMHV3hOJc9nJdFVMULkdLoRDjA1FCQAS5npE/PCmCzlkL6z1asVb1Z fMFJFtGgbsqRJ5fzO4OQ1vBIhzraU0ES+6cPWfCpGifXQK0OGhX3+Xw+NzOYhyiY M97xQ8smjPwgh95RafXmtj2wxKrdw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtkedgjeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeevffffhfduteevvefhueffieegtdeutdehffeltefffedttdeggeejheeiueet teenucffohhmrghinhepmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 8 Jun 2021 00:31:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Mark Nottingham In-Reply-To: Date: Tue, 8 Jun 2021 14:30:53 +1000 Cc: Ned Freed , DISPATCH list Content-Transfer-Encoding: quoted-printable Message-Id: References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> <01RZSLCQGG9Y00IM2V@mauve.mrochek.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [dispatch] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 04:31:13 -0000 On 4 Jun 2021, at 1:21 am, Murray S. Kucherawy = wrote: >=20 >> While I don't have a problem with doing this if IANA doesn't, and if = it makes >> things easier for IANA so much the better, I am dubious that this = actually >> solves the problems people have with registering media types. >>=20 >> The complaints I've heard about the media type registration process = concern the >> lack of guidance as to how to fill in the various fields. I took a = look at the >> two examples, and I don't see how using what appears to be a = completely free >> form interface will address that. >>=20 >> At a minimum some justification needs to be given as to why this = approach >> will be an improvement. >>=20 > There were two proponents for adding this to the charter, so I'll let = them pipe up here. The interfaces aren't freeform; if you create an issue, you'll see it = uses a template to fill out. Furthermore, the README of each repo = provides guidance. Stepping back, though, I think the bigger question here is whether the = registry policies are still fit for purpose. Right now, a URI scheme can = be registered provisionally on a FCFS basis, and those schemes are not = syntactically distinguished from permanent schemes. OTOH, media types do = syntactically distinguish standards-track registrations from others, and = places several additional hurdles in the place of those registrations = (which by far are the most desirable). This difference in policies is strikingly odd, and seemingly arbitrary. = It would be good to understand why there is a difference, and whether = it's still justifiable.=20 If the community comes to an understanding that the barriers to = registration are appropriate, the current procedures are likely adequate = (although it'd be good to get feedback from other standards bodies). = However, if they're to be changed, the registration procedure would need = consideration too. With that in mind, I suggest replacing the bullet about GitHub with: * Evaluate the registry policies and procedures in the context of how = media types are currently used, and modify them if necessary. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Jun 7 23:37:28 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7943A2450 for ; Mon, 7 Jun 2021 23:37:26 -0700 (PDT) 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_H4=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=l2oENm5p; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kTXDu7LW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unmc7yE2Jdzx for ; Mon, 7 Jun 2021 23:37:21 -0700 (PDT) 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 C7F923A2467 for ; Mon, 7 Jun 2021 23:37:21 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 994F6177D; Tue, 8 Jun 2021 02:37:20 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 08 Jun 2021 02:37:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=I hOwBL6WhQPSLYX3ynZAYoOFlXM4l7oldLgD+2v8EK0=; b=l2oENm5pMp84IgVSz 0bxcjyMR2Ra5veCUGKrsNZlmjm6DhHjogscLUPZyzc+u/ycYiz3vQHfyOEty7/5U tDl7NNoTLgEA5Hlor9YgXuHADAXd9JxOMk5WEUsHiibfdaDqe/GjmrXv89g08Fg9 6hj2ldu0ilqe2RBl00zHygDhAudDE01aMSKR74NafmsFvOSuRS3edHcgqoJTxYTS bTe9SVyo2NaimUY3RKteu9ksYqydtTwj/kJlfh0jaUbfCATawURKbM2rLJMKfwPO +UCA/vxH8Y6Dapj/jvhRiN8jH4z3OrOLDWpF6zEFJVjelqLto8GFcnptfV7khn2v +zTCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=IhOwBL6WhQPSLYX3ynZAYoOFlXM4l7oldLgD+2v8E K0=; b=kTXDu7LWAHpJRwOK7xRe9b7jk1rgJLwx9MZ6caByMSy5jZFOTXz+duGr2 BZO7yTdirPR+zIHTzdAYyNeu3wU733ZUiq5rP9do0j+DKXVK+j534mL7DqeTqzdv t8/hW8UrtQCqk27RZyVo2wXOdFU8gmySgjyy9qkv54H714HPZ5eMRpgiYyhWXWiY PXbOT9EhxQ1OjgYlkY7Qrjs/o7xCjBIXlU2juVjtiLNUMA615wPHd8FEk6QKmGmE ylc5dn4UxE0sjuWrndNpNlUXb7BYlRHt557LXEfOkbjT3m7i8SYLYIlEpRgKRqbZ iVVMvd5NtkUm+DwXj1p4QmJ8PBy+Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtkedguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesth hqmhdthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothes mhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeeilefghefggfeuieeutdegieeivd elffdulefgiedvtefhkedvleevkefhkeetveenucffohhmrghinhepghhithhhuhgsrdgt ohhmpdhivghtfhdrohhrghdpmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 8 Jun 2021 02:37:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Mark Nottingham In-Reply-To: Date: Tue, 8 Jun 2021 16:37:14 +1000 Cc: Larry Masinter , dispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <002501d75a5b$08694740$193bd5c0$@acm.org> To: John C Klensin X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [dispatch] RFC 3896 and 3987 vs WHATWG URL Living Standard X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 06:37:27 -0000 My sense right now is that it's not (yet) appropriate to deprecate = 3986/7. Even if we could ignore the non-Web folks using URIs and IRIs (and there = are perhaps good arguments for considering that, IMO, although I know = that others have strong feelings, and there's a lot of history here), = the current WHATWG specification doesn't specify them -- it specifies = how to get from an arbitrary string to what a browser considers a URL to = be. It doesn't specify grammar, and it doesn't cover many of the things = that 3986 in particular does. The issue that Larry links to seems to be taking tentative steps towards = aligning the grammar in 3986/7 with what WHATWG does, which is great. If = that's incorporated, I think there's still a significant gap that would = need to be filled before we can deprecate. Even if that gap were to be = filled, I question whether the WHATWG is an appropriate home for the = specification -- although obviously the W3C has come to peace with HTML = living there. Looking at this from a different angle, we could also ask ourselves = whether 3986/7 should be updated to align with WHATWG URL. I think the = answer to that is likely to be no -- not only is the delta apparently = very small (according to the comments on the linked issue), alignment = would mean doing things like considering <> to be valid content in URIs. = Again, what they're specifying is how to get from an arbitrary string to = a URI, not the syntax itself. Actually, one useful thing we *could* do would be to replace section = 1.1.3 of RFC3986 with something that actually helps people understand = the differences between all of these things. If we ceded 'URL' to the = WHATWG, leaving 3986 to define URI, it might help. Cheers, > On 6 Jun 2021, at 12:21 pm, John C Klensin wrote: >=20 >=20 >=20 > --On Saturday, June 5, 2021 15:35 -0700 Larry Masinter > wrote: >=20 >> Recent progress on WHATWG's URL spec led me to suggest a BOF >> on the topic for IETF 111 >>=20 >> Provide a succinct grammar for valid URL strings >> . Issue #479 . >> whatwg/url (github.com) =20 >>=20 >> But I didn't get an ack, and perhaps this belongs in >> DISPATCH/ART etc. >=20 > Larry, >=20 > This is a question rather than a statement of preference because > I have not thought about it in some time, but are you thinking > it may be time to either revise or deprecate 3896 and 3897? I > may not have enough information but it seems clear to me that, > in terms of the specs to which implementers are paying > attention, the action has shifted toward WHATWG (and, to a > lesser extent, W3C) and away from the IETF documents. >=20 > If deprecating the IETF URI and IRI specs is really the question > (or part of it), I'd think either a BOF or a well-prepared > presentation and a rather large block of time in DISPATCH would > be appropriate. >=20 > best, > john >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jun 8 05:43:49 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E400D3A2F96 for ; Tue, 8 Jun 2021 05:43:47 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=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 (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 0nvEoqBs0-hJ for ; Tue, 8 Jun 2021 05:43:43 -0700 (PDT) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 7955C3A2F95 for ; Tue, 8 Jun 2021 05:43:43 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id k25so26903376eja.9 for ; Tue, 08 Jun 2021 05:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=1PBR7UQ3JKXZrf37EYH4u9BN+opiJ18Div/UcljRXDM=; b=dEcFuZ9IVK7iQpJM0dPq80ApnW1oRMPloprif+3/0AXt5TwBNpX7wo14jVdBdkJV0P A9UtEwxDkpiZmXj2sTUkhM+n9qlD4CoSkVGAfg4dvLtfU5kAEgQ2elzMaS0IoxeYxV13 6pi1QVa0l0fbnm7wH6zxcWSBIDXOz8NH+LlaaTjzRkPU+gt9UGztwbT1ZlT7i+jZqa9/ 9ZLL/Gn/32X15mf9wwCel9gon0SpSXx4w/Q6dkiECRAhkN07b+VKw98siNK6NyEFzdhs a/O4NOPi/PLp/E3KJbkLS+9EJBOTGvYwbPacbpSLq6fIHlseAoGCNpOFYMNvxSjt89UI lkzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=1PBR7UQ3JKXZrf37EYH4u9BN+opiJ18Div/UcljRXDM=; b=Ni/E5CQfHIcaiqyIV510SFF9cs7Ww0WwcIDZMBtvnDu32dz5crwPnAcHf86ALC+vVs iR+zw4lBAgOgJMCLg3EDImAIOymPSB0j0R21rTLdRkGnx90T0ceBvdeTZ94xLJ9ka4w1 0JYd0wJekdztZJo8HsKD+8VUQrXP87VDZKTvqd98a2iswqp62LhGUBA2hjjRk7rG2N0U 9DwMjLj/7aEjLz7Xwm8RF0tUod7sfEPu3R3/jHDJKd0uRJx6npMiVJkSq4LiJA22FCLc xPdo/tztCGtI3NNSHxNDJxkxX1fofgXgttHdmGk2pVYW/L8A8AoKhuOOXwTJmXW66Qv9 Hrew== X-Gm-Message-State: AOAM5303vSl2b6vcdJAyrl9dSECIStxZ3Gan+vuajVFUO4NAeL7zHMlP AFUNeELgGrQFlQJAOBiYHI+Y2d2PWfU= X-Google-Smtp-Source: ABdhPJxSVvDJlY/z84Q+7QSkdW2+k8O9Hvd+2cmc24cykiIxrMCPO66W3AoYvwAoeLx1lriiO0rN5w== X-Received: by 2002:a17:906:4308:: with SMTP id j8mr23541442ejm.315.1623156220677; Tue, 08 Jun 2021 05:43:40 -0700 (PDT) Received: from [192.168.1.166] ([87.214.169.250]) by smtp.gmail.com with ESMTPSA id br24sm7716786ejb.55.2021.06.08.05.43.40 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Jun 2021 05:43:40 -0700 (PDT) From: Alwin Blok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Tue, 8 Jun 2021 14:43:39 +0200 References: <002501d75a5b$08694740$193bd5c0$@acm.org> To: dispatch@ietf.org In-Reply-To: Message-Id: <673E6113-F219-4865-9636-3D1EC9C8DACD@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [dispatch] RFC 3896 and 3987 vs WHATWG URL Living Standard X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 12:43:48 -0000 Hello,=20 I have recently subscribed to this mailing list after seeing Larry = Masinter's message on the issue tracker of the WHATWG URL Standard = .=20 I have done a lot of research on the WHATWG URL standard. Some of the = results can be seen on my personal GitHub page here = and here = . I'm doing that work as an = individual, I'm not part of a WHATWG steering group. I mention that just = in case, to prevent confusion.=20 I believe that an addendum to RFC3986 (URI) and RFC3987 (IRI) that = specifies the WHATWG parsing and resolution behaviour, would be _very_ = valuable. Another, maybe preferable option would be to combine RFC3986 = (URI) and RFC3987 (IRI) into a new document that specifies elementary = operations that can be easily combined to accurately and exactly = reproduce the WHATWG behaviour.=20 Personally I think that the WHATWG standard would improve greatly if the = 'basic-url-parser' is refactored and split up into spearate parsing, = resolving, normalising and encoding operations. I am doubtful that this = will happen at all, though I do estimate that over time support for = relative URLs will have to be added.=20 I have thought a lot about how to resolve the, difficult situation and = I've come to the conclusion that the WHATWG and the IETF can actually (I = am serious) complement each other well here. The style of the IETF is = more suitable for specifying the elementary operations and the deeper = structure, whereas the WHATWG is limited in that area and can instead = focus on the step-by-step instructions in pseudocode and on the = specification of the web APIs. The most important thing will be, that: 1) Any new IETF effort at an updated RFC3986/ RFC3987 specifies = elementary operations that can be used by the WHATWG to implement the = WHATWG behaviour, accurately and exactly, and 2) That the WHATWG acknowledges the new IETF effort, and explicitly = points out that the behaviour is equivalent to theirs. This is similar = to what has been done in the WHATWG Encoding Standard = for UTF8. I will add that = personally I think that it is good for readers, but also as a gesture to = the IETF, to make such a statement a bit more prominent. All of this, is just an outline, of course, and it does require a lot of = effort, still.=20 But I believe that it can be done and that it is worthwhile.=20 Regards, Alwin Blok From nobody Tue Jun 8 06:03:02 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9136C3A302D for ; Tue, 8 Jun 2021 06:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 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, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 IGk_pALLX8ok for ; Tue, 8 Jun 2021 06:02:55 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 C9A953A302A for ; Tue, 8 Jun 2021 06:02:55 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RZZGWJBBV400ICAZ@mauve.mrochek.com> for dispatch@ietf.org; Tue, 8 Jun 2021 05:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1623157069; bh=9rh370Dy1sWuINBYw3eI02OdSslbrkGrg2GyUrqc6hg=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=jKhPiQ1flXMrYDUT3sXpZTlVHgKjny7cPDCty1N0LIvjmstJLpEQKRG+l/HQYpGmz BTEW8mHMgchPnugGEIJLdO04cJAZtMPuS3AllW64v4+2HOnetHa9Um9UFjcis6PW9L 2DeMHNjLXdNLAtfuei+UIVmuLxBSKsm7UjJJS+GQ= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RZSK5M2ZAO0085YQ@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dispatch@ietf.org; Tue, 8 Jun 2021 05:57:41 -0700 (PDT) From: ned+dispatch@mrochek.com Cc: ned+dispatch@mrochek.com, Bron Gondwana , dispatch@ietf.org Message-id: <01RZZGWED8R80085YQ@mauve.mrochek.com> Date: Tue, 08 Jun 2021 05:30:42 -0700 (PDT) In-reply-to: "Your message dated Mon, 07 Jun 2021 20:47:50 +0530" References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <01RZPZV5ELIY0085YQ@mauve.mrochek.com> <01RZY69GSAQA0085YQ@mauve.mrochek.com> To: Ujjwal Sharma Archived-At: Subject: Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 13:03:01 -0000 > On 07/06/2021 18.49, ned+dispatch@mrochek.com wrote: > > You then may want to get some preliminary review of these documents, to make > > sure they track with your intended goals. Or not - it may be that the people > > working on these specifications have a clear shared understanding of what's > > needed. > > > > Once this is done a new charter needs to be submitted that describes the work to > > be done, with these two new drafts as a starting point. Given the wide use of > > RFC 3339, it needs to be very specific about what is or isn't in scope for the > > revision of that specification. > Pardon my relative inexperience with IETF, but I suppose by RFC 3339bis > you mean "a document detailing the updates to RFC 3339 but not the > extension format". This document already exists at > https://github.com/ryzokuken/draft-ryzokuken-datetime-updated (source), > https://ryzokuken.dev/draft-ryzokuken-datetime-updated/documents/rfc-3339.html > (rendered) and > https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-updated/. The > (relatively) smaller diff can be found at > https://github.com/ryzokuken/draft-ryzokuken-datetime-updated/compare/original...main > (look in the sources folder). First, this document was cited nowhere in the proposed charter. If the intent is to use this as a basis for the 3339bis work, it should have been. Second, this document illustrates very nicely why the charter needs to nail down what is and isnt't allowed in a potential 3339bis: Despite its limited scope it retains the completely gratuitous changes to the 3339 ABNF the other document had. As I pointed out in my original review, it is essential that the ABNF remain as stable as possible, in order to prevent breakage in other documents that reference specific productions. If you want to see how this is done I suggest looking at how RFC 6532 did it for the productions in RFC 5322. Third, I'm intentionally ignoring the issue of what changes, if any, are actually needed. That's for the WG to decide, and I really don't want to derail getting the charter done in order to discuss the appropriateness of fractional seconds in time offsets. The charter should specify the scope of the allowed changes and leave it at that. > The draft that you reviewed is just a version of this RFC 3339bis that > also includes the extension format. As mentioned before, this was done > because there was not enough clarity around how we could best get > consensus around the format. If you prefer that the extension format > refer to (and not extend) the RFC 3339bis, then that would work just > fine and I suppose we could discuss that in great detail within the WG > (personally, I'd be happy either way). I'm afraid this comment only reinforces my point about getting your ducks in a row before proceeding: In his comments Bron was very clear that this was a settled issue. He said: I take a lot of responsibility for this - and it's this way *because* of the feedback in DISPATCH last time, which was "don't try messing with RFC3339". But I think maybe you also looked at the draft as it was proposed back then because - again - I didn't push hard enough to have an actual draft uploaded which specified basically that this would look something like: "RFC3339{bis}-point-in-time{extended context}" (exact encoding TBD) If you disagree that this is a setttled issue - and it appears from what you've said here that you do - then you need to confer with your colleagues in this endeavor and decide on an approach. I will also note that this is not now and never had been a question of what I "prefer". It's a question of using an approach that experience has shown to work versus one that experience has shown ... doesn't. > > That said, some of the subsequent comments about ECMA International TC39 and ISO > > TC154, as well as statements like "Temporal proposal having reached stage 3" and > > "delegates are already working on implementing it in various engines" seem to me > > to be even more of a cause for concern. If this work really is as advanced as > > these statements seem to imply, and is in any way constraining on what we're > > doing here, then the WG needs access to these specifications. > > In case it isn't clear, the situation I want to avoid is where someone in the WG > > comes up with some proposal, only to be told, "Sorry, that's not the TC39 way, > > and no, I don't have anything to show you what that way actually is." > You are already aware of the situation around ISO 8601, but all the ECMA > TC39 specs and proposals are published freely on the internet. > Everything relevant to this work is contained in the "Temporal" proposal > which is published at https://tc39.es/proposal-temporal/. A specification that attaches both metadata and other stuff to timestamps using a completely different approach really doesn't help in any obvious way that I can see. If the new charter opts to cite this as an input it needs to explain how it's suoposed to be used. > Hope this clarifies everything, feel free to ask for further clarification, > Ujjwal I'm afraid what it does is confirm most, if not all, of my objections were on point. Ned From nobody Tue Jun 8 12:04:34 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF623A3A27 for ; Tue, 8 Jun 2021 12:04:32 -0700 (PDT) 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, NICE_REPLY_A=-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 (2048-bit key) header.d=igalia.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 YK5GAgcIk8D5 for ; Tue, 8 Jun 2021 12:04:25 -0700 (PDT) Received: from fanzine.igalia.com (fanzine.igalia.com [178.60.130.6]) (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 AF06D3A3A26 for ; Tue, 8 Jun 2021 12:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=dilyrAe8Us7f2/3R3xxRxpYTG3D/TfJDd8qHegil7OY=; b=jXjGNBtUryidPwM9wK9nIuXP6EaXdTBM0qmWcs4T2DT11K1ZUEHx32xbkjnLCt3mUZPpPFUZYej0J8jtgOYomqN3lzVqdL0l91It5Vy1DjxiTGYEHb9gP48x64RPpEf3zRBl4iYUxau/VdBO/rqMop2G6KMn5x8DOJq9GNcYBmipae1kBkzwIFgzT62vCurlR4iyWxNW4fGl8Ou4nplxy+Pg1m0OdGK6czAKHN+AQkefK9sfoRRHjekZiigmUqVc3/qpg306cFuGBQuOHJct/sm4/J/vxdu9Typ6GB2OJvDPUJduw2juEEWKH33ONr0hzgisySvr6LMImrtwbKFlvw==; Received: from [183.83.213.107] (helo=[192.168.0.190]) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1lqh1O-000656-HO; Tue, 08 Jun 2021 21:04:18 +0200 To: Ned Freed Cc: ned+dispatch@mrochek.com, Bron Gondwana , dispatch@ietf.org References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <01RZPZV5ELIY0085YQ@mauve.mrochek.com> <01RZY69GSAQA0085YQ@mauve.mrochek.com> <01RZZGWED8R80085YQ@mauve.mrochek.com> From: Ujjwal Sharma Organization: Igalia S.L. Message-ID: Date: Wed, 9 Jun 2021 00:34:06 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <01RZZGWED8R80085YQ@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 19:04:33 -0000 Hey Ned! On 08/06/2021 18.00, Ned Freed wrote: > Second, this document illustrates very nicely why the charter needs to nail down > what is and isnt't allowed in a potential 3339bis: Despite its limited scope it > retains the completely gratuitous changes to the 3339 ABNF the other document > had. As I pointed out in my original review, it is essential that the ABNF > remain as stable as possible, in order to prevent breakage in other documents > that reference specific productions. If you want to see how this is done I > suggest looking at how RFC 6532 did it for the productions in RFC 5322. As I mentioned previously, your review was the first time it was raised to me and I understand the concern completely. As a matter of fact, I already submitted a new version of the draft to fix that: https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-updated/01/. That said, I was still under the impression that this change could be discussed at the WG level and wouldn't block the charter... > Third, I'm intentionally ignoring the issue of what changes, if > any, are actually needed. That's for the WG to decide, and I really don't want > to derail getting the charter done in order to discuss the appropriateness > of fractional seconds in time offsets. The charter should specify > the scope of the allowed changes and leave it at that. That's great! I agree. > I'm afraid this comment only reinforces my point about getting your > ducks in a row before proceeding: In his comments Bron was very clear > that this was a settled issue. He sai> ... > If you disagree that this is a setttled issue - and it appears from what you've > said here that you do - then you need to confer with your colleagues in this > endeavor and decide on an approach. I don't think I completely agree with this inference. What's "settled" is always a function of what input we've received. Until a while ago, the signals from DISPATCH were clear: they wanted us to have nothing to do with RFC 3339 (because what we're doing here interests only a subset of implementations) and the idea was that we would embed the entire instant format and publish a distinct RFC. Now you've pointed out that referencing RFC 3339 would be a better idea, and while I agree that this is an important discussion to be had, I disagree that we need to block chartering the WG on this single decision. > A specification that attaches both metadata and other stuff to timestamps using > a completely different approach really doesn't help in any obvious way that I > can see. If the new charter opts to cite this as an input it needs to explain > how it's suoposed to be used. You asked about the ECMA specifications and I pointed you to them. The Temporal spec is not relevant to the work of the WG in any way except for the fact that it utilizes the format that we're trying to standardize here. Best, Ujjwal -- Ujjwal "Ryzokuken" Sharma (he/him) Compilers Hacker, Node.js Core Collaborator and Speaker From nobody Wed Jun 9 08:21:44 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514213A1BAA for ; Wed, 9 Jun 2021 08:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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=mrochek.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 xqrhycPIhK9C for ; Wed, 9 Jun 2021 08:21:38 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 17B5A3A1BA8 for ; Wed, 9 Jun 2021 08:21:37 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S0101VLVI800FNZV@mauve.mrochek.com> for dispatch@ietf.org; Wed, 9 Jun 2021 08:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1623251791; bh=2WgvFekpONUyY2ZVPP61xyBVLqZsTBPHTi3FiBIuveo=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=nOismesZIwZLZLDGB80bgSKk5q/0nNZKGX13rxrtB7clt0XHati1KlR/dJOMUionC 1RPq69FOcBeMPHdZpzIFUSDAByvRZGcE5QA6A92ivtNCH1a8eZ4+3zgPY26WimcBgL Up3tWiW780fTa9K3CPkaA+FTiiDA6cbLSdh0J3ps= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RZSK5M2ZAO0085YQ@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dispatch@ietf.org; Wed, 9 Jun 2021 08:16:24 -0700 (PDT) From: ned+dispatch@mrochek.com Cc: Ned Freed , ned+dispatch@mrochek.com, Bron Gondwana , dispatch@ietf.org Message-id: <01S0101Q8IDO0085YQ@mauve.mrochek.com> Date: Wed, 09 Jun 2021 07:25:50 -0700 (PDT) In-reply-to: "Your message dated Wed, 09 Jun 2021 00:34:06 +0530" References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <01RZPZV5ELIY0085YQ@mauve.mrochek.com> <01RZY69GSAQA0085YQ@mauve.mrochek.com> <01RZZGWED8R80085YQ@mauve.mrochek.com> To: Ujjwal Sharma Archived-At: Subject: Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 15:21:42 -0000 > On 08/06/2021 18.00, Ned Freed wrote: > > Second, this document illustrates very nicely why the charter needs to nail down > > what is and isnt't allowed in a potential 3339bis: Despite its limited scope it > > retains the completely gratuitous changes to the 3339 ABNF the other document > > had. As I pointed out in my original review, it is essential that the ABNF > > remain as stable as possible, in order to prevent breakage in other documents > > that reference specific productions. If you want to see how this is done I > > suggest looking at how RFC 6532 did it for the productions in RFC 5322. > As I mentioned previously, your review was the first time it was raised > to me and I understand the concern completely. As a matter of fact, I > already submitted a new version of the draft to fix that: > https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-updated/01/. > That said, I was still under the impression that this change could be > discussed at the WG level and wouldn't block the charter... Charters exist to define the scope of work and work products for the group. And should the scope change or work products change, the charter is supposed to be updated accordingly. If something as significant as a 3339bis update is being considered by the WG, it has to be in the charter. It cannot be done informally. To say otherwise is in effect to say that charters are nonbinding and essentially meaningless. > > I'm afraid this comment only reinforces my point about getting your > > ducks in a row before proceeding: In his comments Bron was very clear > > that this was a settled issue. > > ... > > If you disagree that this is a setttled issue - and it appears from what you've > > said here that you do - then you need to confer with your colleagues in this > > endeavor and decide on an approach. > I don't think I completely agree with this inference. What's "settled" > is always a function of what input we've received. Until a while ago, > the signals from DISPATCH were clear: they wanted us to have nothing to > do with RFC 3339 (because what we're doing here interests only a subset > of implementations) This sounds like possible mission creep to me. > and the idea was that we would embed the entire > instant format and publish a distinct RFC. I once again refer you to what Bron has said about this. Your ducks are not in a row. > Now you've pointed out that > referencing RFC 3339 would be a better idea, and while I agree that this > is an important discussion to be had, I disagree that we need to block > chartering the WG on this single decision. This substantially mischaracterizes the situation. > > A specification that attaches both metadata and other stuff to timestamps using > > a completely different approach really doesn't help in any obvious way that I > > can see. If the new charter opts to cite this as an input it needs to explain > > how it's suoposed to be used. > You asked about the ECMA specifications and I pointed you to them. The > Temporal spec is not relevant to the work of the WG in any way except > for the fact that it utilizes the format that we're trying to > standardize here. Again, other people seem to disagree. I think this has reached, if not passed, the point of diminishing returns, so I'm unlikely to respond further until new draft(s) are out along with a new charter. Ned From nobody Wed Jun 9 10:14:07 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2D33A1F09 for ; Wed, 9 Jun 2021 10:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 JAjPecr1xIKf for ; Wed, 9 Jun 2021 10:14:03 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B253A1F07 for ; Wed, 9 Jun 2021 10:14:02 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lr1m5-000NVa-Iq; Wed, 09 Jun 2021 13:13:53 -0400 Date: Wed, 09 Jun 2021 13:13:47 -0400 From: John C Klensin To: Ujjwal Sharma cc: Ned Freed , dispatch@ietf.org Message-ID: <4BDEC6628D413BDAC6A67524@PSB> In-Reply-To: References: <162255609215.5567.6852158423318065168@ietfa.amsl.com> <01RZPZV5ELIY0085YQ@mauve.mrochek.com> <01RZY69GSAQA0085YQ@mauve.mrochek.com> <01RZZGWED8R80085YQ@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 17:14:06 -0000 --On Wednesday, June 9, 2021 00:34 +0530 Ujjwal Sharma wrote: > Hey Ned! > > On 08/06/2021 18.00, Ned Freed wrote: >> Second, this document illustrates very nicely why the charter >> needs to nail down what is and isnt't allowed in a potential >> 3339bis: Despite its limited scope it retains the completely >> gratuitous changes to the 3339 ABNF the other document had. >> As I pointed out in my original review, it is essential that >> the ABNF remain as stable as possible, in order to prevent >> breakage in other documents that reference specific >> productions. If you want to see how this is done I suggest >> looking at how RFC 6532 did it for the productions in RFC >> 5322. > > As I mentioned previously, your review was the first time it > was raised to me and I understand the concern completely. As a > matter of fact, I already submitted a new version of the draft > to fix that: > https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-upda > ted/01/. > > That said, I was still under the impression that this change > could be discussed at the WG level and wouldn't block the > charter... >... Ujjwal, Drawing inspiration from Ned's remarks, some off-list discussions, and a sense that the people you probably see as resisting and you and your colleagues are not communicating very well, let me see if I can explain the situation in a different way and make a suggestion. (1) The timestamp format specified in RFC 3339 is very widely deployed and used, both in support of IETF standards and outside them. Changing it would be a big deal, very disruptive, and should be undertaken only with clear explanation and strong justification as to why that is necessary and worth the risks. We have had a few experiences in the IETF in which documents that were supposedly just intended to update and replace others, making no or tightly focused substantive changes, inadvertently introduced errors and more substantive changes. We've caught more, but not all, of those before or during IETF Last Call, but considerable energy had been spent by then. If those risks are necessary, an explanation and justification for taking them has not, as far as I can tell, appeared. And "don't touch 3339" does not mean "copy a good deal of text out of 3339, with or without slight modifications" either. (2) RFC 3339 is a profile of ISO 8601:1998. Other than the references being out of date because 8601 has been updated now consists of two parts, no information has been presented so far that 3339 has become inconsistent with ISO 8601-1:2019. If it is, we have another problem, but there is no indication in either your draft or the draft charter as to what it is and what you propose doing about it. In any event, it is probably a different task from the extension. (3) I may still be confused about this but if what you are proposing is a pure extension that does not conflict with or alter any of RFC 3339, ISO 8601-1:2019, ISO 8601-2:2019, or ongoing work in ECMA or ISO/ TC 154, then the charter should say that explicitly and the I-D should make that clear, explain why it is needed, and concentrate on the extension. Ideally, if this proposal reflects new (since 3339 was written) work in the ECMA and ISO groups, it should make that clear and should be written much the way 3339 was written: as a profile of that work with sufficient discussion and examples to be usable without the reader needing to read and understand the ISO standards. If it is actually a clean extension to the current ISO standards and RFC 3339, the document should not need to repeat or paraphrase RFC 3339 in any way. It is likely to need to reference it but the only necessary update to RFC 3339 should be to note that readers of 3339 might want to look at the new spec and under what circumstances plus _maybe_ supplying updated references it is is possible to assert that the updates don't change anything because there have been no substantive changes since 1988 in the ISO documents on which 3339 depends that would affect 3339's validity as a profile. I may have been confused and probably was but I came away from the DISPATCH discussion believing that the plan was to do (3) above and only that, and that everything else was about the details. No charter provisions that would allow the WG to decide it was appropriate to alter 3339 (especially the timestamp format) without coming back to the community and getting consensus about that plan. And, if the extension is going to be inconsistent with either 3339 or ISO 8601-*:2019 in any way (i.e., not a fully compatible add-on to either one), then I think (and would have said during DISPATCH had it seemed necessary) that needs to be spelled out and the charter and get rough community consensus. With the understanding that the above is nothing but an attempt to summarize recent discussions rather than saying anything new, I hope it helps. best, john From nobody Wed Jun 9 17:40:09 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC55E3A2CCD for ; Wed, 9 Jun 2021 17:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLSesjzy4pK1 for ; Wed, 9 Jun 2021 17:40:02 -0700 (PDT) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 4A4473A2CC9 for ; Wed, 9 Jun 2021 17:40:02 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id x21-20020a17090aa395b029016e25313bfcso2733542pjp.2 for ; Wed, 09 Jun 2021 17:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=Z34s5nAjW0c1GjvBU8vSjPM2+oKX5KH8f0eM4DxUhzo=; b=IUQWQaYTZsexKOpoQGeYFrIU8tT2u7cDkyeP9vcEMEXanGNfRCZ/Y6wloK42OLsYun J/+bPTfvPSnrQtR2TLGZM88b4QAZSxFBg8HoGxam89qLFZvF14PdltDvSfW7VsqOfG0j 2olcFnViTXc5It6/N37gOaRwq0ibf8QOGm++2E+JgpTMXAVDCkENM45xYYVWFI6Wx7i5 xFOj551OXSDUrmIz1ATmxgp2KHv963uGn5imQtHbV1K2NGaCogn9qRqtRl5Uk0ZFllBJ vBOVlfsLTh1vtCVEy6re2cuyr4A1XiBRZWUFdhhDVa7p14DBuJK/sG9WThf0cU3o8fYI 5VcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=Z34s5nAjW0c1GjvBU8vSjPM2+oKX5KH8f0eM4DxUhzo=; b=eu72VRf7Cv26tW6Bupkgw4huzFE+r6jhve0/5sTkhsHFuX6bHJUeLLb5zIgT2qJnWJ l29NnKcfPlxXtBk4cx04VP1Z5zJv6qDwsyuIU03bmBQp8xG2MxsEdHK1V7X09gbYos8p WG0C2+oDYfiofbpw+NQOvyX+eHSMzExYlM59ORUVJ3fJ/gQ16Pc826pphtP7rZpiUeuy qParLO3diE4p/9SVZEImtw9zOaFQURaEiGo/yUb8xi1ceMfXJnI4gDyebZEe4qnXr6R4 L5JP2+5JBCzZ3/8en1LK7wmGXW++Z1xd/CHl9BsaEvK5C7JOLviSEkY/8xaMLdtSIA2P EIqQ== X-Gm-Message-State: AOAM5335VdyEuE3X052ALpi9K2M+yfxWrVb2tn6Ne2lFX7ink2Hp6Wmh gucw/1kkyrIT4kZTNkAXmUEnGTj78wo= X-Google-Smtp-Source: ABdhPJyojwnibTmxV8bPSFOaL1S8NnQ17dTfq7V1Re2bi4mrhHO8rQh73Dc2M4WnIBBS1458Jra9VA== X-Received: by 2002:a17:903:2c2:b029:101:9c88:d928 with SMTP id s2-20020a17090302c2b02901019c88d928mr2453766plk.62.1623285599020; Wed, 09 Jun 2021 17:39:59 -0700 (PDT) Received: from TVPC (c-73-158-116-21.hsd1.ca.comcast.net. [73.158.116.21]) by smtp.gmail.com with ESMTPSA id l70sm806134pgd.20.2021.06.09.17.39.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Jun 2021 17:39:58 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Mark Nottingham'" , "'John C Klensin'" Cc: References: <002501d75a5b$08694740$193bd5c0$@acm.org> In-Reply-To: Date: Wed, 9 Jun 2021 17:39:58 -0700 Message-ID: <019301d75d91$24878020$6d968060$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQKaLvE30C8z31T9z7KHncQ61MqIvwLMsk1rAahR+EmpYw+K0A== Archived-At: Subject: Re: [dispatch] RFC 3896 and 3987 vs WHATWG URL Living Standard X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 00:40:07 -0000 The question is: is there enough interest to have a BOF at IETF 111 to discuss a plan for moving forward? I don't imagine starting out with a presentation of a solution. I'd probably want to focus on "minimum viable product": What things could we do first with minimum effort that would improve the current state? A replacement for RFCs 3986 and 3987 wouldn't be my first step. Maybe a short standards-track "UPDATES" that points to/contains deltas or a new grammar that is more consistent with (tested) implementations. And a pointer to WHATWG-URL, whether normative or not I'm not sure. That's a little more than Mark's "Section 1.1.3" because it makes normative changes but (apparently) minimal ones. I was encouraged to see WHATWG paying attention to feedback from curl and node.js as implementations of URLs, not just browsers. Larry -- https://LarryMasinter.net https://interlisp.org > -----Original Message----- > From: Mark Nottingham > Sent: Monday, June 7, 2021 11:37 PM > To: John C Klensin > Cc: Larry Masinter ; dispatch@ietf.org > Subject: Re: [dispatch] RFC 3896 and 3987 vs WHATWG URL Living Standard > > My sense right now is that it's not (yet) appropriate to deprecate 3986/7. > > Even if we could ignore the non-Web folks using URIs and IRIs (and there are > perhaps good arguments for considering that, IMO, although I know that > others have strong feelings, and there's a lot of history here), the current > WHATWG specification doesn't specify them -- it specifies how to get from > an arbitrary string to what a browser considers a URL to be. It doesn't specify > grammar, and it doesn't cover many of the things that 3986 in particular does. > > The issue that Larry links to seems to be taking tentative steps towards > aligning the grammar in 3986/7 with what WHATWG does, which is great. If > that's incorporated, I think there's still a significant gap that would need to be > filled before we can deprecate. Even if that gap were to be filled, I question > whether the WHATWG is an appropriate home for the specification -- > although obviously the W3C has come to peace with HTML living there. > > Looking at this from a different angle, we could also ask ourselves whether > 3986/7 should be updated to align with WHATWG URL. I think the answer to > that is likely to be no -- not only is the delta apparently very small (according > to the comments on the linked issue), alignment would mean doing things > like considering <> to be valid content in URIs. Again, what they're specifying > is how to get from an arbitrary string to a URI, not the syntax itself. > > Actually, one useful thing we *could* do would be to replace section 1.1.3 of > RFC3986 with something that actually helps people understand the > differences between all of these things. If we ceded 'URL' to the WHATWG, > leaving 3986 to define URI, it might help. > > Cheers, > > > > On 6 Jun 2021, at 12:21 pm, John C Klensin wrote: > > > > > > > > --On Saturday, June 5, 2021 15:35 -0700 Larry Masinter > > wrote: > > > >> Recent progress on WHATWG's URL spec led me to suggest a BOF on the > >> topic for IETF 111 > >> > >> Provide a succinct grammar for valid URL strings > >> . Issue #479 . > >> whatwg/url (github.com) > >> > >> But I didn't get an ack, and perhaps this belongs in DISPATCH/ART > >> etc. > > > > Larry, > > > > This is a question rather than a statement of preference because I > > have not thought about it in some time, but are you thinking it may be > > time to either revise or deprecate 3896 and 3897? I may not have > > enough information but it seems clear to me that, in terms of the > > specs to which implementers are paying attention, the action has > > shifted toward WHATWG (and, to a lesser extent, W3C) and away from the > > IETF documents. > > > > If deprecating the IETF URI and IRI specs is really the question (or > > part of it), I'd think either a BOF or a well-prepared presentation > > and a rather large block of time in DISPATCH would be appropriate. > > > > best, > > john > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > -- > Mark Nottingham https://www.mnot.net/ From nobody Wed Jun 9 21:34:01 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0053A3368 for ; Wed, 9 Jun 2021 21:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 Gx8Df8Cga1Iy for ; Wed, 9 Jun 2021 21:33:56 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11EE3A336B for ; Wed, 9 Jun 2021 21:33:55 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lrCO7-000P7S-6J; Thu, 10 Jun 2021 00:33:51 -0400 Date: Thu, 10 Jun 2021 00:33:46 -0400 From: John C Klensin To: Larry Masinter , 'Mark Nottingham' cc: dispatch@ietf.org Message-ID: In-Reply-To: <019301d75d91$24878020$6d968060$@acm.org> References: <002501d75a5b$08694740$193bd5c0$@acm.org> <019301d75d91$24878020$6d968060$@acm.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] RFC 3896 and 3987 vs WHATWG URL Living Standard X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 04:34:01 -0000 Larry, Without trying to answer your question, two small cautions. While WHATWG has chosen, probably for good reason, to concentrate on URLs, as you know 3986 is about URIs more generally. It includes some sweeping requirements that are arguably unreasonable or over-constraining for non-URL URIs generally and URNs in particular. One of the reasons the URNbis WG got RFCs 8241 and 8254 out and then essentially gave up was connected to those constraints and I gather that there has been some development and deployment outside IETF that made progress by ignoring restrictive interpretations of 3986. If it is worth the sort of work you suggest to recognize changes consistent with WHATWG work, is it not equally worth considering updates that would create better alignment with URN practice and demands on URN extensions? Not directly related, but my understanding is that work elsewhere has moved considerably beyond RFC 3987 (fwiw, a Proposed Standard while 3986 is an Internet Standard). It seems to me likely that we would want to treat 3986 and 3987 quite differently, maybe even retiring the latter in favor of a pointer to work done elsewhere. I don't know how to peek into a can of worms without opening it. john --On Wednesday, June 9, 2021 17:39 -0700 Larry Masinter wrote: > The question is: is there enough interest to have a BOF at > IETF 111 to discuss > a plan for moving forward? I don't imagine starting out with a > presentation of > a solution. > > I'd probably want to focus on "minimum viable product": > What things could we do first with minimum effort that would > improve the current state? A replacement for RFCs 3986 and > 3987 wouldn't be my first step. Maybe a short standards-track > "UPDATES" that points to/contains deltas or a new grammar that > is more consistent with (tested) implementations. > And a pointer to WHATWG-URL, whether normative or not I'm not > sure. > > That's a little more than Mark's "Section 1.1.3" because it > makes normative changes but (apparently) minimal ones. > > I was encouraged to see WHATWG paying attention to feedback > from curl and node.js as implementations of URLs, not just > browsers. From nobody Sun Jun 13 05:01:41 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0389A3A1809 for ; Sun, 13 Jun 2021 05:01:40 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 PtKa_j4UfkZ3 for ; Sun, 13 Jun 2021 05:01:35 -0700 (PDT) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 513103A1808 for ; Sun, 13 Jun 2021 05:01:35 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id ci15so11733225ejc.10 for ; Sun, 13 Jun 2021 05:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SWiN7c5s3tG0pVKpJof99V1fAVB7gNrvouRITGhLEHQ=; b=WY01ACHECfbC0mNohGA43z8OF5KjzIqhJH+OWjLFovBpQUSJ/UkZgpSQYH5icZeFpp 0BURaYBmbpITR7U/QjmzYYuZQS1fSonZp8ek1AbVJ6gmZXP6RtoykJ46VAogrhZM859X vRXJFsr7xoaOeMcbj1ATJvktiz6fWTUlUlMcSBDHTzCJEiKudBTvsPWxIkN7EtfjZMjO scrjNZ/XmFUXp1/4on08M6wkOkE7GDzk2LhmV/fLOieIxWQqziqPqI/RDhMYhDr5hfYU Rx2op7szkIk/Bv3metyBY6Wd54+Gv0a5MJE7bTSs1LdsslHe3Ol6hAPXlbPj6VMwPvS2 wZxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SWiN7c5s3tG0pVKpJof99V1fAVB7gNrvouRITGhLEHQ=; b=Qm/BGDj4KckQDcLMcS7JNXM+YybMlauB9HVmNnh45BfkgIbrs8WEqV/ZqlbbPU55vE wrZHUaE/Eih0C3cbv98KhDYt0gIGz9eelJlXHjr2LDabtSC9E5sVdmlgNrizTLBi0Bsr MXQzgapA4x0EoLYnu+5/MgSh4R/2Z3WvamNse9RINeGWKgmWkgOLSZPW0tACFQsKqaRp MhTLOhhr9/uDOGkEh6/2jfH3VfjBfdd+i6U5HbOB+AfMVirao83D2anw6sWQW2AGXSbe cx8VcczSPCd6exZmo820fciZ2FX8ZWN+AB2V2kYypRDdxhHDy3xM5JJwumSvhLRTIW6h FRuA== X-Gm-Message-State: AOAM5335oilRr/ttX71vUwe1A9oq8KKdAgMPdV4aAPZ2A9wat8N82bi0 lLO6DRz97zAAJ3PQRvv4B48= X-Google-Smtp-Source: ABdhPJw0FDhwIjmvaWAxhtjFs5P3OplAOmue3ZRlCL8d6yW6BKirpmdRI2zs/Lu36TAdlR6ri3nY8A== X-Received: by 2002:a17:906:d791:: with SMTP id pj17mr11402477ejb.442.1623585692973; Sun, 13 Jun 2021 05:01:32 -0700 (PDT) Received: from [192.168.1.166] ([87.214.169.250]) by smtp.gmail.com with ESMTPSA id e25sm4635511eja.15.2021.06.13.05.01.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Jun 2021 05:01:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Alwin Blok In-Reply-To: Date: Sun, 13 Jun 2021 14:01:31 +0200 Cc: John C Klensin , dispatch@ietf.org, Larry Masinter Content-Transfer-Encoding: quoted-printable Message-Id: References: <002501d75a5b$08694740$193bd5c0$@acm.org> To: Mark Nottingham X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [dispatch] RFC 3896 and 3987 vs WHATWG URL Living Standard X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 12:01:40 -0000 > On 10 Jun 2021, at 02:39, Larry Masinter wrote: >=20 > A replacement for RFCs 3986 and 3987 wouldn't be my > first step. Maybe a short standards-track "UPDATES" that points = to/contains > deltas or a new grammar that is more consistent with (tested) > implementations. Since I am new to the IETF process, is there a link that I can follow = with more information about this? Specifically, a description of what is an UPDATES, in this case.=20 > On 8 Jun 2021, at 08:37, Mark Nottingham wrote: >=20 > The issue that Larry links to seems to be taking tentative steps = towards aligning the grammar in 3986/7 with what WHATWG does, which is = great. If that's incorporated, I think there's still a significant gap = that would need to be filled before we can deprecate.=20 I don=E2=80=99t know if it will be incorporated. I feel quite a lot of = resistance to it. My impression may be wrong though and maybe it will = work out just fine.=20 > although obviously the W3C has come to peace with HTML living there Oh=E2=80=A6. They should up their game and publish a much simpler but = behaviourally equivalent specification of the html parsing chapter only.=20= > Looking at this from a different angle, we could also ask ourselves = whether 3986/7 should be updated to align with WHATWG URL. I think the = answer to that is likely to be no -- not only is the delta apparently = very small (according to the comments on the linked issue) It can maybe just be descriptive, as in: this is the grammar and the = behaviour that the WHATWG implicitly specifies.=20 The delta between RFC3987 and WHATWG URL is not small. You cannot = directly compare the documents, the style of the WHATWG prevents that. = But the standard can be (after so much effort=E2=80=A6) characterised. = That characterisation could be published as an IETF document. That would = be great! The diff between that, and RFC3987 should be relatively small.=20= > alignment would mean doing things like considering <> to be valid = content in URIs. Again, what they're specifying is how to get from an = arbitrary string to a URI, not the syntax itself. The WHATWG explicitly defines valid URLs to always have a scheme. But = then it implicitly defines =E2=80=98loose URL=E2=80=99s and =E2=80=98loose= relative URL=E2=80=99s via their =E2=80=98basic-url-parser=E2=80=99 = function.=20 That function specifies, how to get from an arbitrary input string and = optionally an =E2=80=98URL record=E2=80=99 to a = resolved-normalised-URL-record, or failure.=20 If you break down that function, you see that it implicitly specifies: - A grammar for valid URLs and one for loose URLs (incorporating valid = and invalid) - Grammars for relative references - An encoding normal form for loose URLs - Several slightly different resolution operations They don=E2=80=99t seem to be attentively aware of that themselves.=20 The solution was pointed out lucidly by David Sheets in 2012: = Kind regards, -Alwin Blok From nobody Sun Jun 13 23:47:37 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9EB3A160B for ; Sun, 13 Jun 2021 23:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_BLOCKED=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 (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 D8rOpnScdoSa for ; Sun, 13 Jun 2021 23:47:31 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 721483A160A for ; Sun, 13 Jun 2021 23:47:30 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id 68so7266779vsu.6 for ; Sun, 13 Jun 2021 23:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G05Hx+C7e0y2xxCzSWglD1gTIzHM5Wlbm6G8d1nvt0M=; b=UAxjH2oY7RCG0jJJomqqPkbB7shLjSC9TYK7DwDwG/uyb9+XFQG80JwoNLSiInJgLt I+VZ8shFExy1CaojygqDI5S6RoPzxGgA0dMRzRPDgrzeF5ucxK2j3wZFwQvX8+T7Okkc ptetd3IFc8jjx+4bkfLtgOkpcnws7U9fgf5qatdXwJWkmCd2oS91CrS1UUT8gKiEk9xb PV6ETVTTWgYd+P1WQbcskJHtXJXS21hvZM6T9nYxUaBaI/9zt5Ny6CTFPrz9FTDRoW7t D7L4ChDhzQD/XP0TX34R+McW49t6H4/x8WW4XbjeZ3mdZKQ3MDa/3G72B9ea265W+/Rw wGdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G05Hx+C7e0y2xxCzSWglD1gTIzHM5Wlbm6G8d1nvt0M=; b=AO2EU9NYOiW4FwNSMws8+TeycnX61hj+LhyUPUPJexxCKnThaz0epPWbg1CAu+HkxI JgplIdWDrV08kUvaZRwPszzbmkzDDUCF6ZoDwlFpwfvqn+qipGShAVgFnyD5P2ZAsZ/L I2NZWfZQxhGzmaSltNumFbFk3tvNG5P6q8lO804j/Ui2/yJ6y7goDnsj2lEMd64/4Mkp LtlXiVDOeXEXLR3hwl6mV1F3xfbT9NakVN07oOx1Y5oVorvzmin9tAcM1fqITG2zmJ/M pEx3QOC5jV68fnwt42+Ji/V2PIQVdmxEwbY0Ik72nrLOf3LWGsoypwx90MVTfm8tjVEk pw6A== X-Gm-Message-State: AOAM533yaIgqI/C4UVs5txCVsf/uSyu8cJ5gD43EvCcuQRlom1ZBWM3A EPQuraRLLb5W42XUuPt6rioyEVzKr0EmIrybir6cOat004IQhQ== X-Google-Smtp-Source: ABdhPJzAo0oUJz/HWB1XsHt69vNvw6AjztCmniUKX+Y3/2a/p6mhpmVqmo5AiHlmbO7WzeCQfYSae4oy04I4xDbY6Ak= X-Received: by 2002:a67:edcd:: with SMTP id e13mr17239477vsp.40.1623653248780; Sun, 13 Jun 2021 23:47:28 -0700 (PDT) MIME-Version: 1.0 References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> <01RZSLCQGG9Y00IM2V@mauve.mrochek.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Sun, 13 Jun 2021 23:47:17 -0700 Message-ID: To: DISPATCH list Cc: Ned Freed , John C Klensin , Mark Nottingham Content-Type: multipart/alternative; boundary="00000000000021cd7205c4b43b5d" Archived-At: Subject: Re: [dispatch] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 06:47:36 -0000 --00000000000021cd7205c4b43b5d Content-Type: text/plain; charset="UTF-8" On Mon, Jun 7, 2021 at 9:31 PM Mark Nottingham wrote: > If the community comes to an understanding that the barriers to > registration are appropriate, the current procedures are likely adequate > (although it'd be good to get feedback from other standards bodies). > However, if they're to be changed, the registration procedure would need > consideration too. > > With that in mind, I suggest replacing the bullet about GitHub with: > > * Evaluate the registry policies and procedures in the context of how > media types are currently used, and modify them if necessary. > I've folded this suggestion and John's into the draft charter, which I've now added to the datatracker so that people can see changes over time as we iterate: https://datatracker.ietf.org/doc/charter-ietf-mediaman/ Please have a look and let me know if this is good enough to proceed to the formal part of chartering. Note that the process still requires two review passes through the IESG and one formal round of public commentary, so I'm wondering if people feel like it might be close enough to start those processes, or if we should iterate here again first. I've also, per John's suggestion, inquired about whether ISO generally, or a TC specific to haptics, is already listed as an approved SDO for media type registrations. Even if they are, though, BCP 13 still requires a standards track RFC for a top-level registration, though the path he proposes would be fine for all the sub-registrations they might want to make. -MSK --00000000000021cd7205c4b43b5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 7, 2021 at 9:31 PM Mark Notti= ngham <mnot@mnot.net> wrote:
=
If the community comes to an understanding that the barriers to reg= istration are appropriate, the current procedures are likely adequate (alth= ough it'd be good to get feedback from other standards bodies). However= , if they're to be changed, the registration procedure would need consi= deration too.

With that in mind, I suggest replacing the bullet about GitHub with:

* Evaluate the registry policies and procedures in the context of how media= types are currently used, and modify them if necessary.

I've folded this suggestion and John's into the d= raft charter, which I've now added to the datatracker so that people ca= n see changes over time as we iterate:

https://datatracker.ietf.org/doc/cha= rter-ietf-mediaman/

Please have a look and let me kno= w if this is good enough to proceed to the formal part of chartering.=C2=A0= Note that the process still requires two review passes through the IESG an= d one formal round of public commentary, so I'm wondering if people fee= l like it might be close enough to start those processes, or if we should i= terate here again first.

I've also, per Jo= hn's suggestion, inquired about whether ISO generally, or a TC specific= to haptics, is already listed as an approved SDO for media type registrati= ons.=C2=A0=C2=A0 Even if they are, though, BCP 13 still requires a standard= s track RFC for a top-level registration, though the path he proposes would= be fine for all the sub-registrations they might want to make.
<= br>
-MSK
--00000000000021cd7205c4b43b5d-- From nobody Wed Jun 16 12:49:36 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3FF3A248C; Wed, 16 Jun 2021 12:49:24 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 (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 EJdFIbRXco7p; Wed, 16 Jun 2021 12:49:20 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 1ED083A248B; Wed, 16 Jun 2021 12:49:19 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id z15so1678333vsn.13; Wed, 16 Jun 2021 12:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S6whBP6jh+K/mqZstUk5t4LdPP4gUuzRYRzoXISHlh0=; b=pYCQF2XXNljhHnwDjP7JqVG6zhLdQXRBieWxiKkZxnv474H4pcqJxpfMY9hZmf5cqX QRMreyOpUp3srmtlmEErbNOb5dPg8ewG8tA40Q4pm83+j4zpsSA/s31hU7k87hVFdKWm pvKnVbE5YeUk0Vm01pZM5faw5TqPQ/RgKLcX+DIAZ7usS67YovS7HuI+RdIW47Q7ASS+ M5b/dKbW3E1aCCaP+5IBFyv8SioHYsmDD/PgLDG/ZrfAJfEEDRO76v7LOgDtoUNbcoZ8 BkLVfRx/OQe2bHTgeC8XT5Ym3unbWORWI4K18Osv5LT2LCVdJcNh/WBwPenOtN0qzJgf 5MTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S6whBP6jh+K/mqZstUk5t4LdPP4gUuzRYRzoXISHlh0=; b=HgIdkX3qctDdWuP6VtzxPFarHS1KcjDMW+DapzFD6DnLCKr5TbkHfXkwJIrFuByB7J 38x934elfvZWEqxnAjD3c2sq8jZ+Mf82NdGE6CjXdJ8hSVQID8nKkijr9e6JWIBHMcx6 mCb7doRYsStPc7sx7SWBMOMebBIG/rHf6TiqxtT2LcUhBSu3YWXsivbTFQjarysLPCz5 siTXxw3C6WMhyAxl1fF98P5IxyywmCF2ygXqKm+x3JemOKcdSM51uXDRl94wlLcZbEUF FEgqOMspO7tlBoz63Eh+76XvSbt2GjGPfdk6xCuIntb/3lcSPbkk2LYVKuCMXisyIrwH 405g== X-Gm-Message-State: AOAM530mvtqWTTkQS8229Oaf7w06FA8nokmUqC4/rEEqfG0ANrsyNAuH 6RGXwY6+s6WWqKsDi3W/Vy4Ij4+DmFeNfX7dwyqa+jo6N9g= X-Google-Smtp-Source: ABdhPJxe2jJWV+x07EYraZGqyWSPZhSEvPYfGX1q6i1Xo2qw3mb25aay/vOjI5IP9+qtksCKD1MOuW4/BHTp3wyHI2M= X-Received: by 2002:a67:1a45:: with SMTP id a66mr932278vsa.15.1623872957709; Wed, 16 Jun 2021 12:49:17 -0700 (PDT) MIME-Version: 1.0 References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> <01RZSLCQGG9Y00IM2V@mauve.mrochek.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 16 Jun 2021 12:49:06 -0700 Message-ID: To: DISPATCH list , media-types@ietf.org Cc: Ned Freed , John C Klensin , Mark Nottingham Content-Type: multipart/alternative; boundary="000000000000ce03c005c4e7624c" Archived-At: Subject: Re: [dispatch] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 19:49:25 -0000 --000000000000ce03c005c4e7624c Content-Type: text/plain; charset="UTF-8" On Sun, Jun 13, 2021 at 11:47 PM Murray S. Kucherawy wrote: > I've folded this suggestion and John's into the draft charter, which I've > now added to the datatracker so that people can see changes over time as we > iterate: > > https://datatracker.ietf.org/doc/charter-ietf-mediaman/ > > Please have a look and let me know if this is good enough to proceed to > the formal part of chartering. Note that the process still requires two > review passes through the IESG and one formal round of public commentary, > so I'm wondering if people feel like it might be close enough to start > those processes, or if we should iterate here again first. > > I've also, per John's suggestion, inquired about whether ISO generally, or > a TC specific to haptics, is already listed as an approved SDO for media > type registrations. Even if they are, though, BCP 13 still requires a > standards track RFC for a top-level registration, though the path he > proposes would be fine for all the sub-registrations they might want to > make. > (Adding the "media-types@ietf.org" list, so people there can comment if needed before I start the process) An additional question: Would it be better to use the existing media types IETF list for this work, or should it get a separate mailing list? -MSK --000000000000ce03c005c4e7624c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 13, 2021 at 11:47 PM Murray S= . Kucherawy <superuser@gmail.com<= /a>> wrote:
I've folded this suggestion = and John's into the draft charter, which I've now added to the data= tracker so that people can see changes over time as we iterate:
Please have a look and let me kno= w if this is good enough to proceed to the formal part of chartering.=C2=A0= Note that the process still requires two review passes through the IESG an= d one formal round of public commentary, so I'm wondering if people fee= l like it might be close enough to start those processes, or if we should i= terate here again first.

I've also, per Jo= hn's suggestion, inquired about whether ISO generally, or a TC specific= to haptics, is already listed as an approved SDO for media type registrati= ons.=C2=A0=C2=A0 Even if they are, though, BCP 13 still requires a standard= s track RFC for a top-level registration, though the path he proposes would= be fine for all the sub-registrations they might want to make.
=

(Adding the "media-types@ietf.org" list, so people there = can comment if needed before I start the process)

An addi= tional question: Would it be better to use the existing media types IETF li= st for this work, or should it get a separate mailing list?

<= /div>
-MSK
--000000000000ce03c005c4e7624c-- From nobody Wed Jun 16 17:29:53 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668563A0EE9; Wed, 16 Jun 2021 17:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67fbnfHxbRqR; Wed, 16 Jun 2021 17:29:42 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-eopbgr1320104.outbound.protection.outlook.com [40.107.132.104]) (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 D2B803A0ED9; Wed, 16 Jun 2021 17:29:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OpTBYYX/ZulVYK5VPSxXZG+KS+dsuTLNpiqwnJ77J3Mo1LLaZ8b4pD500B3VfPsNxXiklDZwRTUun3jvgFtXQEgYHFXopqgEinn8YfVXRslANexDDbODyDPnHduPWXbwvDiTy9JfpZ6p0R/zc1766+XW1Z40HS0/cUg3hoXsobn84mUgTs9d96bVqcuVVKfzPWohMkcGiGKAJUjucVB81KOTfCOE38BIeBRB+/KiZaXEJHO80+abR6YVUvOneTXrnZoNpws9bTQY8uAebiQIqDNq7BB9t/QrLc7SNK4hXwF3sxb3VM5nZ6zW7OCuR0TKTnQAxw6KYREfzdWcJ5vrxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zaU1fmk4qMVnylPKbbZk8D//J+il6TowsAT6XzpU+mY=; b=CNClNIq+qq7rd0Xa39LvZnpqQFpzIyfFodJjYVOMh3AvWReYnYq+iRV3BHBFYnDPfgXGdU3i7C9n5/Kg+RsDhYMDWERAe9IpJbt0fA3ngmBwY1Eawg1UiDnlJBkzyqcFPHA2a2zanfG5Hspu63C/BfzU0HM1wsqHANbQET5D1YLXzP4EV6ekyaZZ9pCOuwPuD6fe2msUpGA+r0JB4U7bIq+WFbyjD5appGZcV9OU6PM6KpJf7RILVpyFiQdDcTotQXGcfw9HJ9XqExeSq8ETaurZZ3SKA/7BekTDtVfDVAahxnkaxlgy6IApFsdakIvp6Tpe0Jb21OqPO9yL0F8ylg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zaU1fmk4qMVnylPKbbZk8D//J+il6TowsAT6XzpU+mY=; b=kt4pGdLGntvuiWl0LzUnLcafrcj6Vb7uzc940+Mu6z7DP02bvsVLNvxqT9xxU1I5bJwWe383FBqn0xOqbKFIx1qssZUincB9kkuzX90Cz7gG+u/jOFC5wTfpYZN7piKARMYeH1sLDSYwGaKLcWtPT+Nwe0yMB+/0qvDyBr0GZGU= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TY2PR01MB4828.jpnprd01.prod.outlook.com (2603:1096:404:114::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.23; Thu, 17 Jun 2021 00:29:38 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::a103:800c:b1ed:48ba]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::a103:800c:b1ed:48ba%8]) with mapi id 15.20.4242.019; Thu, 17 Jun 2021 00:29:38 +0000 To: "Murray S. Kucherawy" , DISPATCH list , media-types@ietf.org References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> <01RZSLCQGG9Y00IM2V@mauve.mrochek.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Thu, 17 Jun 2021 09:29:36 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [114.185.21.49] X-ClientProxiedBy: TYAPR01CA0102.jpnprd01.prod.outlook.com (2603:1096:404:2a::18) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.5] (114.185.21.49) by TYAPR01CA0102.jpnprd01.prod.outlook.com (2603:1096:404:2a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19 via Frontend Transport; Thu, 17 Jun 2021 00:29:37 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 45a7395a-38bb-44bc-dbaa-08d93126fd5a X-MS-TrafficTypeDiagnostic: TY2PR01MB4828: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: VRU9vSvRY7NgmVSiJhEq2xJgPNafBhW7MWzZySeI7Ecj0XMUkaPo/jf5qTs4BQI5TohG4Potme4ojgMClYSbKs4Nqr+KzjPYj5uqS0N/S3i4xDKenjRx7Jb5TNS1CQb5PutIqy3+Ytz0m942JysjMVfATOVxDRnav3hPpeVWTU860ac+ahX4s6SlF2GnmaQGXZuKsBK/nUcrTAcv0uMtL88ul5VpjUEB8+Oa9wYQDl30hz0cft4daXuNKpJCzHYbra5uirMzgP6Ci1AZVUTdQiU7LemkQt/j7V5DQZpdSbsZYKeh5p/5A2AsLsuZnCbt8wfLX8ZoS+erTMGmPrTgVcItnN7FHxBxyG92427gRuIqSrWDUZGPdEnG7FaR2VgTD5nD1lQPvpYsa5hwrkTogh47BdziqqZ9EO7niFmVwkStkPX9VAkHkyKSgg09mPHrmlIJ5Usf8GLz0uCLKWUgfZ2bvX1vDKGhmLIYrKXyt4I2oybHV0WXfkW7x46wlXCJGZw4x4xnJyaOou8z6TTVSIKYgSoiSKDsWQGjlwWabnHCZnJXXtTsylDSzrU3ATdAPETV+n2vRPsc7PYrOX2uB4TuZHggTqBtqQAZQqZu1oNZVFoV2OPtQDm2N4fWb5JlPFDcuIJPKHUMxwCgLlQiFsjgy4u1xloAsYfy0PLip5s1pTqDaV/QuhwCV/Nk3JC/lqW0OSibBVVY+KiwN7Qf5TmfIm15sVwVO79Qx+zL9uk= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(346002)(39830400003)(136003)(376002)(396003)(2906002)(186003)(26005)(16526019)(36916002)(53546011)(52116002)(38350700002)(956004)(8676002)(6486002)(66476007)(478600001)(316002)(786003)(86362001)(38100700002)(66556008)(4744005)(31696002)(16576012)(8936002)(110136005)(31686004)(2616005)(66946007)(5660300002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?T29BeUJIVUd6RXRZMEVUbnBkZ0FKVE4zWC9CRllreloxVmtDSlBhZ1o2empV?= =?utf-8?B?VzhvNnlaKy91aVFTSGNSVUNKTHAwUi8wK1JMUkh5ODJ0d0hZcW1Lb1I0ajFU?= =?utf-8?B?ejh3dW1tQTFLaFA4ZW9RbWJyL2JmN0ZVd0VWOUxrL3RlTE50clhkcnNIdllX?= =?utf-8?B?N0tnQTVOdlhLNlVWcXY4QVFibGZLZCtyeXo4cUQ5aThRRGpDWHo2RldqNElR?= =?utf-8?B?Q3k3RTVmMDAyRjU5TmpXVlRrSjVCME5qQnNpUDg5YkdscTNZVWw2RkpmZVUr?= =?utf-8?B?MUVYak1ja0huREdBdkMzN0NyL251QXBaa2FvcFhYVWxFUmEwdi9nQXFFRWV3?= =?utf-8?B?WFhaK0Z4bzhoZm1wTVJGR3dXbCtrUlFQZ3FOR2VEbHZKaUxKamhGcTNCeE05?= =?utf-8?B?MEVUWTVhNWN1SFRvS2tTYnFBdWhBSmt0YWx5UzRTMVRzNVM1WlR6eUs4NThU?= =?utf-8?B?RjlZOUg1TE5yUFp0MHVhbzYzUjRsS01DbmNrZ2tvbWNmODRuemlHaDFHbWlM?= =?utf-8?B?akNBdjczaENVWTc5eXNxMVYvc3lSdTE5MFdSWUhjVWFERTZ4NEV1RHB0eEtz?= =?utf-8?B?OWJNc3hDN1BwQWUrSkVGSDloeWR2UUV4NVpYZkZwNERaVzRxSTA2SnRUWGto?= =?utf-8?B?Y21LNjNkZWRFOVpDLzNNVytZeVdhQlRIZWpEaHdUdlprSHdFc3MzUmtZb0xk?= =?utf-8?B?S0xFbGtvdkJLdk4zU2tsMEZZV3VlV3k0WVJzWkRBem5uVDJIVndLSWxPVlZW?= =?utf-8?B?U0FHZm1haklWb21ScGg4TkF5QldJeEJSd1hXOHFwekNqckpYN1JPZXR1dkhk?= =?utf-8?B?UkxFczE1ZG9jbzAvUTMrTWlhWXluai9sbXJ3NUNpUzJzeGNWRHNxM3hDVS9I?= =?utf-8?B?dlgzOGYwRFNxdktsWlgxWHlaeTJ6SlQ4dlRXYzR3cWZiYTY0Mk5tREI4TFJm?= =?utf-8?B?cDRJYjZBSDgvajd4R2VrbGcrendzWnphTVE5dnUzK1k5SW40ZU5nV1dBS3d1?= =?utf-8?B?bFhjS2gxNTMrZVZVQUVRdWk0VEFVZ1NNMnN0ZEtpUFJMNmJnNG1DYmVydG1o?= =?utf-8?B?eWdJaWF5cm1RanVvaklZdHI5T1dneEIvNFA3aW5hOXg4RnB5WmdTSEJSUWIv?= =?utf-8?B?bUNIV3ZoRzVpL2ovQ0lkTjNJQkdTUWxtQis1Z0M5ODJxZWtWQ1VFVFVXNkZ4?= =?utf-8?B?RHBKY3FwRnNiaEprTmNaNUU0OGpWelBwVzBSSGVMTFV5VWNLL1lKTzQ1MzJ2?= =?utf-8?B?bWdIMVk4WWgyRDNtUWxXTHExU1JkOGVBcHdqZkNqSjYzNVIxb0luRnFyeFZR?= =?utf-8?B?NmF5dzF1czVITVdQcGNQaEpIQnJsUnU4a3RwTnJzNVAySVdMbWJqek5wamFn?= =?utf-8?B?N1owck5RNzM5YVJxbFpnZEJES2tJV3owSHA4YVAyYlMyOWVONEM3YlRTekxp?= =?utf-8?B?N243YS9ucDFnVHkxaXZQTVhHaGZua3dJdlVVYzRoVDRSR1RMSTdPZjRrdVRv?= =?utf-8?B?WFJ0OUswenZnMTdvR1RVMHJxanoyZHdqdWFmNDhFWGYxYUtjMHYwNUZqQkdD?= =?utf-8?B?YWxGSzEzdW1HRTFacUtqb3BtcXVTOWlUbXM1Rk92SUQvcEZ4ZW5iQkFoWDNF?= =?utf-8?B?aGQ3SjVsWm45anoxZG12V0NxUkVjYnFDMitqM0lZa2RhaDlST2hrRFoxREpu?= =?utf-8?B?bDZvTTZBK3dYaFVpUWpOdDF2N2VXSHp2S3FBcncxWkZDWVpUUXJrZ1U3TUJT?= =?utf-8?Q?KdI214zapopQOY4yEQc2nhMxVJFMG3G1CMf5FxS?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 45a7395a-38bb-44bc-dbaa-08d93126fd5a X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2021 00:29:38.2955 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: DUuGcl4ImlNuX+gjhXDA5Yegh3l/ehfBxlpfs7YjzAFfYG020+TC7pYAw5LUTl1rSBESER2Br1BoM7phYVlsRA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB4828 Archived-At: Subject: Re: [dispatch] [media-types] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 00:29:47 -0000 On 2021-06-17 04:49, Murray S. Kucherawy wrote: > (Adding the "media-types@ietf.org" list, so people there can comment if > needed before I start the process) > > An additional question: Would it be better to use the existing media types > IETF list for this work, or should it get a separate mailing list? I think using the existing list would be preferable. It's currently very low traffic, but should have a number of people on it that can contribute, even if just by checking that they are fine with where things are going and therefore not raising any comments. Regards,   Martin. From nobody Wed Jun 16 23:01:28 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A43B3A0BF1 for ; Wed, 16 Jun 2021 23:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlIRtKbaUWI9 for ; Wed, 16 Jun 2021 23:00:45 -0700 (PDT) Received: from 8.mo6.mail-out.ovh.net (8.mo6.mail-out.ovh.net [178.33.42.204]) (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 3CB7C3A0BF5 for ; Wed, 16 Jun 2021 23:00:45 -0700 (PDT) Received: from player756.ha.ovh.net (unknown [10.108.4.127]) by mo6.mail-out.ovh.net (Postfix) with ESMTP id 9DA54252FE5 for ; Thu, 17 Jun 2021 08:00:39 +0200 (CEST) Received: from hoplahup.net (pd9526c86.dip0.t-ipconnect.de [217.82.108.134]) (Authenticated sender: paul@hoplahup.net) by player756.ha.ovh.net (Postfix) with ESMTPSA id 5DE6F1E6B4519; Thu, 17 Jun 2021 06:00:31 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-103G0051e9e8aaa-9f3f-44bf-8dd6-867e44977416, F6872317591DAD382EA4BBECE7B115767A5CA861) smtp.auth=paul@hoplahup.net X-OVh-ClientIp: 217.82.108.134 From: "Paul Libbrecht" To: "Murray S. Kucherawy" Cc: "DISPATCH list" , media-types@ietf.org, "John C Klensin" , "Mark Nottingham" , "Ned Freed" Date: Thu, 17 Jun 2021 08:00:29 +0200 X-Mailer: MailMate (1.14r5757) Message-ID: In-Reply-To: References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> <01RZSLCQGG9Y00IM2V@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_6E092FDA-B3FC-4C71-A732-4B91B137EC81_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"plain":[690, 1346], "uuid":"D8F3582F-A199-4D36-B27D-C23814523BBC"}] X-Ovh-Tracer-Id: 16503159360533825669 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrfeeftddgleekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffoffkjghfgggtgfesrgekmherredtjeenucfhrhhomhepfdfrrghulhcunfhisggsrhgvtghhthdfuceophgruhhlsehhohhplhgrhhhuphdrnhgvtheqnecuggftrfgrthhtvghrnhepudeggeetudeujeefuefgteeikefhheeufffftdehvdelgedtleegffdthfdvtefhnecuffhomhgrihhnpehivghtfhdrohhrghenucfkpheptddrtddrtddrtddpvddujedrkedvrddutdekrddufeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrjeehiedrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehprghulheshhhophhlrghhuhhprdhnvghtpdhrtghpthhtohepughishhprghttghhsehivghtfhdrohhrgh Archived-At: Subject: Re: [dispatch] [media-types] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 06:00:50 -0000 --=_MailMate_6E092FDA-B3FC-4C71-A732-4B91B137EC81_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Hello list, It’s interesting to see a renovation wind about the registration process and details. I am wondering if the group is the right place to prepare an update of the registration template so as remove the Macintosh 4-letter-codes and insert clipboard flavours for windows and universal type identifiers for macOS. This was discussed a few times on this mailing list. I have been in contact with a few media-type proposers, some of which have accepted a change of their declaration in this direction. I have been in contact with one IETF-aware person to update RFC6838 but that has not progressed. Thanks in advance. Paul On 16 Jun 2021, at 21:49, Murray S. Kucherawy wrote: > On Sun, Jun 13, 2021 at 11:47 PM Murray S. Kucherawy > > wrote: > >> I've folded this suggestion and John's into the draft charter, which >> I've >> now added to the datatracker so that people can see changes over time >> as we >> iterate: >> >> https://datatracker.ietf.org/doc/charter-ietf-mediaman/ >> >> Please have a look and let me know if this is good enough to proceed >> to >> the formal part of chartering. Note that the process still requires >> two >> review passes through the IESG and one formal round of public >> commentary, >> so I'm wondering if people feel like it might be close enough to >> start >> those processes, or if we should iterate here again first. >> >> I've also, per John's suggestion, inquired about whether ISO >> generally, or >> a TC specific to haptics, is already listed as an approved SDO for >> media >> type registrations. Even if they are, though, BCP 13 still requires >> a >> standards track RFC for a top-level registration, though the path he >> proposes would be fine for all the sub-registrations they might want >> to >> make. >> > > (Adding the "media-types@ietf.org" list, so people there can comment > if > needed before I start the process) > > An additional question: Would it be better to use the existing media > types > IETF list for this work, or should it get a separate mailing list? > > -MSK > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types --=_MailMate_6E092FDA-B3FC-4C71-A732-4B91B137EC81_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Hello list,

It=E2=80=99s interesting to see a renovation wind about t= he registration process and details.

I am wondering if the group is the right place to prepare= an update of the registration template so as remove the Macintosh 4-lett= er-codes and insert clipboard flavours for windows and universal type ide= ntifiers for macOS.

This was discussed a few times on this mailing list.
I have been in contact with a few media-type proposers, some of which hav= e accepted a change of their declaration in this direction.
I have been in contact with one IETF-aware person to update RFC6838 but t= hat has not progressed.

Thanks in advance.

Paul

On 16 Jun 2021, at 21:49, Murray S. Kucherawy wrote:

On Sun, Jun 13,= 2021 at 11:47 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
I've folded this suggestion and John's into the draft charter, = which I've now added to the datatracker so that people can see change= s over time as we iterate:
Please have a look and let me know if this is good enough to p= roceed to the formal part of chartering.=C2=A0 Note that the process stil= l requires two review passes through the IESG and one formal round of pub= lic commentary, so I'm wondering if people feel like it might be clos= e enough to start those processes, or if we should iterate here again fir= st.

I've also, per John's suggestion= , inquired about whether ISO generally, or a TC specific to haptics, is a= lready listed as an approved SDO for media type registrations.=C2=A0=C2=A0= Even if they are, though, BCP 13 still requires a standards track RFC fo= r a top-level registration, though the path he proposes would be fine for= all the sub-registrations they might want to make.

(Adding the "media-types@ietf.org" list, so people there can co= mment if needed before I start the process)

An addition= al question: Would it be better to use the existing media types IETF list= for this work, or should it get a separate mailing list?

<= /div>
-MSK

___________________________________= ____________
media-types mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-types

--=_MailMate_6E092FDA-B3FC-4C71-A732-4B91B137EC81_=-- From nobody Fri Jun 18 04:07:02 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1C33A104E for ; Fri, 18 Jun 2021 04:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, SPF_HELO_NONE=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 7hfTo0U4gUPU for ; Fri, 18 Jun 2021 04:06:57 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::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 6D7F63A104D for ; Fri, 18 Jun 2021 04:06:57 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4G5x2Q26Vwz2xHS; Fri, 18 Jun 2021 13:06:54 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 645707213.838184-a8448b895aab58245978c7a744ec84bd Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Fri, 18 Jun 2021 13:06:54 +0200 Message-Id: <46C20458-2EFE-4A85-ADDD-A22AFE77FB1E@tzi.org> To: dispatch@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [dispatch] Format underlying security.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 11:07:00 -0000 https://datatracker.ietf.org/doc/draft-foudil-securitytxt defines a format and semantics for /security.txt on web servers (I know, = I=E2=80=99m simplifying here). There are now knockoffs like draft-ring-analyticstxt that seem to define = a format that is almost, but not entirely, unlike security.txt. Do we need a spec that defines an RFC822-like text format for key-value = pairs like this (because, clearly, we don=E2=80=99t have enough text = formats to choose from)? =20 I would consider this preferable to setting up a maze of little = knock-off formats all different. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 22 15:37:06 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097EC3A1D08; Tue, 22 Jun 2021 15:37:00 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 (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 IOl0Ubeit9yo; Tue, 22 Jun 2021 15:36:55 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 43F493A1D0B; Tue, 22 Jun 2021 15:36:55 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id x22so121101uap.0; Tue, 22 Jun 2021 15:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=566kA3ADVLoC0RbVGDjSRiEaD6xyBYKAyDyircyU0+Y=; b=Hza7flPdQPG7NszOq6TglVeJUjrr8YVrfCIXZHPpCUoakYAJd4Sr6AzpBfLm3zKqq0 +kYWzvcJ9//mn2Xi7IrOHkdrYr2FX3U8aT7F5TYr34hQVFV/fKNZhTMcpYXbrA7w/MjE 5MPwiW3UbXo3sbH2IVTRoe7GK8JeiIG/VNz+vr8HRUIZl4Gk58/+Neeqg1FtSSSlalbT je/YVtP+sOigEsrcCAGtWxCcdy0/eexqm4KrW3P0eb0pQ2uk3TM8tytFMECGKUGs5j+q 5gkBph1SgeZ2tB/ohgRL9lJ9ejkN/qRmX//vZ2VsxZ26X4b694qCKU9MxffKWg8iOiHB Smeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=566kA3ADVLoC0RbVGDjSRiEaD6xyBYKAyDyircyU0+Y=; b=etBPj37viJ1AHTlwV/lBTntiPn05fhWalPt0J7won6/3Nm2J5gJwDOP/xn7SuiWNWv EA3538gxJ42NQZdgVZeJCJxBqHROEjwQ50L17ipWdBC/zBWZ/3biZ83i693hrKTQstl8 s9dS9hXp7YUSyhhDPl/I1H7JF3lpZJhH3KpoAWzmvwnDq1yIE5DahGxc3BA/ZAK5A2Z9 B/CGs/9GymWCIhFqJPZEDs6Ikg2xuW8jyDrxKBicMPffh1u0HjVAZeSq9BVrhLiXM5kT Jcm0M/DAW2oWsaF19JNaAMW6hgEwPCI553TFduQywjqmkH3dvBno5t10il9qQ/OEVuou 5ZGA== X-Gm-Message-State: AOAM531o5H2fTMgJdj8Xn/6g+9Pnvf3shwNs6D8SslrIvow8SHyc1sVg iPl3LSHCJjYQBmYoqaoV/lbb7Y/dIzaT8WA7ayA= X-Google-Smtp-Source: ABdhPJzZp3y2w9uJrDb1iHiSYFDHQO7iHwdMOm1k0JTCmgzZFZcQfrD7KN7GFwrkCMGt7JmJplUIlKoPRIuRUKn/agA= X-Received: by 2002:ab0:6009:: with SMTP id j9mr1584358ual.87.1624401413424; Tue, 22 Jun 2021 15:36:53 -0700 (PDT) MIME-Version: 1.0 References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> <01RZSLCQGG9Y00IM2V@mauve.mrochek.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 22 Jun 2021 15:36:41 -0700 Message-ID: To: Paul Libbrecht Cc: DISPATCH list , media-types@ietf.org, John C Klensin , Mark Nottingham , Ned Freed Content-Type: multipart/alternative; boundary="000000000000384a4d05c5626d32" Archived-At: Subject: Re: [dispatch] [media-types] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 22:37:00 -0000 --000000000000384a4d05c5626d32 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 16, 2021 at 11:00 PM Paul Libbrecht wrote: > I am wondering if the group is the right place to prepare an update of the > registration template so as remove the Macintosh 4-letter-codes and insert > clipboard flavours for windows and universal type identifiers for macOS. > > This was discussed a few times on this mailing list. > I have been in contact with a few media-type proposers, some of which have > accepted a change of their declaration in this direction. > I have been in contact with one IETF-aware person to update RFC6838 but > that has not progressed. > There's been no feedback from anyone else, up or down, about this idea. My own impression is that this isn't quite within scope of what we're talking about for this effort, but then again it makes sense to include this now rather than spin up a subsequent effort or wait for the next train. Naturally I'm happy to include this in the proposed charter if there's consensus to include it. I'm just about to enqueue the charter we have in hand for its first IESG review pass before it goes out for general review. If this or any other change should be included in that submission, please (everyone, anyone) say something sooner rather than later. -MSK --000000000000384a4d05c5626d32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 16, 2021 at 11:00 PM Paul Libbrecht <paul@hoplahup.net> wrote:
I a= m wondering if the group is the right place to prepare an update of the reg= istration template so as remove the Macintosh 4-letter-codes and insert cli= pboard flavours for windows and universal type identifiers for macOS.

This was discussed a few times on this mailing list.
I have been in contact with a few media-type proposers, some of which have = accepted a change of their declaration in this direction.
I have been in contact with one IETF-aware person to update RFC6838 but tha= t has not progressed.


There's been no = feedback from anyone else, up or down, about this idea.=C2=A0 My own impres= sion is that this isn't quite within scope of what we're talking ab= out for this effort, but then again it makes sense to include this now rath= er than spin up a subsequent effort or wait for the next train.=C2=A0 Natur= ally I'm happy to include this in the proposed charter if there's c= onsensus to include it.

I'm just about to = enqueue the charter we have in hand for its first IESG review pass before i= t goes out for general review.=C2=A0 If this or any other change should be = included in that submission, please (everyone, anyone) say something sooner= rather than later.

-MSK
--000000000000384a4d05c5626d32-- From nobody Wed Jun 23 00:00:48 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49E83A09DB for ; Wed, 23 Jun 2021 00:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5v5lh-d9ZYMI for ; Wed, 23 Jun 2021 00:00:38 -0700 (PDT) Received: from 6.mo1.mail-out.ovh.net (6.mo1.mail-out.ovh.net [46.105.43.205]) (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 A78B73A1151 for ; Wed, 23 Jun 2021 00:00:38 -0700 (PDT) Received: from player699.ha.ovh.net (unknown [10.110.171.50]) by mo1.mail-out.ovh.net (Postfix) with ESMTP id 0F3CF20B6AC for ; Wed, 23 Jun 2021 09:00:34 +0200 (CEST) Received: from hoplahup.net (p5dc6fdae.dip0.t-ipconnect.de [93.198.253.174]) (Authenticated sender: paul@hoplahup.net) by player699.ha.ovh.net (Postfix) with ESMTPSA id 703CB1F7524A1; Wed, 23 Jun 2021 07:00:27 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-102R00477a654e3-c2e8-49c9-87fc-06433261e639, 62D18D71EE23157A8A05E6810D9E71CD751EDB68) smtp.auth=paul@hoplahup.net X-OVh-ClientIp: 93.198.253.174 From: "Paul Libbrecht" To: "Murray S. Kucherawy" Cc: media-types@ietf.org, "John C Klensin" , "Mark Nottingham" , "DISPATCH list" , "Ned Freed" Date: Wed, 23 Jun 2021 09:00:26 +0200 X-Mailer: MailMate (1.14r5757) Message-ID: In-Reply-To: References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> <01RZSLCQGG9Y00IM2V@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_199EF85E-A611-4A17-B1AB-67CB2EA3C675_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"plain":[1031, 1294], "uuid":"6D088197-3379-4C68-93EC-AB212EA02B30"}] X-Ovh-Tracer-Id: 15857737241212684421 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrfeegvddguddtiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufffokfgjfhggtgfgsegrkehmreertdejnecuhfhrohhmpedfrfgruhhlucfnihgssghrvggthhhtfdcuoehprghulheshhhophhlrghhuhhprdhnvghtqeenucggtffrrghtthgvrhhnpedugeegteduueejfeeugfetieekhfehueffffdthedvleegtdelgefftdfhvdethfenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedtrddtrddtrddtpdelfedrudelkedrvdehfedrudejgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrheileelrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepphgruhhlsehhohhplhgrhhhuphdrnhgvthdprhgtphhtthhopeguihhsphgrthgthhesihgvthhfrdhorhhg Archived-At: Subject: Re: [dispatch] [media-types] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 07:00:43 -0000 --=_MailMate_199EF85E-A611-4A17-B1AB-67CB2EA3C675_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Hello Murray, Here are two reasons that I think may be convincing to change the template: - the old Macintosh 4-letter code is long dead - macOS UTIs are and have always been specified by Apple. Finding documentation on them is often a sport. As far one could see until 2010: no more registration, applications are free to register UTIs. As a side effect of the proprietary nature, it appears that around 2010 Apple started to indicate that the `public` subtree of the UTIs is reserved to types declared by Apple. Other documentation pages still do not mention this. As a result… Some UTI declarations (e.g. in use in widespread desktop apps) thus have become invalid. The media-type inclusion of UTIs can help against this unpredictability. You are right that clipboard types tend not to be a super-fashionable topic and I find it rather good that this does not trigger a flood of mails such as the discussion on the necessity of a new prefix. Thanks in advance. Paul On 23 Jun 2021, at 0:36, Murray S. Kucherawy wrote: > On Wed, Jun 16, 2021 at 11:00 PM Paul Libbrecht > wrote: > >> I am wondering if the group is the right place to prepare an update >> of the >> registration template so as remove the Macintosh 4-letter-codes and >> insert >> clipboard flavours for windows and universal type identifiers for >> macOS. >> >> This was discussed a few times on this mailing list. >> I have been in contact with a few media-type proposers, some of which >> have >> accepted a change of their declaration in this direction. >> I have been in contact with one IETF-aware person to update RFC6838 >> but >> that has not progressed. >> > > There's been no feedback from anyone else, up or down, about this > idea. My > own impression is that this isn't quite within scope of what we're > talking > about for this effort, but then again it makes sense to include this > now > rather than spin up a subsequent effort or wait for the next train. > Naturally I'm happy to include this in the proposed charter if there's > consensus to include it. > > I'm just about to enqueue the charter we have in hand for its first > IESG > review pass before it goes out for general review. If this or any > other > change should be included in that submission, please (everyone, > anyone) say > something sooner rather than later. > > -MSK > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types --=_MailMate_199EF85E-A611-4A17-B1AB-67CB2EA3C675_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello Murray,

Here are two reasons that I think may be convincing to ch= ange the template:

  • the old Macintosh 4-letter code is long dead
  • macOS UTIs are and have always been specified by Apple. Finding docum= entation on them is often a sport. As far one could see until 2010: no mo= re registration, applications are free to register UTIs. As a side effect= of the proprietary nature, it appears that around 2010 Apple started to = indicate that the public subtree= of the UTIs is reserved to types declared by Apple. Other documentation = pages still do not mention this. As a result=E2=80=A6 Some UTI declaratio= ns (e.g. in use in widespread desktop apps) thus have become invalid. The= media-type inclusion of UTIs can help against this unpredictability.

You are right that clipboard types tend not to be a super= -fashionable topic and I find it rather good that this does not trigger a= flood of mails such as the discussion on the necessity of a new prefix.<= /p>

Thanks in advance.

Paul

On 23 Jun 2021, at 0:36, Murray S. Kucherawy wrote:

On Wed, Jun 16, 2021 at 11:00 PM= Paul Libbrecht <paul@hoplahup.ne= t> wrote:
I= am wondering if the group is the right place to prepare an update of the= registration template so as remove the Macintosh 4-letter-codes and inse= rt clipboard flavours for windows and universal type identifiers for macO= S.

This was discussed a few times on this mailing list.
I have been in contact with a few media-type proposers, some of which hav= e accepted a change of their declaration in this direction.
I have been in contact with one IETF-aware person to update RFC6838 but t= hat has not progressed.


There's been n= o feedback from anyone else, up or down, about this idea.=C2=A0 My own im= pression is that this isn't quite within scope of what we're talk= ing about for this effort, but then again it makes sense to include this = now rather than spin up a subsequent effort or wait for the next train.=C2= =A0 Naturally I'm happy to include this in the proposed charter if th= ere's consensus to include it.

I'm j= ust about to enqueue the charter we have in hand for its first IESG revie= w pass before it goes out for general review.=C2=A0 If this or any other = change should be included in that submission, please (everyone, anyone) s= ay something sooner rather than later.

-MSK
<= /div>

_______________________________________________
media-types mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-types

--=_MailMate_199EF85E-A611-4A17-B1AB-67CB2EA3C675_=-- From nobody Thu Jun 24 02:14:26 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE1A3A12BD; Thu, 24 Jun 2021 02:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.865, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRkxJGanBtPB; Thu, 24 Jun 2021 02:14:20 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100128.outbound.protection.outlook.com [40.107.10.128]) (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 D7D143A12BA; Thu, 24 Jun 2021 02:14:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OIUC9I/4FSmi1XjV3xUGhEvrYyY5N5o1+U3O33cnjug603jPy/h27oQjpEjNb/M00pHQvOtCxSUGJzTMbD4Wqi/cx1qI9axl5XO1DEnPHuUWqm2JcWj7g/Ly92TnqykD7NBt5naUFVQ+1GFHrwlO3MWKHO059tsPPzVFED+Qz5J5TOymepf48IN7Sdrz1pHD9JF29Qc6uRKfugVAZ2ZKxkKVt+/2iztGVIMcR/tLPzgfEoBe4jFsnyloMn3D9CIDCB/KDXjyJaxOZS7v1rTN9PEwcdoXTXpMB1PsZeI1FUzTh2hIyVLsjehbYotI5o/V76Cx6OdbZgiS8v8l2NQq4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qdtvDNBFcorqWVRyjGuuQHKoxHcYf77d8w18/2CLf2k=; b=GWLi6aHsAAQus5mYOS+eippy9WXyPAzxJBKNgViQTZ72fvI4xZtoSuBj83dJ6JMlIwFLdwNd5mbjYEXF6U470cnevTnkZkA1tR+zlXJDN0vxuXSsFonyqKuvPADS8ymzHFyube56K7Y0DRdNQWmYtMap4YrmenzwQSDtTBUPMDABjyxKvORzHVKz3qkIOdHfI9f5o1n6uNkbL1Gyv1AgNSZzAu5erCN64fCNH/nkD85hklfBfAXz0rzkQUh91Q3JswyBh0xYX7hWG1GpVSua1xNinALwIczlOO4QgZhfiGqHL9+VJMTmNq0J/hGnd8T/0MU5ar4LS15Mjr3q7jaEbw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qdtvDNBFcorqWVRyjGuuQHKoxHcYf77d8w18/2CLf2k=; b=kr1ZP7lORRIWR6BAIvWjG/BytcIXm1r/iHprFW4w97NXAEE7H6dKVI3qwVFEee9cMEOLzFOaHpsUnz2DerVDgLTtPcT99t7P2E6ElyiRKEacopd8jjeTG7wOkhe5F1iFNjaqQf5jOoaElAMsAp9wz/hWntFN/VguCbHdAE9ejmdGZpg0RGJAyZTZ7CxGtlAAd+CuHQw+NmbvWjht+cs18PHCI8Hq4tdlC5e4zwNB8x5NB+oxyfq5mz0MX6aMSUyRnMuBp+BAa85sj7Ms/ECMBP9mjpfk4CB9z8AM6bKMtBNx+AqtKT06e/D4Q8kybNalDwhCxBPiJZsVDqsbKrQ7rQ== Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:12c::10) by LO2P123MB4942.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1e6::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18; Thu, 24 Jun 2021 09:14:14 +0000 Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::3c36:33ea:ca34:ef01]) by LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::3c36:33ea:ca34:ef01%5]) with mapi id 15.20.4264.020; Thu, 24 Jun 2021 09:14:13 +0000 From: Kirsty P To: "dispatch@ietf.org" CC: dispatch chairs Thread-Topic: IETF 111 meeting - call for topics Thread-Index: AQHXaNhU0zhaLyNwzka1HvKfrn0EkA== Date: Thu, 24 Jun 2021 09:14:13 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ncsc.gov.uk; x-originating-ip: [20.49.216.120] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ef24729d-1af9-468b-d104-08d936f06f6b x-ms-traffictypediagnostic: LO2P123MB4942: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CyVDNi/mH7Cc8ryj5KtNVRWf+RHpYDBD/mRicA2+021lqigiF9yWxfGUvCitQB3UTAauqheK7ddd/+8NivQ2TNlQAAd3G7NPTcGQ8JLbwQj7SAr6eqGo8eDPiSz+wao9YmtVFbuYNNote/iPNFx/6pmsd7O4ONBB7AM7GGhI093wGKttlTIaoxGl4VUIJ6iBYF6Wi0PXlpSBu9CDkrFiUuYXlEoWPwn4FgAGVKNvKquXk20kS1D/XCXzoPWLC6uR8fnx+Ifw+UnGGJ9XEUAT4KD+6ercqdx6O0AhQ5ETkRh9VcGQXGS6RsidUriNRgV1SmgVJqPg0P/o68hSqKDsDszfgquL1hLVMzZR7MgzVlh2ba0h0PqsQkiSXCcr+K19rpkIdsIQWMhWuGRUNdqkKYiQbjjKY5SzHv+/MG18aBmS22hEj1oA4hqotfhXUac0MGdboi4uDCA0H+Pu6IXq90hZZSXCXJ/uoLcUf6+hbz1IbtAPqwI/lan5cu93JmbWR6ySh7ojVxh/PxdmytQbddSJBRCnWrk6wh9R4YNi8db5/DldUFLx/YH1wEZKpcszGLeVHIvHGdIkTLET7A9yy/D5eNIYAViW7q8y71+Yh7Y= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(366004)(39850400004)(396003)(136003)(9686003)(122000001)(2906002)(4326008)(71200400001)(6506007)(478600001)(38100700002)(7696005)(450100002)(33656002)(19627405001)(6916009)(83380400001)(8676002)(26005)(186003)(8936002)(76116006)(86362001)(66946007)(66446008)(66556008)(66476007)(64756008)(5660300002)(55016002)(316002)(4744005)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?fkvERupP3Vv45lxWTf0UU1t394CyJs5G60zRz8cLA5xwl9hsU+8rFdBEoH?= =?iso-8859-1?Q?2t4IjoNg6zvJNNrRubTuboqq2nGJ9gonlL25aQPs0ndn2wO5B1lNgzgGZ4?= =?iso-8859-1?Q?oyeAmmzakDgKHSVY6mJTKUkXgmrQBe+trB/rolJRwurHV5tUtD42sSzSF0?= =?iso-8859-1?Q?36ZpKHn3UN4Fo3IZm6ko32Dxlvh1vAmuITJs/P0oWf8J6HE6HNbIz9vnCb?= =?iso-8859-1?Q?hXOhQm0WYRaJZNoOZMs63If/3wM2t3752jKXbW/R8+O/YV/qJMoogCNBWs?= =?iso-8859-1?Q?8oWkYjI6RpmZcRp+aRErwZ9y96b7JzAmlW80eC9t03w+YOvzYui+WnGbEc?= =?iso-8859-1?Q?A20QZWlJ+1JWv1p7TPoH4Sx4sfbheGgfab2A5qk6c7g2fHKnglNRGRS7H8?= =?iso-8859-1?Q?f4g5z72JVd2gsoAyvYYnlZZxVV/mZ8P9irCISvh0TlKSrKl0lBMUJxJxGu?= =?iso-8859-1?Q?igO8Cwif5B35pWebD11/VSAKIEzhopBukhJnNznWB2M/kEqGdmTgJwZYPY?= =?iso-8859-1?Q?zylhaiZfMz9NlHxZdfRkhCpWzTHOtKVk6+AOADSwvRiS1vhF4H+vB7tMr9?= =?iso-8859-1?Q?4/crVkkGpra/1l+4pIaRa34vEMM8O75Q3s+tvl8To1EcZ6acL9wI5dHRkS?= =?iso-8859-1?Q?Y9+WR/lpawE70C1XHHTIisONil2gFTgLnw8vo3sCn1PuQtvbwjuY3ZnaU1?= =?iso-8859-1?Q?QCuyoji6SVYA0dTWAgQKdm1jRXWqcXrDO7UdehMxicDGMzmI14wUp4e6d/?= =?iso-8859-1?Q?zZaJHJZusCI4BjKlTEb0o7IVsMHpWB8AifRD8KW8Zm+PLFLdjwlG2sXzN4?= =?iso-8859-1?Q?iMKlBGhOnaCAyyo5yw60hYZTNm0p2Sc/r2tk3OX7X9dV3V+hq/2n2KGMiW?= =?iso-8859-1?Q?dajeJsU31wtzJ7SxYnuNIvkSmuGm1r5/jjvQpS9Amt91ofBWCYihvuPOjB?= =?iso-8859-1?Q?k+6jhKSKWiZwSldRxkeHPLO/Q00iXn7Uw5HHc9W5KddIcoltYlAcz5a3Rg?= =?iso-8859-1?Q?ufqcKrMsFg9D8tNenG6wu0oQcJKMAQUKXpKxM+hQC+GpPjGOgcJNyUosbq?= =?iso-8859-1?Q?vZkMVHb7uFMmDuHXJbUgoApBy99bhxIm5K2uhkbfGaDBdA6c+kq9IGQ+ON?= =?iso-8859-1?Q?LF/gpdEfmwoJCZRcHgsbxPGcqQeId4RMcn4WdA0X5Ig0912fZCLjQdJSDd?= =?iso-8859-1?Q?eLhHsjQ7mMbDgFi2Ta0cbAkPiQUhv/QLgS+uEF9vBWSGYnJnwc46h+GphW?= =?iso-8859-1?Q?O5mvSOu2JBNNVnQr9lNFNvdso2bUPkmdyOI8PbTa/poUzb7fa9WcPWRuSt?= =?iso-8859-1?Q?0WokPES/+DmayJ+JYXOY8NT5BoFS5jrmY9/QaXJCcwWnNtX+fiXJkt/jyS?= =?iso-8859-1?Q?WcbQT2bNw9?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P123MB359954A22CD47EB8F11C6E4CD7079LO2P123MB3599GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: ef24729d-1af9-468b-d104-08d936f06f6b X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2021 09:14:13.8147 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FAqKw15aTQ57mPEHIsyxZ3GlUeAcw3ar/KmtFNkesg80i2Zk8AlKvbSvZI+Qu4stJ5SKcaBoOrvg+mhY3+oaDQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB4942 Archived-At: Subject: [dispatch] IETF 111 meeting - call for topics X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 09:14:25 -0000 --_000_LO2P123MB359954A22CD47EB8F11C6E4CD7079LO2P123MB3599GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone, Do you have some work that needs dispatching? Or something that you'd like = to share with the ART AREA at IETF 111? Then get in touch! Patrick and I are starting to put together the agenda for the DISPATCH meet= ing at IETF 111 (26-30 July), so if you would like time at the meeting to d= iscuss your work or ideas, then please get in touch with us on the dispatch= chairs email (CC'd). We're keen to hear from you! And if you're not really sure what this dispatching thing is for, or if you= have questions about bringing new work, please get in touch with us all th= e same - we're here to help. We look forward to hearing from you! Kirsty This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB359954A22CD47EB8F11C6E4CD7079LO2P123MB3599GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everyone,

Do you have some work that needs dispatching? Or something that you'd = like to share with the ART AREA at IETF 111? Then get in touch!

Patrick and I are starting to put together the agenda for the DISPATCH= meeting at IETF 111 (26-30 July), so if you would like time at the meeting= to discuss your work or ideas, then please get in touch with us on the dispatch chairs email (CC'd). We're keen to= hear from you!

And if you're not really sure what this dispatching thing is for, o= r if you have questions about bringing new work, please get in touch with u= s all the same - we're here to help.

We look forward to hearing from you!

Kirsty



This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB359954A22CD47EB8F11C6E4CD7079LO2P123MB3599GBRP_-- From nobody Wed Jun 30 09:24:54 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E733A21F7; Wed, 30 Jun 2021 09:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=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=fastmail.fm header.b=HMsXklN0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZKbSYwro Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASbp8u4-OLJQ; Wed, 30 Jun 2021 09:24:46 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138823A21F5; Wed, 30 Jun 2021 09:24:46 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 318453200924; Wed, 30 Jun 2021 12:24:44 -0400 (EDT) Received: from imap37 ([10.202.2.87]) by compute6.internal (MEProxy); Wed, 30 Jun 2021 12:24:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=zYJAWuFAnKtnSDuKvQ0BugsLI2GspcS ynVtLAmb2Gds=; b=HMsXklN0IpD6dyPSdgrp3xZc+KUsmnuEYZrzojl5gOFNo90 xYcVKfO5Jwvn05qSOIoVAwxnfHF0y2fMyOJMtpnQpdZYAK1ZyD1VYfm6zwMyqVmw m3/0/hq1iJmFTr1OM7CG/eNEX1x5PQhXkmlGbvo3oU/q3X9XoYTlEzjOkJKPmRzX ax7PqXl2R/NXdhGM+vothLVf6F2Gaz3Ef7XP41Kt1Ejva0rdvBVVQOfm+yQxNHpu csovPvVzQ0lJp968qXBboQoEplX4ZfBXGFhoLeFOu1LocPtR1kG/Zipt+XJDKiED wv9Td2sOa6hBWvr8wbA81cH0A/kFWcnD8icuu4Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=zYJAWu FAnKtnSDuKvQ0BugsLI2GspcSynVtLAmb2Gds=; b=ZKbSYwrorihm61AkGVhe77 MZHz7hj/hdXi/RUqr2n+YRmY0Jt5tJLDfM2Rj6mtO+Wy6Vs20zVeoNzuCwbnkjdk q818zUYx5SFSTT8C8SxvGyL5YQdrE+H06dM9VnMwEDOqAbHSrWAfXeO9CMUU9c/u oOq9xk+hRDo+myQdnfRlGMrAOk7sS4WqkhjOt6keNwDWztfeOVMghPO+lDLcRyTf WUiuVdotrTCMGriXaN37+WGRLGjplRVVfTqD4GKMvLr4/XP8kWSdHv/dTfj0Jjkf KAzMKR6aLn9uIhmpP4s7O7z7mZLXgnXidgVOKSPto4ZUiO3KtR99RpFSIMinVcWg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeeigedgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuggftrfgrthhtvghrnhepfeeggfeiudejgedtledugfduvdfgteefiedtveet udekfeegtefgheeuiedvgfeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2C7236B4006A; Wed, 30 Jun 2021 12:24:43 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578 Mime-Version: 1.0 Message-Id: <2aefbe02-bf86-4689-a8d3-b6fd8149ed56@www.fastmail.com> In-Reply-To: References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> <01RZSLCQGG9Y00IM2V@mauve.mrochek.com> Date: Wed, 30 Jun 2021 17:24:21 +0100 From: "Alexey Melnikov" To: "Murray S. Kucherawy" , "Paul Libbrecht" Cc: media-types@ietf.org, DISPATCH , "Ned Freed" Content-Type: multipart/alternative; boundary=cf76d1459189407fbf20bb44772b58fc Archived-At: Subject: Re: [dispatch] [media-types] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2021 16:24:52 -0000 --cf76d1459189407fbf20bb44772b58fc Content-Type: text/plain Hi all, On Tue, Jun 22, 2021, at 11:36 PM, Murray S. Kucherawy wrote: > On Wed, Jun 16, 2021 at 11:00 PM Paul Libbrecht wrote: >> __ >> I am wondering if the group is the right place to prepare an update of the registration template so as remove the Macintosh 4-letter-codes and insert clipboard flavours for windows and universal type identifiers for macOS. >> >> This was discussed a few times on this mailing list. >> I have been in contact with a few media-type proposers, some of which have accepted a change of their declaration in this direction. >> I have been in contact with one IETF-aware person to update RFC6838 but that has not progressed. >> I am the guilty IETF-aware person... I am thinking that if we are doing all other related work we might as well tackle this, so I am in support of doing this in the WG. Now ideally I would like this to be addressed as an extension to the media type registration template that list extra optional fields. So I don't want to reopen RFC6838, but a separate draft that updates it would be great. > > There's been no feedback from anyone else, up or down, about this idea. My own impression is that this isn't quite within scope of what we're talking about for this effort, but then again it makes sense to include this now rather than spin up a subsequent effort or wait for the next train. Naturally I'm happy to include this in the proposed charter if there's consensus to include it. > > I'm just about to enqueue the charter we have in hand for its first IESG review pass before it goes out for general review. If this or any other change should be included in that submission, please (everyone, anyone) say something sooner rather than later. Hopefully it is not too late :-). Best Regards, Alexey --cf76d1459189407fbf20bb44772b58fc Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi all,

On Tue, Jun 22, 2021, at 11:36 PM, Murray S. Kucherawy= wrote:
On Wed, Jun 16, 2021 at 11:00 PM Paul Libbrecht <paul@hoplahup.net> wrote:

I am wo= ndering if the group is the right place to prepare an update of the regi= stration template so as remove the Macintosh 4-letter-codes and insert c= lipboard flavours for windows and universal type identifiers for macOS. =

This was discussed a few times on thi= s mailing list.
I have been in contact with a few media-= type proposers, some of which have accepted a change of their declaratio= n in this direction.
I have been in contact with one IET= F-aware person to update RFC6838 but that has not progressed.
<= p>


<= /div>
I am the guilty IETF-aware person...

<= div>I am thinking that if we are doing all other related work we might a= s well tackle this, so I am in support of doing this in the WG. Now idea= lly I would like this to be addressed as an extension to the media type = registration template that list extra optional fields. So I don't want t= o reopen RFC6838, but a separate draft that updates it would be great.


There's bee= n no feedback from anyone else, up or down, about this idea.  My ow= n impression is that this isn't quite within scope of what we're talking= about for this effort, but then again it makes sense to include this no= w rather than spin up a subsequent effort or wait for the next train.&nb= sp; Naturally I'm happy to include this in the proposed charter if there= 's consensus to include it.

I'm just about = to enqueue the charter we have in hand for its first IESG review pass be= fore it goes out for general review.  If this or any other change s= hould be included in that submission, please (everyone, anyone) say some= thing sooner rather than later.
H= opefully it is not too late :-).

Best Regar= ds,
Alexey

--cf76d1459189407fbf20bb44772b58fc-- From nobody Wed Jun 30 13:51:10 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFCF3A2A3C for ; Wed, 30 Jun 2021 13:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.421 X-Spam-Level: X-Spam-Status: No, score=0.421 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, HTML_MIME_NO_HTML_TAG=0.377, MALF_HTML_B64=1, MIME_BASE64_TEXT=1.741, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGZ_cpSgnvOg for ; Wed, 30 Jun 2021 13:51:04 -0700 (PDT) Received: from forward104j.mail.yandex.net (forward104j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::107]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE7D3A2A38 for ; Wed, 30 Jun 2021 13:51:04 -0700 (PDT) Received: from sas1-1fb0fcb041b9.qloud-c.yandex.net (sas1-1fb0fcb041b9.qloud-c.yandex.net [IPv6:2a02:6b8:c14:2688:0:640:1fb0:fcb0]) by forward104j.mail.yandex.net (Yandex) with ESMTP id EB18B4A14D5; Wed, 30 Jun 2021 23:51:00 +0300 (MSK) Received: from mail.yandex.ru (mail.yandex.ru [151.252.65.190]) by sas1-1fb0fcb041b9.qloud-c.yandex.net (mxback/Yandex) with HTTP id woodWj0J50U1-oxJWiqX0; Wed, 30 Jun 2021 23:51:00 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1625086260; bh=AdZ+aS/qFugx2qQEU+D0UbJwAMEq0uPE83x13Wxrysk=; h=Message-Id:Date:Cc:Subject:To:From; b=ev/+WBUpFsyqJVTn+iMzpTVA3h3m+BL4StUnozJ030Llg9fKzjyRsVugynbUPM/aj qEav/f9JbM8crc6nvjtgE27YLCyVQPas1U5gr8WE2UclKjgeDsGuh/PSRN9JejQoCP /dk1Z8GNDSe2AdzrEbkI8t/gZCiugbBe0S+uVgfQ= Authentication-Results: sas1-1fb0fcb041b9.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Received: by sas1-28d87b1eb748.qloud-c.yandex.net with HTTP; Wed, 30 Jun 2021 23:50:59 +0300 From: Anton Tveretin To: DISPATCH list Cc: "cullrich@immersion.com" , "ymuthusamy@immersion.com" MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 01 Jul 2021 01:50:59 +0500 Message-Id: <1218211625084352@mail.yandex.ru> Content-Transfer-Encoding: base64 Content-Type: text/html Archived-At: Subject: Re: [dispatch] draft-muthusamy-dispatch-haptics X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2021 20:51:09 -0000 PGRpdj5IZWxsbyBBbGwhPC9kaXY+PGRpdj5Tb3JyeSwgSSB3YW50ZWQgdG8gd3JpdGUgdGhpcyBl YXJsaWVyLCBidXQgSSB3YXMgb24gdmFjYXRpb24uLi4gTm93IEkgZG8gbm90IGtub3cgd2hvbSB0 byB3cml0ZSBiZXN0LjwvZGl2PjxkaXY+MS4gSSByZWluc3RhdGUgdGhhdCB0aGVyZSBhcmUgdHdv IGRpZmZlcmVudCBuYW1lc3BhY2VzIGZvciB0eXBlczsgbmFtZWx5LCBNSU1FIGFuZCBzdHJlYW0g dHlwZXMgYXMgaW4gU0RQIFtSRkMgMzI2NCBhbmQgbGF0ZXJdLiBBcyBhbiBleGFtcGxlOiBlYXJs eSB2aWRlbyBzdHJlYW0gZm9ybWF0cyAoQ2luZXBhaywgRFZJLCBJbmRlbykgY29tYmluZWQgd2l0 aCBhdWRpbywgc3RvcmVkIGluIGFueSBjb250YWluZXIgZm9ybWF0IChBVkksIFF1aWNrVGltZSwg bGF0ZXIgQVNGKS48L2Rpdj48ZGl2PjIuIEkndmUgZm91bmQgYSByYXRoZXIgb2xkIGxpc3Qgb2Yg RVMgdHlwZXMsIEkgcHVibGlzaGVkIGl0IG9uIEdpdGh1YiwgYnV0IGl0IGlzIGluIFJ1c3NpYW4u IEkgcGVyY2VpdmUgaXQgYXMgZGlmZmVyZW50IFRWLWxpa2UgRVMgKHN0aWxsIFNEUC4uLik8L2Rp dj48ZGl2PjMuIEknbSB3cml0aW5nIGEgbGlzdCBvZiBtZWRpYSB0eXBlcyBmb3IgNkdUQVBJLiBJ dCBpcyBjbGVhcmx5IHNsaWdodGx5IGRpZmZlcmVudCBmcm9tIHRoZSBFUyBsaXN0LiBCdXQgYW4g QVBJIGlzIG5vdCBib3VuZCB0byBhbiBpbXBsZW1lbnRhdGlvbi4gTGlrZXdpc2UsIHRoZXJlIGFy ZSBubyBzdWJ0eXBlcyBpbiB0aGUgQVBJLCBhbiBpbXBsZW1lbnRhdGlvbiBpcyBmcmVlIHRvIGNo b29zZSBhbnkuPC9kaXY+PGRpdj40LiBTbywgdGhlIGZhY3QgdGhhdCBzb21lIHR5cGUgaXMgZGVm aW5lZCBmb3IgaW4gc29tZSBjb250ZW50IG9yIHN0cmVhbSB0eXBlIGRvZXMgbm90IG1lYW4gYW55 dGhpbmcgZm9yIG90aGVyIGZvcm1hdHMgb3IgQVBJcy48L2Rpdj48ZGl2PlRodXMsIEkgc2VlIHRo ZSByZWFzb24gZm9yICJoYXB0aWMvLi4uIiBpZiBvbmx5IHRoZXJlIHdpbGwgYmUgImhhcHRpYy8x IiwgImhhcHRpYy8yIiwgLi4uIGFzIG9wcG9zZWQgdG8gImFwcGxpY2F0aW9uL2hhcHRpYyIuPC9k aXY+ From nobody Wed Jun 30 14:09:58 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A1A3A2B09 for ; Wed, 30 Jun 2021 14:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FktdKrf8B-Ol for ; Wed, 30 Jun 2021 14:09:52 -0700 (PDT) Received: from 10.mo177.mail-out.ovh.net (10.mo177.mail-out.ovh.net [46.105.73.133]) (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 4CFA53A2B06 for ; Wed, 30 Jun 2021 14:09:51 -0700 (PDT) Received: from player788.ha.ovh.net (unknown [10.110.103.118]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id 80BF91659D4 for ; Wed, 30 Jun 2021 23:09:49 +0200 (CEST) Received: from hoplahup.net (pd9526ca7.dip0.t-ipconnect.de [217.82.108.167]) (Authenticated sender: paul@hoplahup.net) by player788.ha.ovh.net (Postfix) with ESMTPSA id 104CB1FC6642E; Wed, 30 Jun 2021 21:09:44 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-104R005dcda3571-b674-4f03-8161-b4a49b0bae03, DFFEAFC7B9EFBBCC258E3DC0D3CC50C9FA61C943) smtp.auth=paul@hoplahup.net X-OVh-ClientIp: 217.82.108.167 From: "Paul Libbrecht" To: "Alexey Melnikov" Cc: "Murray S. Kucherawy" , media-types@ietf.org, DISPATCH , "Ned Freed" Date: Wed, 30 Jun 2021 23:09:36 +0200 X-Mailer: MailMate (1.14r5757) Message-ID: <4D858397-159F-42E9-B9BC-41457FF9E17E@hoplahup.net> In-Reply-To: <2aefbe02-bf86-4689-a8d3-b6fd8149ed56@www.fastmail.com> References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> <01RZSLCQGG9Y00IM2V@mauve.mrochek.com> <2aefbe02-bf86-4689-a8d3-b6fd8149ed56@www.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_B59B7529-626B-4183-BAED-6434B14C2844_=" Embedded-HTML: [{"plain":[110, 1815], "uuid":"DC6580B6-86B8-411E-9E8D-F021E5FB6341"}] X-Ovh-Tracer-Id: 15968919855018648805 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrfeeigedgieefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffoffkjghfgggtsegrtdhmreertdejnecuhfhrohhmpedfrfgruhhlucfnihgssghrvggthhhtfdcuoehprghulheshhhophhlrghhuhhprdhnvghtqeenucggtffrrghtthgvrhhnpeekgfehieefueeghfeijefgfffhieehffeiveefhfefteegveekfeehgeeffefhheenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedtrddtrddtrddtpddvudejrdekvddruddtkedrudeijeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejkeekrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepphgruhhlsehhohhplhgrhhhuphdrnhgvthdprhgtphhtthhopeguihhsphgrthgthhesihgvthhfrdhorhhg Archived-At: Subject: Re: [dispatch] [media-types] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2021 21:09:56 -0000 --=_MailMate_B59B7529-626B-4183-BAED-6434B14C2844_= Content-Type: text/plain; format=flowed I am happy to help on this topic if this is feasible. paul On 30 Jun 2021, at 18:24, Alexey Melnikov wrote: > Hi all, > > On Tue, Jun 22, 2021, at 11:36 PM, Murray S. Kucherawy wrote: >> On Wed, Jun 16, 2021 at 11:00 PM Paul Libbrecht >> wrote: >>> __ >>> I am wondering if the group is the right place to prepare an update >>> of the registration template so as remove the Macintosh >>> 4-letter-codes and insert clipboard flavours for windows and >>> universal type identifiers for macOS. >>> >>> This was discussed a few times on this mailing list. >>> I have been in contact with a few media-type proposers, some of >>> which have accepted a change of their declaration in this direction. >>> I have been in contact with one IETF-aware person to update RFC6838 >>> but that has not progressed. >>> > > I am the guilty IETF-aware person... > > I am thinking that if we are doing all other related work we might as > well tackle this, so I am in support of doing this in the WG. Now > ideally I would like this to be addressed as an extension to the media > type registration template that list extra optional fields. So I don't > want to reopen RFC6838, but a separate draft that updates it would be > great. > >> >> There's been no feedback from anyone else, up or down, about this >> idea. My own impression is that this isn't quite within scope of >> what we're talking about for this effort, but then again it makes >> sense to include this now rather than spin up a subsequent effort or >> wait for the next train. Naturally I'm happy to include this in the >> proposed charter if there's consensus to include it. >> >> I'm just about to enqueue the charter we have in hand for its first >> IESG review pass before it goes out for general review. If this or >> any other change should be included in that submission, please >> (everyone, anyone) say something sooner rather than later. > Hopefully it is not too late :-). > > Best Regards, > Alexey > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types --=_MailMate_B59B7529-626B-4183-BAED-6434B14C2844_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">I am happy to help on this topic if this is feasible.
paul

On 30 Jun 2021, at 18:24, Alexey Melnikov wrote:

Hi all,

On Tue, Jun= 22, 2021, at 11:36 PM, Murray S. Kucherawy wrote:
On Wed, Jun 16, 2= 021 at 11:00 PM Paul Libbrecht <p= aul@hoplahup.net> wrote:

I am wondering if the = group is the right place to prepare an update of the registration templat= e so as remove the Macintosh 4-letter-codes and insert clipboard flavours= for windows and universal type identifiers for macOS.

This was discussed a few times on this mailing list.
=
I have been in contact with a few media-type proposers, some = of which have accepted a change of their declaration in this direction. <= br>
I have been in contact with one IETF-aware person to updat= e RFC6838 but that has not progressed.

=

I am the guilty= IETF-aware person...

I am thinking that if = we are doing all other related work we might as well tackle this, so I am= in support of doing this in the WG. Now ideally I would like this to be = addressed as an extension to the media type registration template that li= st extra optional fields. So I don't want to reopen RFC6838, but a separa= te draft that updates it would be great.


<= div>There's been no feedback from anyone else, up or down, about this ide= a.=C2=A0 My own impression is that this isn't quite within scope of what = we're talking about for this effort, but then again it makes sense to inc= lude this now rather than spin up a subsequent effort or wait for the nex= t train.=C2=A0 Naturally I'm happy to include this in the proposed charte= r if there's consensus to include it.

I'm ju= st about to enqueue the charter we have in hand for its first IESG review= pass before it goes out for general review.=C2=A0 If this or any other c= hange should be included in that submission, please (everyone, anyone) sa= y something sooner rather than later.
<= div>Hopefully it is not too late :-).

Best R= egards,
Alexey

___________________________________= ____________
media-types mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-types

--=_MailMate_B59B7529-626B-4183-BAED-6434B14C2844_=-- From nobody Wed Jun 30 18:34:58 2021 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A983A0B1A; Wed, 30 Jun 2021 18:34:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dispatch@ietf.org Message-ID: <162510329549.9791.8155967866092541287@ietfa.amsl.com> Date: Wed, 30 Jun 2021 18:34:55 -0700 Archived-At: Subject: [dispatch] I-D Action: draft-ietf-dispatch-javascript-mjs-09.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2021 01:34:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dispatch WG of the IETF. Title : ECMAScript Media Types Updates Authors : Matthew A. Miller Myles Borins Mathias Bynens Bradley Farias Filename : draft-ietf-dispatch-javascript-mjs-09.txt Pages : 27 Date : 2021-06-30 Abstract: This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This document obsoletes RFC4329, "Scripting Media Types", replacing the previous registrations for "text/javascript" and "application/javascript" with information and requirements aligned with implementation experiences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dispatch-javascript-mjs-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dispatch-javascript-mjs-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 30 19:00:25 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6453A0CA9 for ; Wed, 30 Jun 2021 19:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 1YKqY_CU215t for ; Wed, 30 Jun 2021 19:00:19 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D09B3A0CA8 for ; Wed, 30 Jun 2021 19:00:19 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id k21so6121662ljh.2 for ; Wed, 30 Jun 2021 19:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=qfDFJGHE0+r1dcfazY5A60wYxeM+4SLCS5Rh7+0CTdI=; b=sMFDAzyX2vphLjbeY78zCQ3vijvdwlGAdIJIom3cZYIu3vS3iXsJEeXBx3YPdyOeqk E5J0FlRyM26vHHoRl4vrYjikSFMQaiVVs6vJUS9l586ufckQWYFECIwMZdj7XEnB2Ybo XXVweMPruxqU/HbNDNHeOv3abo0VvW3oZJKpqlRYGggdoYfB++sHUFY55XOBbWxtoOQC Mezd81JO5DvrSn8qq1M0j+iRx8v3sn6PxW6EZFySoCIisOHZF+VwkNvz34OMTk/jHPo/ GSIQc8A0sDp6Yv3LW7aA0o5bZF7rwMdnCg+vBGkCAt9MgJo4LI0yTWDt7gSAeMEvUJF0 r5RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=qfDFJGHE0+r1dcfazY5A60wYxeM+4SLCS5Rh7+0CTdI=; b=liLMdkfQci4qgQHqGSNQbf5jJJ8NcOwOugiUcqjh4RrPecI5hCdLwmkHgMxTSuHlEh BycVqFWOkCVXyYPXBxSlWFECYPAIeq2ddJlUNdGsXk+djgGtratN79L3B9ksNfHHmj6+ m3KXhmA0TCjVNoaDP5AktO+bub1Xbc+kxOFro90ptBf2LeLWv4sh8d19qddO6sNIfn1G HvPvA7C1SRcDWfyKgNmYVIl6f7W7fLsKmTZ/YUiB2kaixAYK4YR4726haUxPUlRE/Z0H T1o72FM9YYbCIMfpv/BjwnBlfaeIDePYySK7m/VxlMdOMdiuLb48kGR3lZAW7p7eTtWo 9alg== X-Gm-Message-State: AOAM531YwrzaRZc4ugSvW7njIpTgJW4ctN7/3ic2AtGd02JeyKdo5mal 4PaO4Y9/XDvYjO0m0v25afOjhOzb4lr5jxMTiqpMXeYtnJw9yOSC X-Google-Smtp-Source: ABdhPJzTFja3WaOXF2jmX6g9soczV9D8UtulwUYtdmwZkgv++Tz2KT6LYTSnr2Ms0S+PK2liitMNymbHuiX94lr4aXs= X-Received: by 2002:a2e:bc08:: with SMTP id b8mr10447201ljf.64.1625104813548; Wed, 30 Jun 2021 19:00:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: James Zern Date: Wed, 30 Jun 2021 19:00:02 -0700 Message-ID: To: DISPATCH list Content-Type: multipart/alternative; boundary="00000000000022f04d05c6063318" Archived-At: Subject: Re: [dispatch] processing path for image/webp rfc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2021 02:00:24 -0000 --00000000000022f04d05c6063318 Content-Type: text/plain; charset="UTF-8" On Tue, May 25, 2021 at 12:31 PM James Zern wrote: > Just bumping the thread for visibility. Are there any opinions on the > right processing path for the image/webp mime-type? > > On Wed, May 12, 2021 at 10:13 AM Murray S. Kucherawy > wrote: > >> On Thu, May 6, 2021 at 6:45 PM James Zern > 40google.com@dmarc.ietf.org> wrote: >> >>> On Thu, May 6, 2021 at 12:53 AM Murray S. Kucherawy >>> wrote: >>> >>>> On Thu, Apr 29, 2021 at 7:58 PM James Zern wrote: >>>> >>>>> It was suggested I post a message here requesting advice on the >>>>> processing path of my submission to register the image/webp mime-type [1]. >>>>> I'm not familiar with the process, so if you could have a look and see if >>>>> this is appropriate for the DISPATCH working group or suggest another I'd >>>>> appreciate it. >>>>> >>>> In a thread on media-types there was a reference to MIME types supported by Debian packages [3]. image/webp is widely accepted, but I'd like to see it recognized officially to help unblock other work [4][5]. > >>>> Just a reminder that DISPATCH's charter includes: >>>> >>>> "- By agreement with ART ADs, processing simple administrative >>>> documents." >>>> >>>> If we agree that this work fits that description, then that's a >>>> processing option here. >>>> >>>> I would also suggest this be floated by media-types@ietf.org, if that >>>> hasn't been done already. >>>> >>> >>> I requested a review on that list [2]. Did you want to start a separate >>> thread to request advice on a processing path? >>> >> >> Nope, that's what this thread is for. >> > [1] https://datatracker.ietf.org/doc/draft-zern-webp/ [2] https://mailarchive.ietf.org/arch/msg/media-types/EYRWG6ochcIhAFhBwHCJlsBVV38/ [3] https://mailarchive.ietf.org/arch/msg/media-types/r0MJSX-WIywIAnq9w7slgWtLhUU/ [4] https://crbug.com/webp/448 [5] https://crbug.com/webp/485 > >> -MSK >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > --00000000000022f04d05c6063318 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 25, 2021 at 12:31 PM Jame= s Zern <jzern@google.com> wro= te:
Just bumping the thread for visibility. Are there any opinions on= the right processing path for the image/webp mime-type?

On Wed, May 12, 202= 1 at 10:13 AM Murray S. Kucherawy <superuser@gmail.com> wrote:
On= Thu, May 6, 2021 at 6:45 PM James Zern <jzern=3D40google.com@dmarc.ietf.org&g= t; wrote:
On Thu, May 6, 2021 at 12:53 AM Murra= y S. Kucherawy <superuser@gmail.com> wrote:
= On Thu, Apr 29, 2021 at 7:58 PM James Zern <jzern@google.com> wrote:
I= t was suggested I post a message here requesting advice on the processing p= ath of my submission to register the image/webp mime-type [1]. I'm not = familiar with the process, so if you could have a look and see if this is a= ppropriate for the DISPATCH working group or suggest another I'd apprec= iate it.

In = a thread on media-types there was a reference to MIME types supported by De= bian packages [3]. image/webp is widely accepted, but I'd like to see i= t recognized officially to help unblock other work [4][5].
=C2=A0=
=

Just a reminder that DISPATCH's charter incl= udes:

"- By agreement with ART ADs, processing simple administr= ative documents."

If we agree that this work = fits that description, then that's a processing option here.
=
I would also suggest this be floated by media-types@ietf.org, if that has= n't been done already.

I requested a review on that list [2]. Did you want to start a separa= te thread to request advice on a processing path?

Nope, that's what this thread is for.

[4]=C2=A0https://crbug.com/webp/448=
=C2=A0

-MSK
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000022f04d05c6063318--