From nobody Mon Dec 2 00:48:27 2019 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 11B5E1200A1 for ; Mon, 2 Dec 2019 00:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=qEzpD2WQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Zeye7kD6 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 7OBDeOT5H7YQ for ; Mon, 2 Dec 2019 00:48:24 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91E8B120013 for ; Mon, 2 Dec 2019 00:48:24 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id E90F89A8 for ; Mon, 2 Dec 2019 03:48:22 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute1.internal (MEProxy); Mon, 02 Dec 2019 03:48:23 -0500 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=fm1; bh=fdQ5DVM Xk1ztct3roCDD/fmDMGwMhKDhfqxTSwTBlEo=; b=qEzpD2WQNsh89PNyP9/S0sc Mnk1JPfv0rJZFcIme87/iBjtVP48dgohxkEtzSMZFy1mVIgj5TIh56W0t1vF28Pw c8F6uTHnvZCRURb3CHldn7H7Wpgdv4OMwGEC4L4dsSgGxKlPGADn+vXMZRaoznpD MsKZ8IFN6i6Gu0X3L9CXAf62rT2a/8eMuK5ao3lAui4CyHa+pEihfT+7+KoKGmPo qKVASHcQX26E5MnBU9OMrJx5nqFSvBsy26SVYRENw/HV5vjKgvZARmliGYjl7OwN O1RLxDzXfrwibPSWGBtnxqgBDAlLbzYoYnxPYNQCuStb7u0SYW8KNTpXxZAEYgw= = 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=fm1; bh=fdQ5DV MXk1ztct3roCDD/fmDMGwMhKDhfqxTSwTBlEo=; b=Zeye7kD6Uq4XYfBqjbpOYV tvYzin78tNXS6Q3l1h8xS8z3ZyaQitWA9JEOu1f4b9KX4H5d7cQRW3xql3AV3njU oNYupxppe67g3hnBzqRBvFRlcSdinm00fr3C7vd09VIKEO41dEAG4tK0Ey5sBFx4 U1GcMdh3io8JSirDMstLgJDVOEcG4fcSWS9KlYAHjGnoLdz1bKtc8qDSXXOvqt/p AKHHHOOghbTQclgI9V4XY+GVFDyntMGEVMS6MdhVKM+EwvNq2EWj7tRqZNhKAKto SBn1nN2sH8k5xpfeCxFPqCL5DA9Wr26IpYFBV7ru6NHMp3VkENieTpgxwc39VkLg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudejgedguddviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshht ohesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomh eprhhsthhosehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigv pedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3766330006F; Mon, 2 Dec 2019 03:48:22 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <052a9cd1-f2a2-416d-9eda-3971ae2acee2@www.fastmail.com> In-Reply-To: References: <6d0fa1f3-5dbe-d4df-821f-a0bddb61546b@gmail.com> <3d216646-0235-0af4-b9ad-1401eea482c4@gmail.com> <7f83a966-d1e9-464e-acd2-45bb7fd05107@beta.fastmail.com> <98a0f7ca-213d-4be0-9b0c-310dad70c0ab@gmail.com> <595e1efa-97a0-4373-8d5f-d4e5e05a1838@dogfood.fastmail.com> <601a4ef3-d922-71e0-ab4b-8e539ed3f7ae@gmail.com> <669b29a4-1734-4ea1-9ac9-33e590d91762@dogfood.fastmail.com> <07d3a19b-5198-e9fa-acbf-94c5161e11fb@gmail.com> <322a91d4-3246-49df-a1c4-628a59cf5304@dogfood.fastmail.com> Date: Mon, 02 Dec 2019 09:48:02 +0100 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=764da8c78ce042ae9867d141cb56c9ca Archived-At: Subject: Re: [calsify] WGLC JSCalendar X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 08:48:26 -0000 --764da8c78ce042ae9867d141cb56c9ca Content-Type: text/plain On Mon, Nov 4, 2019, at 12:31 AM, Neil Jenkins wrote: > On Mon, 4 Nov 2019, at 08:40, Daniel Migault wrote: >> 1) IPR >> Could each author confirmed that any and all appropriate IPR >> disclosures required for full conformance with the provisions of BCP 78 >> and BCP 79 have already been filed. > > Confirmed from me. Confirmed from me as well. Cheers, Robert --764da8c78ce042ae9867d141cb56c9ca Content-Type: text/html
On Mon, Nov 4, 2019, at 12:31 AM, Neil Jenkins wrote:
On Mon, 4 Nov 2019, at 08:40, Daniel Migault wrote:
1) IPR
Could each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Confirmed from me.

Confirmed from me as well.

Cheers,
Robert

