From nobody Mon Sep 4 02:57:31 2023 Return-Path: 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 1197EC14CE4F; Mon, 4 Sep 2023 02:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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="PqxJyTwm"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="lfayNR66" Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7n2uKMDSwk8; Mon, 4 Sep 2023 02:57:26 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA22EC14CE31; Mon, 4 Sep 2023 02:57:25 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 71E745C00BE; Mon, 4 Sep 2023 05:57:22 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute3.internal (MEProxy); Mon, 04 Sep 2023 05:57:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:cc:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1693821442; x=1693907842; bh=dals2V5tXqIWveARqTOKsmwIbIwO+awufL4 PzCabJ/0=; b=PqxJyTwmbUtOiiYQ9J9uA8DHFySdVnSZG+0+oSfEA2wg4eZVrT3 +uD4D99n/E47nsHF0I5axvSOTZ8jn/U1kxqOVSvRl9WrsAxCBQ1WeSqvjoIpt49G 4L5tQMFEcsF2GgNbaXOvK/SkEGwACv4dBpgNuW0iemDrf27jHfolQFvMy88SDeij d3T7eU4K0RQ9GbUdTTFvchom/RjNpFWheNc+sHL6DaomIQoWoLD5boL/TJ7fOn52 /qx6w32r0pF1evIXEehXy3zd13L1vRl0JqZUbMr3TH9lsnLWJTOc0RHDtUnUpCsH UlUPsf9Xa82AINW9Dg2lUZk60Tz3GM2o2sQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1693821442; x=1693907842; bh=dals2V5tXqIWv eARqTOKsmwIbIwO+awufL4PzCabJ/0=; b=lfayNR66oofNhfsHuIGaACLYd4cCp x1tRe972gBFGblgN1DITJ33vFRoPxNx42D2t9JkDAL10eNBQB/Jrxq0edz0LVFHU tIPHnIKMLwB0inNDb0upxoKjZBk5EFjoRVQimNquSiyOXJdk+IniaUzFTANMPOIr NGpdfWYFaYi3PQfJjyqd7PXgaoW+1ZYQPeiPtehA1TmXxNPyzazNp+Zfcnf+j5yX TQfOgxo8WywV5ggfIN6Xlp5RLzkVkrlsTjI0mE08u0bKV0P5HDzWF3FRwp697Klj MxvlGjyZT5hWJyj2wMlKKQPxTJnGU4VSehP3x4dJpVWHdT1+e2Tbj19kw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudegkedgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerreejnecuhfhrohhmpedftfho sggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthhosehfrghsthhmrghilhhtvggrmhdrtg homheqnecuggftrfgrthhtvghrnheplefgheejtddutdfgieefjeejjeduiefhkeevfeeg ueehuddtvdelgfffveefvdejnecuffhomhgrihhnpehitggrnhhnrdhorhhgpdhivghtfh drohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Feedback-ID: ia5d944da:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 86FD52D40092; Mon, 4 Sep 2023 05:57:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-711-g440737448e-fm-20230828.001-g44073744 Mime-Version: 1.0 Message-Id: <31f3f732-db0e-4f02-8ea4-4a0148c187a2@app.fastmail.com> In-Reply-To: References: <168207023641.10169.13335976589846153291@ietfa.amsl.com> <5beb7882-4f67-039c-00ae-49d86277ccb6@it.aoyama.ac.jp> <3498b43d-14a1-4734-a231-7b92aca934ff@app.fastmail.com> <13F35ABF-6AE8-4E32-8C24-544F02BE79B0@tzi.org> <2bb161cc-fdfc-49f8-8b36-c1b329603f04@app.fastmail.com> <27F6E36C-B7E0-4367-8789-574B1E659EDF@tzi.org> <2a1c3796-6844-b428-6f4b-0a7703a18ba1@it.aoyama.ac.jp> <85c0c403-fa48-4491-b051-c93f6a06d0cf@app.fastmail.com> <9306fcbd-7a44-45e7-847f-e81e82c1213c@app.fastmail.com> Date: Mon, 04 Sep 2023 11:57:00 +0200 From: "Robert Stepanek" To: "Rob Sayre" Cc: "Daniel Migault" , =?UTF-8?Q?Martin_D=C3=BCrst?= , "Carsten Bormann" , art@ietf.org, calsify@ietf.org, draft-ietf-calext-jscontact.all@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary=1705eacda4ec4421a452ea24af029c26 Archived-At: Subject: Re: [calsify] [Last-Call] Artart last call review of draft-ietf-calext-jscontact-07 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2023 09:57:31 -0000 --1705eacda4ec4421a452ea24af029c26 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 1, 2023, at 9:05 AM, Rob Sayre wrote: > On Thu, Aug 31, 2023 at 11:45=E2=80=AFPM Robert Stepanek wrote:__ >> I am wary of restating too many requirements in the JSContact RFC for= which other RFCs are authorative: there's always the risk of getting it= wrong. That especially applies to DNS: https://rfc-annotations.research= .icann.org. >=20 > I am not trying to be difficult here. I don't think you are, I appreciate all your comments! I also agree it's= important to come to a good conclusion with internationalizations and U= RIs, so we should take time for that. > I think your document is too strict, since the URL fields are delimite= d by JSON constructs. We currently strictly require URIs (RFC 3986) because that's straight-fo= rward to convert from and to vCard. So indeed your example IRI (RFC 3987= ) http://=E3=81=82=E3=81=82.com would not be allo= wed, it would need to be converted to a URI as outlined in section 3.1 o= f RFC 3987 . = I can image we allow using IRIs where we currently require URIs, they lo= ok like a great addition. I am just cautious as long as I haven't unders= tood all the implications. One part I'm particularly concerned about is how to convert IRIs for use= with vCard URI-typed properties . Citing Section 3.1 of the IRI spec: "= Systems [...] MAY convert the ireg-name component of an IRI [...] for sc= hemes known to use domain names in ireg-name, if the scheme definition d= oes not allow percent-encoding for ireg-name". This suggests to me that getting from an IRI to a valid URI requires sch= eme-specific rules, and using IRIs in JSContact would require implementa= tions to take these rules into account during conversion to vCard. That'= s definitely more effort than just copying a string value from one repre= sentation to another. It's OK should we decide that IRIs are worth that = additional effort, it's just a decision I don't want to take lightly. What URI schemes do require special handling during IRI conversion? Do a= ll schemes use domain names in ireg-name and so using Punycode for conve= rsion is basically a given? How well are IRIs and URI conversion support= ed in software libraries, especially outside browsers? Is there more to = say about security other than highlighting the spoofing concerns of RFC = 3987? I'd appreciate any feedback, especially from people who have more experi= ence with working with IRIs than me. --1705eacda4ec4421a452ea24af029c26 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Fri, Se= p 1, 2023, at 9:05 AM, Rob Sayre wrote:
On Thu, Aug 31= , 2023 at 11:45=E2=80=AFPM Robert Stepanek <rsto@fastmailteam.com> wrote:
=
I am wary of restating too many requirements in the JSContact RFC f= or which other RFCs are authorative: there's always the risk of getting = it wrong. That especially applies to DNS: https://rfc-annotations.resea= rch.icann.org.

