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/
- Re: [calsify] Feedback on draft-ietf-calext-ical-… Francesca Palombini
- Re: [calsify] Feedback on draft-ietf-calext-ical-… Michael Douglass
- Re: [calsify] Feedback on draft-ietf-calext-ical-… Mark Nottingham
- Re: [calsify] Feedback on draft-ietf-calext-ical-… Michael Douglass