--764da8c78ce042ae9867d141cb56c9ca-- From nobody Wed Dec 4 20:56:26 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB4D1200B4; Wed, 4 Dec 2019 20:56:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <157552178053.11154.9870419677194116500@ietfa.amsl.com> Date: Wed, 04 Dec 2019 20:56:20 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-22.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 04:56:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : JSCalendar: A JSON representation of calendar data Authors : Neil Jenkins Robert Stepanek Filename : draft-ietf-calext-jscalendar-22.txt Pages : 75 Date : 2019-12-04 Abstract: This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative, and over time successor to, the widely deployed iCalendar data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCal format, it is not a direct mapping from iCalendar and expands semantics where appropriate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-22 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 4 20:58:45 2019 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 3972A120997 for ; Wed, 4 Dec 2019 20:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.073, SPF_PASS=-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=T3prMJmk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EshrDF4O 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 H1wPyNu9EXdY for ; Wed, 4 Dec 2019 20:58:39 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24F8120047 for ; Wed, 4 Dec 2019 20:58:39 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B1491227A8; Wed, 4 Dec 2019 23:58:38 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Wed, 04 Dec 2019 23:58:38 -0500 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:cc:subject:content-type; s=fm1; bh=8oJv U9mcIo4H8FABVcX4lchc78mAP5BdG80q1BeYetA=; b=T3prMJmkDE1xEzWDsuQ5 NRe5eaE+rM+/W+yrd5Y+dU11iHpgkfLAAFjYhj8yzCtdGHIOiwjseWLudLsvoPXB vW7qTCCcZ27oM5Ts0Y1FaRPuvWK6TNySyw6/8LKrNntqsmG9kTcH3NaU3vIb67KS mAFVrbRmDTRNuI6WLEpK4fVOcm91sS1fhOtB1+isLgYWg51ArkZkqEJhj5UCfL+H Nrw9D+vTwJqIpu37rj2bLaNwldd68el5Qh5jLffan3D75mP5imPBXPof60TKVOXx axVBNfqxDK48/rS+eSCDhHw1jLov5QmJoK/PZDJOkHNfRJdM0x7Spk3F6l2TEj7Z Kw== 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=fm1; bh=8oJvU9 mcIo4H8FABVcX4lchc78mAP5BdG80q1BeYetA=; b=EshrDF4OeOplFUhBevyyck piQYPcBylngvm+C3bvvP9NT7xT91oV9BQEMAM1L2ebdpVW99yG4ayoQFPm6B9dWh Dfz6+dhLlWWXnaCcFQH41CFYFEy25KOKxYQz8acvmKq7uJafYZT9Vr5fb0XbuZqv TgIDnGomKM3/YeKg/vSv5z9aLhpJSe6GBRilrXplwcclIq7tRE/EGpeWIkjl5kjd AcNFrJ/3wb/yE5L2dE9hc5G6HnsmmEfH/TOGSszxR/kwsALBfENd59WCqnt4uJsW drTKIEOeP4HXxVu7h8EEhfYYonbBy9u2uVhjQrwNj7HFcMrIhp6I4H2a+K4ICdTg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudektddgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucffohhmrghinhepihgvthhfrdhorhhgpdhirghnrgdrohhrghenucfrrghrrghmpehm rghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluh hsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3A66130006F; Wed, 4 Dec 2019 23:58:38 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-612-g13027cc-fmstable-20191203v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <6E2BEA12-C0B7-4117-A263-AD6F71FD94AE@iana.org> Date: Thu, 05 Dec 2019 15:58:18 +1100 From: "Neil Jenkins" To: "iana-issues-comment@iana.org" Cc: "Robert Stepanek" , "Daniel Migault" , "calsify@ietf.org" Content-Type: multipart/alternative; boundary=29d2d18fdcd54a00832f809e51f3223f Archived-At: Subject: Re: [calsify] =?utf-8?q?=5BIANA_=231156721=5D_Early_IANA_Review_for_?= =?utf-8?q?draft-ietf-calext-jscalendar-21?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 04:58:43 -0000 --29d2d18fdcd54a00832f809e51f3223f Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry for the delay responding. > About the statement that "The IANA will list common-use registrations = prominently and separately from those with other intended use values": w= ould listing common-use values first be sufficient, or would you want th= e registry divided into three separate registries?=20 Listing common-use values first is fine, no need for separate registries= . > The registration procedure for common use registrations is described a= s Specification Required (it might be helpful to capitalize the registra= tion procedures and cite RFC 8126),=20 I will capitalise Specification Required. RFC 8126 is referenced in Sect= ion 8.2.3 describing the expert review, but I will add another reference= here too. > but in the template, the reference field is named "RFC Reference." On = the other hand, if the statement in Section 8.2.3 that "for simple defin= itions a description in the registry may be sufficient" refers to the Sp= ecification Required range, I wonder if it could be more appropriate to = describe the registration procedure for that range as Expert Review and = have us add a note that says something like "RFC preferred." The registr= ation procedures for all three ranges (common, reserved, obsolete) could= be presented in a table like the ones at https://www.iana.org/assignmen= ts/cose, with the addition of a "Notes" field to expand on the requireme= nts/expectations for common-use submissions. I have changed this to "Reference or Description", defined as =E2=80=9CA= brief description or RFC number and section reference where the propert= y is specified=E2=80=9D. While we could make it Expert Review, I think Specification Required is = still correct, because we want to ensure there is sufficient documentati= on for interoperability. It's just sometimes a single sentence is suffic= ient, and to make it easy to update we'd like to just be able to put tha= t straight in the registry rather than require a separate document. Does that sound reasonable, or would you still prefer something differen= t? > The problem is that a description in the registry may not fit the desc= ription of Specification Required defined in Section 4.6 of RFC 8126: Reading this again, I can't see anything in it that prohibits the specif= ication being included in the registry entry itself. > Sections 8.4.1 and 8.4.2 have the same title.=20 This was a mistake; the second one should just be =E2=80=9CJMAP Enum Sub= registry Template=E2=80=9D. > Section 8.4 is unusual, as we haven't run into the idea of a template = for a new subregistry. >=20 > We may have some presentation issues. We can't leave the subregistry n= ame field blank, and it may not be possible to create additional fields = at the top of the registry for Property Name, Property Context, and Chan= ge Controller, except within the context of a "Note:" field that appears= after the registry reference. Even if the presentation in the document = doesn't change, would it be possible to use a registry naming scheme tha= t captures the property name and context, after which we could add the c= hange controller information in a note? For example, would something lik= e this work?=20 >=20 > Registry Name: Enum Values for freeBusyStatus Property (Contexts: JSEv= ent, JSTask) > Reference: [this document] > Registration Procedure: Expert Review > Expert(s): [expert names] > Note: > Change Controller: IETF I think this would be OK. I guess my main questions is can a new subregi= stry be added without an RFC (i.e. just by submitting to IANA the new su= bregistry template)? The scenario I'm thinking of is someone adds a new = simple enumerable property and so needs a new subregistry. > One more question: Section 8.4.1 says that the IETF is the change cont= roller for Standards Track / BCP RFCs, but would the IETF not be the cha= nge controller for any IETF-stream RFC? Yes, they probably should be. I've changed that. I have published a new draft with the above changes for review. Many thanks, Neil. --29d2d18fdcd54a00832f809e51f3223f Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Sorry for = the delay responding.

