Re: [calsify] Feedback on draft-ietf-calext-ical-relations

Mark Nottingham <mnot@mnot.net> Sat, 30 October 2021 00:39 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EBF3A1A0D; Fri, 29 Oct 2021 17:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=TEY/b86z; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FVSd+hsR
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 HaQpB6X3bsAS; Fri, 29 Oct 2021 17:39:06 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109C23A1A29; Fri, 29 Oct 2021 17:39:05 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id B3F133201D59; Fri, 29 Oct 2021 20:39:03 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 29 Oct 2021 20:39: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=fm1; bh=F jEO9pqACCTBtxZJgm1ruR2M53rbwm30xMKHtcpRU+M=; b=TEY/b86zrdBj8349h AJb5pV1VNvhApeBRNkEfV8N4rSCl3psHVfxtXWS48e+9l5aA73akMkpu9/IpjJiH JJfz3GXYSkITz3c/oCLOfqr4tsMQV/XZzlPanQx8UiZs4eO7pM8dZSR/SgZU/cyk La4mEiTpa+ufim3kDIPDQsrQhNIZYMbRVAcCwGKSbeDjcbdc4DQLl1BuNaTq3aYE e6VfDlTAMBSN2QHClQJSs9VMs2BLveNMdbGWA6I2hwpxSa6clfQtCgwqL0gWZt7M sCo9n+62rp1cvwXPpjOHYuGyVsxAI0GhAXlaidlcTkFx9Br5KpwnuTWyIF7fCAj/ cqqiQ==
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=fm1; bh=FjEO9pqACCTBtxZJgm1ruR2M53rbwm30xMKHtcpRU +M=; b=FVSd+hsRKWR5k4vLPigwfre5sA+oDdzAPc+ZsqwX3CQeqCyfJL6byMf3I n0NQdEsREpP7JrrU9fU1eKTefK3tL7HHz2U8NNHqTVmz12SFo0+jPAkheL1KFntA J8KKv6U9wlmeKDyRYMK4GRia30+AmH/ZF9JZNwT8SOLVNUKRiWXSYxGnE3DRx7U2 53Ae5n8pEnbBKiuMKeD8EhQOP2DBkLOzTFX1AkICBJkMjQJXNWxJY6ESzHHp8pG4 /D7XRqltCQePsLoStB+GI1SUqQN5CJDjXtA73YPmpfICVkaBeMA/h3rm+tYz3Mc3 d8okqhh5Z+pv2C3sEEAuRwUkIjprA==
X-ME-Sender: <xms:JpR8YQPkko5-0L9PWAthv0wPIq115Q4yHuYs2-h5DJN6nP5hy3CCvg> <xme:JpR8YW_jH8IiLy7qeA5OS7sun-UZFtn6WObkVpMtSZ7hTks3zweUVcbg8GXp61nNi FGdoNd7TWYvYJ1uOQ>
X-ME-Received: <xmr:JpR8YXTonTH_OPuKcHozqaE0qZpAo7CN_V9AjoyvvmvmLXeQv6m5do1i9tgjKkFtpQEKkHZ__NDgm7dKyxrgD0PGuoYHvcrkadsbydY9oHMHvqfQ9RuwWLm9>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdegiedgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeevffffhfduteevvefhueffieegtdeutdehffeltefffedttdeggeejheeiueet teenucffohhmrghinhepmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:JpR8YYud5ybtqpcHUTpI3OODNiK3OBF6GLZqLYKYVaijhD0s8N-SwA> <xmx:JpR8YYe6kKoMadRwNbOP8ONv-0dIxBpgD-yYH-MgIt8IQ3BFpFeHzg> <xmx:JpR8Yc1Rjy4Mr9vrGB6tqjRTIO0Gg74L938d2m8U-JkLQff5A0TiFw> <xmx:J5R8YfzVJ-GRHPDkv1265mfBtLilxPBOlVaFLE_AxUjolFwjDppNpg>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 29 Oct 2021 20:38:59 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <df1a8dd1-1782-d555-36f3-bb9c06b4cb61@gmail.com>
Date: Sat, 30 Oct 2021 11:39:01 +1100
Cc: Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>, "draft-ietf-calext-ical-relations@ietf.org" <draft-ietf-calext-ical-relations@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "calsify@ietf.org" <calsify@ietf.org>, "calext-chairs@ietf.org" <calext-chairs@ietf.org>, The IESG <iesg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BE133796-75FA-4A93-81A7-6CC860D21D09@mnot.net>
References: <CD95B935-9A4D-4FD8-8BA1-84A600F6FB0E@mnot.net> <HE1PR07MB421724DC84A7138DA01500B698869@HE1PR07MB4217.eurprd07.prod.outlook.com> <df1a8dd1-1782-d555-36f3-bb9c06b4cb61@gmail.com>
To: Michael Douglass <mikeadouglass@gmail.com>
X-Mailer: Apple Mail (2.3693.20.0.1.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/12HgDBty3_rpKOri2opS5ZDyyhQ>
Subject: Re: [calsify] Feedback on draft-ietf-calext-ical-relations
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Calendaring and Scheduling Standards Simplification <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Oct 2021 00:39:11 -0000

> On 29 Oct 2021, at 3:37 am, Michael Douglass <mikeadouglass@gmail.com> wrote:
> 
>> Two alternative paths forward would address this concern:
>> 
>> 1) Define this as a serialisation of 8288 links
>> 2) Use a separate registry
> A third path might be to specify how it differs while trying to come closer to 1.
> 
> I think having 2 registries defining essentially the same concept would be more confusing and lead to more misalignments. At least this way we only define it once.
> 
> I accept the point on context and attributes. I think we can deal with that - e.g. context is the referencing entity and define a mapping of existing parameters to the 8288 defined attributes (e.g. "title"->"label")

That sounds like you're defining a serialisation of 8288 links.

> RFC 8288 in Appendix A specifies how it differs from 2 other linking methods.

That's noting how different _serialisations_ work -- they are different ways to express the same data model.

Another question to ask is whether it makes sense for the link types currently registered to show up here, and vice versa (whether the ones you propose to register make sense in HTML, Atom, Link headers, etc.). That might help guide the answer.

Cheers,

--
Mark Nottingham   https://www.mnot.net/