I am not trying to be difficult here.

I don't think you are, I appreciate all your commen= ts! I also agree it's important to come to a good conclusion with intern= ationalizations and URIs, so we should take time for that.

I think your document is too stric= t, since the URL fields are delimited by JSON constructs.

We currently strictly require UR= Is (RFC 3986) because that's straight-forward to convert from and to vCa= rd. So indeed your example IRI (RFC 3987) http://=E3=81=82=E3=81=82.com would not be allow= ed, it would need to be converted to a URI as outlined in section 3.1 of R= FC 3987. I can image we allow using IRIs where we currently require = URIs, they look like a great addition. I am just cautious as long as I h= aven't understood all the implications.

One= part I'm particularly concerned about is how to convert IRIs for use wi= th vCard URI-typed properties . Citing Section 3.1 of the IRI spec: "Sys= tems [...] MAY convert the ireg-name component of an IRI [...] for schem= es known to use domain names in ireg-name, if the scheme definition does= not allow percent-encoding for ireg-name".

This suggests to me that getting from an IRI to a valid URI requires sc= heme-specific rules, and using IRIs in JSContact would require implement= ations to take these rules into account during conversion to vCard. That= 's definitely more effort than just copying a string value from one repr= esentation to another. It's OK should we decide that IRIs are worth that= additional effort, it's just a decision I don't want to take lightly.

What URI schemes do require special handling= during IRI conversion? Do all schemes use domain names in ireg-name and= so using Punycode for conversion is basically a given? How well are IRI= s and URI conversion supported in software libraries, especially outside= browsers? Is there more to say about security other than highlighting t= he spoofing concerns of RFC 3987?

I'd appre= ciate any feedback, especially from people who have more experience with= working with IRIs than me.
--1705eacda4ec4421a452ea24af029c26--