About the statement that "The IANA will list common-use r= egistrations prominently and separately from those with other intended u= se values": would listing common-use values first be sufficient, or woul= d you want the registry divided into three separate registries? 

Listing common-use values first = is fine, no need for separate registries.

The registration procedure for common= use registrations is described as Specification Required (it might be h= elpful to capitalize the registration procedures and cite RFC 8126),

I will capitalise Specification = Required. RFC 8126 is referenced in Section 8.2.3 describing the ex= pert review, but I will add another reference here too.
but in the template, th= e reference field is named "RFC Reference." On the other hand, if the st= atement in Section 8.2.3 that "for simple definitions a description in t= he registry may be sufficient" refers to the Specification Required rang= e, I wonder if it could be more appropriate to describe the registration= procedure for that range as Expert Review and have us add a note that s= ays something like "RFC preferred." The registration procedures for all = three ranges (common, reserved, obsolete) could be presented in a table = like the ones at https= ://www.iana.org/assignments/cose, with the addition of a "Notes" fie= ld to expand on the requirements/expectations for common-use submissions= .

I have changed this to "Refe= rence or Description", defined as =E2=80=9CA brief description or RFC nu= mber and section reference where the property is specified=E2=80=9D.
=

While we could make it Expert Review, I think = Specification Required is still correct, because we want to ensure there= is sufficient documentation for interoperability. It's just sometimes a= single sentence is sufficient, and to make it easy to update we'd like = to just be able to put that straight in the registry rather than require= a separate document.

Does that sound reaso= nable, or would you still prefer something different?

=
The problem is that a des= cription in the registry may not fit the description of Specification Re= quired defined in Section 4.6 of RFC 8126:
Reading this again, I can't see anything in it that prohibi= ts the specification being included in the registry entry itself.

Sections 8.4.= 1 and 8.4.2 have the same title.

<= div>This was a mistake; the second one should just be =E2=80=9CJMAP Enum= Subregistry Template=E2=80=9D.

Section 8.4 is unusual, as we haven't run into = the idea of a template for a new subregistry.

We may have some presentation issues. We can't leave the subregistry = name field blank, and it may not be possible to create additional fields= at the top of the registry for Property Name, Property Context, and Cha= nge Controller, except within the context of a "Note:" field that appear= s after the registry reference. Even if the presentation in the document= doesn't change, would it be possible to use a registry naming scheme th= at captures the property name and context, after which we could add the = change controller information in a note? For example, would something li= ke this work? 

Registry Name: Enum Val= ues for freeBusyStatus Property (Contexts: JSEvent, JSTask)
Reference: [this document]
Registration Procedure: Exper= t Review
Expert(s): [expert names]
Note:
=
Change Controller: IETF

=
I think this would be OK. I guess my main questions is can a new su= bregistry be added without an RFC (i.e. just by submitting to IANA the n= ew subregistry template)? The scenario I'm thinking of is someone adds a= new simple enumerable property and so needs a new subregistry.

One more questi= on: Section 8.4.1 says that the IETF is the change controller for Standa= rds Track / BCP RFCs, but would the IETF not be the change controller fo= r any IETF-stream RFC?

Yes, th= ey probably should be. I've changed that.

I= have published a new draft with the above changes for review.

Many thanks,
Neil.
--29d2d18fdcd54a00832f809e51f3223f--