Return-Path: X-Original-To: auth48archive@mail2.ietf.org Delivered-To: auth48archive@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id B5B00E8B73CF; Mon, 4 May 2026 06:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1777899645; bh=TwAqqMiLpY4KVG3B4DjoGJandWKv33s4W8/uYTaab6U=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=woQ4Okyzk/LnnmCn23u+w8Hcnjlw7aKzT1lNLYkdq0PbN6DUz5GfiKA3E6vUon6lK X+zN/F3NOP2WKA33Kb2DpwcETrtz5cz8ubp9LjlLVH6R7OSbysHwrQYvFE2nJHGJY8 M4dTtfn4DtptgEvQq/caPVWSBAuRLDZihWuJ+I14= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -11.885 X-Spam-Level: X-Spam-Status: No, score=-11.885 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=cisco.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCaDSU1v16sg; Mon, 4 May 2026 06:00:44 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id D7E74E8B5B03; Mon, 4 May 2026 05:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=47633; q=dns/txt; s=iport01; t=1777899592; x=1779109192; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=DOJ+8wy4VbIn3InLC3VMytILFRfv94SbbC/XRP7xXQg=; b=Z5+/QQ2aPoGjhm/1c992ZTsv0k9PvEezC8tLuu3Gjyh0jghfleTLVtGw Gn7RSA+Ll7n4N6C8NMBaekylzKIDDbNSTTnsiodklIOkNjAwZTelYHIUm CAjBe2xPO47IG7xXAj0iMv+1qvjE9qWkHNL0+BxEsnlQ0uhfw3YTO+7QG Ob9h8iR/jkdUcuIt/Z12Cb+mX6dvILjYKXd4EnKNcEowg/bYL8bn7RWT7 vF1V+20VAhbVoohFhDRY0w7sTuUn3dpxwLfgP0vwKUnhTcWiXdKQqKUaj zwVM/IE5vaf7xUU9VG1VK87+IolIDyedqMxEYuVL6tyXuyLEg9ud2nv1s g==; X-CSE-ConnectionGUID: 3mNRU6uOQqmwtIhDAgl7Tg== X-CSE-MsgGUID: GWRAWGgMRbuZGiETSdHk6A== X-IPAS-Result: =?us-ascii?q?A0CQAAAsl/hp/5UQJK1QAQkODAEBAQEBAQEBAQEDAQEBA?= =?us-ascii?q?RIBAQEBAgIBAQEBghACg0ZeQ0mEGzyPU4IhA4tkhWaMZIFrDAMBAQEPPRQEA?= =?us-ascii?q?QGBcQGDFAKNMQImOBMBAgQBAQEBAwIDAQEBAQEBAQEBAQELAQEFAQEBAgEHB?= =?us-ascii?q?YEOE4ZPDUkBEAGFfwEBAQEBAQEMDgEIVgULCQIMAgogAQYDAgIgJREGE4MCA?= =?us-ascii?q?YI6Aw8nAxEGmieadQFOeoEygQGEfdhIDYJYBhQwgQkBiDcgASqBNQOCBoIOh?= =?us-ascii?q?HonG4INgRUnCxBHCoIXPoIfQgOBMgEDD4N1OoIvBIINFXoUgX58gmeJMkgKY?= =?us-ascii?q?hAiAyYzLAFVEw0KCwcFgSNDAzUSKhUjSwUtHYEjIR0XFR9YGwcFEiEqbmt0L?= =?us-ascii?q?FwaDiEkEVlCOAtJBYFyAoIeGV8jLwNOcgMLGA1IESwUIxQbBD5uB4l/XR0Pg?= =?us-ascii?q?T0BCWIGPiYEKAcDHwIgLyQSBQ5HCRoCBQoBOiyKF4t9jHGOGJNkQnGEJoRwh?= =?us-ascii?q?y6PPoYWBC+EBI0ThwKLC4N3gmlniAqQfIJYizGECZFeDA0BUIRngX8lgVkzG?= =?us-ascii?q?ggbFWUBgjw/FBkPjl+DRIUTiiG6DkQyAjsCBwIHDQMLi2WGA4EdYAEB?= IronPort-Data: A9a23:l4s5vqOQT/NikvvvrR1GlsFynXyQoLVcMsEvi/4bfWQNrUoq1GYFm mtND2yGa/yJazb0e9wiPoji80oEvJbXx9ViGXM5pCpnJ55oRWUpJjg4wmPYZX76whjrFRo/h ykmQoCeaphyFTmE+kvF3oHJ9RFUzbuPSqf3FNnKMyVwQR4MYCo6gHqPocZh6mJTqYb/WVjlV e/a+ZWFZgf4g2Isawr41orawP9RlKWq0N8nlgRWicBj5Df2i3QTBZQDEqC9R1OQapVUBOOzW 9HYx7i/+G7Dlz91Yj9yuu+mGqGiaue60Tmm0hK6aYD76vRxjnBaPpIACRYpQRw/ZwNlMDxG4 I4lWZSYEW/FN0BX8QgXe0Ew/ypWZcWq9FJbSJSymZT78qHIT5fj665rKnsLY5A/w/9yHn1v9 dAxJzRSUh/W0opawJrjIgVtrs0nKM+uOMYUvWttiGiDS/0nWpvEBa7N4Le03h9p2ZsIRqiYP pRfMGY+BPjDS0Un1lM/DJ83hs+jh2L0dHtTr1f9Sa8fvzeDk1QqgOe0WDbTUvO1f+xqsUm9n GjbzUv4Ly0hOPyclxPQpxpAgceKx0sXQrk6GLCy/flthFCCn0QcDRQXUR2wpvzRok63QMlWL U0N8CMq/PNr3EOuR9j5GRa/pRaspRUdXp9ZH/YS6QyRxOzT+QnxLnMPTzsEY9wvtdUtbT0ny lHPmMnmbRRqq72cSWCU3rGfti70NCQIRUcLeDMEEVsM+dLjoZ8+pgjBRZNuHK+picezHiv/q xiQoiN7irkSkckR/7+19hXKjzOwoYKPSRQ6ji3UUGWi4hJRf5KsaYLu81bQqPtMLZqeVB+Gp ndspiSFxOkKCZfIkGmGR/8AWejzof2EKzbbx1VoGvHN6giQxpJqRqgIiBkWGaujGp9slePBC KMLhT5s2Q== IronPort-HdrOrdr: A9a23:GvIba6FCpQUEloRApLqEyMeALOsnbusQ8zAXPo5KOH9om62j+/ xG88576faZslwssTQb+exoRpPsfZqsz/FICOAqVN/IYOClghrMEGgI1+XfKlPbak/DH5ZmpM NdWpk7LsHsBl5nisu/ygy5H9E8hOSjysmT9IDjJ7MHd3ASV0mmhD0JbDqmLg== X-Talos-CUID: =?us-ascii?q?9a23=3AcUU7imkJhA+ge2OcHs1UAMBzRxnXOSbY6k3tfVK?= =?us-ascii?q?fMH9sV6G0SXO596c7r8U7zg=3D=3D?= X-Talos-MUID: 9a23:w7t7dwoG2SIc73UW4m0ezx5dDu5XzKuLMkoQo7oHlvW/OQxzZR7I2Q== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="6.23,215,1770595200"; d="scan'208,217";a="478703871" Received: from alln-l-core-12.cisco.com ([173.36.16.149]) by rcdn-iport-3.cisco.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 04 May 2026 12:59:45 +0000 Received: from smtpclient.apple (unknown [10.168.8.195]) by alln-l-core-12.cisco.com (Postfix) with ESMTP id DD2DA18000B28; Mon, 4 May 2026 12:59:42 +0000 (GMT) From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AC615E83-EB13-4864-940E-0D2FBB24020E" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\)) Date: Mon, 4 May 2026 14:59:31 +0200 In-Reply-To: To: Muhammad Shahzad References: <00E7EF1E-ABB9-4D6A-88AD-CD1583847528@staff.rfc-editor.org> <00DE5A64-6BB1-4127-92F2-01A0A4A76747@cisco.com> <0CFF8AD7-2612-45C2-87CC-033CE2492A98@cisco.com> X-Mailer: Apple Mail (2.3864.500.181) X-Outbound-Client-TLS: NONE;unknown [10.168.8.195] X-Outbound-SMTP-Client: 10.168.8.195, [10.168.8.195] X-Outbound-Node: alln-l-core-12.cisco.com Message-ID-Hash: RQ4MP5KVH62I3JD5HETX6JBVWE7OIM42 X-Message-ID-Hash: RQ4MP5KVH62I3JD5HETX6JBVWE7OIM42 X-MailFrom: lear@cisco.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Kaelin Foody , Deb Cooley , rfc-editor@rfc-editor.org, "Nancy Cam-Winget (ncamwing)" , auth48archive@rfc-editor.org, scim-ads@ietf.org, scim-chairs@ietf.org, Hassan X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bauth48=5D_Re=3A_=5BAD=5D_AUTH48=3A_RFC-to-be_9944_=3Cdraft-ietf?= =?utf-8?q?-scim-device-model-18=3E_for_your_review?= List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_AC615E83-EB13-4864-940E-0D2FBB24020E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As do I. Thank you all. Eliot > On 4 May 2026, at 14:42, Muhammad Shahzad wrote: >=20 > Hi All, >=20 > I approve this. Thank you >=20 > -- > Muhammad Shahzad=20 >=20 > On Mon, May 4, 2026, 8:38=E2=80=AFAM Kaelin Foody = > = wrote: >> Hi *Deb, Eliot, >>=20 >> *Deb - We have updated the text per Eliot=E2=80=99s most recent = reply, but it seems no further changes are desired here. Please review = and let us know if the current set of updates are acceptable. Please see = https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html. >>=20 >> Eliot - We have updated the files as requested. Please review and let = us know if any additional updates are needed or if you approve the RFC = for publication. >>=20 >> We will request that IANA make their relevant changes after we = receive all other approvals listed on the AUTH48 status page. >>=20 >> The AUTH48 status page for this document is available here: >> https://www.rfc-editor.org/auth48/rfc9944 >>=20 >> =E2=80=94 FILES (please refresh): =E2=80=94 >>=20 >> The updated files have been posted here: >> https://www.rfc-editor.org/authors/rfc9944.txt >> https://www.rfc-editor.org/authors/rfc9944.pdf >> https://www.rfc-editor.org/authors/rfc9944.html >> https://www.rfc-editor.org/authors/rfc9944.xml >>=20 >> Diff files showing changes between the last and current version: >> https://www.rfc-editor.org/authors/rfc9944-lastdiff.html >> https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html (side by = side) >>=20 >> Diff files showing changes made during AUTH48: >> https://www.rfc-editor.org/authors/rfc9944-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9944-auth48rfcdiff.html (side = by side) >>=20 >> Diff files showing all changes: >> https://www.rfc-editor.org/authors/rfc9944-diff.html >> https://www.rfc-editor.org/authors/rfc9944-rfcdiff.html (side by = side) >>=20 >> Thank you, >>=20 >> Kaelin Foody >> RFC Production Center >>=20 >> > On Apr 27, 2026, at 2:57=E2=80=AFAM, Eliot Lear > wrote: >> >=20 >> > Ok. I=E2=80=99m back, tanned, with much more knowledge of the = Greek Mycenaean and Archaic periods, and raring to go. I=E2=80=99ve = reviewed the diffs and I want to also address Deb=E2=80=99s points. >> >=20 >> > First, about =E2=80=9Cread-only=E2=80=9D and =E2=80=9Cimmutable=E2=80= =9D. This is an artifact of RFC 7643. =E2=80=9CRead-only=E2=80=9D = means just that. =E2=80=9CImmutable=E2=80=9D means it can be written = once. >> >=20 >> > Second, everywhere in the draft, the term should be =E2=80=9Cread-onl= y=E2=80=9D not =E2=80=9Cread only=E2=80=9D (this is a regression). Case = can remain as is. >> >=20 >> > Finally: >> >=20 >> >=20 >> >=20 >> >> On 23 Apr 2026, at 06:52, Kaelin Foody = > = wrote: >> >>=20 >> >>=20 >> >>> b) Should the update below be implemented? >> >>>=20 >> >>> Appendix B.6:=20 >> >>> Two additional instances of =E2=80=9C...:Devices=E2=80=9D = (plural) appear in this section. Should these instances be updated to = =E2=80=9C:Device=E2=80=9D (singular) as well? >> >=20 >> >=20 >> > Yes, please. >> >=20 >> > Regards, >> >=20 >> > Eliot >> >=20 >> >>=20 >> >> We will request that IANA make their relevant changes after we = receive all other approvals listed on the AUTH48 status page. >> >>=20 >> >> All best, >> >>=20 >> >> Kaelin Foody >> >> RFC Production Center >> >>=20 >> >>> On Apr 17, 2026, at 7:02=E2=80=AFAM, Hassan = > wrote: >> >>>=20 >> >>> Hi Kaelin, >> >>>=20 >> >>> Thank you for the updates. Approved from my end. >> >>>=20 >> >>> On Tue, Apr 14, 2026 at 4:32=E2=80=AFPM Kaelin Foody = > = wrote: >> >>> Hi Eliot, >> >>>=20 >> >>> Thanks for your reply and letting us know you will be out of = office -- we will wait on your reply accordingly.=20 >> >>>=20 >> >>> We have updated the files and Section 6.3.1 as requested. Please = review the two matters below at your convenience: >> >>>=20 >> >>> a) For the item below, we have removed a space from the left = margin for both the =E2=80=9Clocation=E2=80=9D line (seen below) and for = the =E2=80=9CresourceType=E2=80=9D line that follows it, to preserve = original indentation. Please review this update in Appendix A.1 for = correctness.=20 >> >>>=20 >> >>>>> Appendix A.1:=20 >> >>>>> We have updated this line per item #6, but it is now one = character too long. Please review and let us know where to insert a line = break for the line below: >> >>>>>=20 >> >>>>> "location": = "https://example.com/v2/ResourceTypes/EndpointApps=E2=80=9D, >> >>>>=20 >> >>>> I think you can just indent one space. >> >>>=20 >> >>>=20 >> >>> b) Should the update below be implemented? >> >>>=20 >> >>>>> Appendix B.6:=20 >> >>>>> Two additional instances of =E2=80=9C...:Devices=E2=80=9D = (plural) appear in this section. Should these instances be updated to = =E2=80=9C:Device=E2=80=9D (singular) as well? >> >>>=20 >> >>>=20 >> >>> Please review the items above and let us know if there are any = outstanding updates remaining. >> >>>=20 >> >>> The AUTH48 status page for this document is available here: >> >>> https://www.rfc-editor.org/auth48/rfc9944 >> >>>=20 >> >>> =E2=80=94 FILES (please refresh): =E2=80=94 >> >>>=20 >> >>> The updated files have been posted here: >> >>> https://www.rfc-editor.org/authors/rfc9944.txt >> >>> https://www.rfc-editor.org/authors/rfc9944.pdf >> >>> https://www.rfc-editor.org/authors/rfc9944.html >> >>> https://www.rfc-editor.org/authors/rfc9944.xml >> >>>=20 >> >>> Diff files showing changes between the last and current version: >> >>> https://www.rfc-editor.org/authors/rfc9944-lastdiff.html >> >>> https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html (side = by side) >> >>>=20 >> >>> Diff files showing changes made during AUTH48: >> >>> https://www.rfc-editor.org/authors/rfc9944-auth48diff.html >> >>> https://www.rfc-editor.org/authors/rfc9944-auth48rfcdiff.html = (side by side) >> >>>=20 >> >>> Diff files showing all changes: >> >>> https://www.rfc-editor.org/authors/rfc9944-diff.html >> >>> https://www.rfc-editor.org/authors/rfc9944-rfcdiff.html (side by = side) >> >>>=20 >> >>> All the best, >> >>>=20 >> >>> Kaelin Foody >> >>> RFC Production Center >> >>>=20 >> >>> On Apr 11, 2026, at 5:51=E2=80=AFAM, Eliot Lear > wrote: >> >>>>=20 >> >>>> Hi Kaelin, >> >>>>=20 >> >>>> Below are my answers. Please be advised, I=E2=80=99m going on = two weeks of holiday and will have a limited ability to respond or = review changes. Also see below for the one remaining other issue which = is mildly substantial but hopefully not controversial. >> >>>>=20 >> >>>>=20 >> >>>>> On 9 Apr 2026, at 20:23, Kaelin Foody = > = wrote: >> >>>>>=20 >> >>>>> Hi Eliot, all, >> >>>>>=20 >> >>>>> We have updated the files as requested. These updates are best = viewed here: = https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html. >> >>>>>=20 >> >>>>> A few follow-up questions regarding these updates: >> >>>>>=20 >> >>>>> a) Section 6.3.1, Table 2: >> >>>>> We have updated this table accordingly. May we also add a value = for =E2=80=9CImm=E2=80=9D in the legend that appears after this table? >> >>>>>=20 >> >>>>> Perhaps: >> >>>>> Imm =3D Immutable >> >>>>=20 >> >>>> Yes. >> >>>>=20 >> >>>>>=20 >> >>>>> b) Section 7.6.2, Table 8:=20 >> >>>>> In the =E2=80=9CMutable=E2=80=9D column of this table, should = the $ref attribute=E2=80=99s value be updated from =E2=80=9CR=E2=80=9D = to =E2=80=9CRO=E2=80=9D as well (to match the updates made to = devContEntEndpoint and telEntEndpoint)? >> >>>>=20 >> >>>> Yes. >> >>>>=20 >> >>>>>=20 >> >>>>> c) Appendix A.1:=20 >> >>>>> We have updated this line per item #6, but it is now one = character too long. Please review and let us know where to insert a line = break for the line below: >> >>>>>=20 >> >>>>> "location": = "https://example.com/v2/ResourceTypes/EndpointApps=E2=80=9D, >> >>>>=20 >> >>>> I think you can just indent one space. >> >>>>=20 >> >>>>>=20 >> >>>>> d) Appendix B.6:=20 >> >>>>> Two additional instances of =E2=80=9C...:Devices=E2=80=9D = (plural) appear in this section. Should these instances be updated to = =E2=80=9C:Device=E2=80=9D (singular) as well? >> >>>>>=20 >> >>>>> We will request that IANA make their relevant changes and = request AD approval after we receive your remaining updates. >> >>>>=20 >> >>>>=20 >> >>>>=20 >> >>>> In Section 6.3.1, we wrote: >> >>>>=20 >> >>>> OLD: >> >>>>=20 >> >>>>> subjectName:When present, a string that contains one of two = names=E2=80=A6 >> >>>>=20 >> >>>> If certificateInfo is present then subjectName must be present. = Otherwise we haven=E2=80=99t given sufficient implementation guidance on = how to identify a valid identity. Therefore, the proposed change is: >> >>>>=20 >> >>>> NEW: >> >>>>=20 >> >>>>> subjectName:A string that contains one of two names >> >>>>=20 >> >>>> The table already indicates that subjectName is required, as = does the JSON OpenAPI. >> >>>>=20 >> >>>> This got missed in earlier review because people (including = myself) may have been thinking about whether the parent object was = present. >> >>>>=20 >> >>>> Regards, >> >>>>=20 >> >>>> Eliot >> >>>>=20 >> >>>>=20 >> >>>>=20 >> >>>>>=20 >> >>>>> The AUTH48 status page for this document is available here: >> >>>>> https://www.rfc-editor.org/auth48/rfc9944 >> >>>>>=20 >> >>>>> =E2=80=94 FILES (please refresh): =E2=80=94 >> >>>>>=20 >> >>>>> The updated files have been posted here: >> >>>>> https://www.rfc-editor.org/authors/rfc9944.txt >> >>>>> https://www.rfc-editor.org/authors/rfc9944.pdf >> >>>>> https://www.rfc-editor.org/authors/rfc9944.html >> >>>>> https://www.rfc-editor.org/authors/rfc9944.xml >> >>>>>=20 >> >>>>> Diff files showing changes between the last and current = version: >> >>>>> https://www.rfc-editor.org/authors/rfc9944-lastdiff.html >> >>>>> https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html = (side by side) >> >>>>>=20 >> >>>>> Diff files showing changes made during AUTH48: >> >>>>> https://www.rfc-editor.org/authors/rfc9944-auth48diff.html >> >>>>> https://www.rfc-editor.org/authors/rfc9944-auth48rfcdiff.html = (side by side) >> >>>>>=20 >> >>>>> Diff files showing all changes: >> >>>>> https://www.rfc-editor.org/authors/rfc9944-diff.html >> >>>>> https://www.rfc-editor.org/authors/rfc9944-rfcdiff.html (side = by side) >> >>>>>=20 >> >>>>> All best, >> >>>>>=20 >> >>>>> Kaelin Foody >> >>>>> RFC Production Center >> >>>>>=20 >> >>>>>> On Apr 7, 2026, at 1:45=E2=80=AFPM, Eliot Lear > wrote: >> >>>>>>=20 >> >>>>>> Hi Kaelin >> >>>>>>=20 >> >>>>>> Hassan identified a number of typos and omissions in his = review. Some of these will need IANA review, as there are several = entries missing. All of these, I think, are non-controversial edits. >> >>>>>>=20 >> >>>>>> There is one exception that we will come back to after this = one. It=E2=80=99s not that it=E2=80=99s controversial, but it is a = substantive change. >> >>>>>>=20 >> >>>>>> Eliot >> >>>>>> 1. Section 7.4.1, Figure 10 (FDO Example) =E2=80=94 schema = URIs in JSON >> >>>>>> OLD: urn:ietf:params:scim:schemas:core:2.0:Devices and = urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Devices >> >>>>>> NEW: urn:ietf:params:scim:schemas:core:2.0:Device and = urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Device >> >>>>>> 2. Appendix A.7, FDO Extension JSON Schema =E2=80=94 id and = meta.location use plural "Devices" >> >>>>>> OLD: "id": = "urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Devices" = and "location": "...fido-device-onboard:2.0:Devices" >> >>>>>> NEW: "id": = "urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Device" = and "location": "...fido-device-onboard:2.0:Device" >> >>>>>> 3. Section 7.5.1, Zigbee deviceEui64Address description >> >>>>>> OLD: "takes the same form as the deviceMACaddress" >> >>>>>> NEW: "takes the same form as the deviceMacAddress " >> >>>>>> 4. Section 7.6.2, description of $ref attribute >> >>>>>> OLD: "EndointApp" >> >>>>>> NEW: "EndpointApp" >> >>>>>> 5. Appendix A.1, Resource Schema =E2=80=94 EndpointApp = endpoint path >> >>>>>> OLD: "endpoint": "/EndpointApp" >> >>>>>> NEW: "endpoint": "/EndpointApps" 6. OLD: "location": = "https://example.com/v2/ResourceTypes/EndpointApp", >> >>>>>> NEW: "location": = "https://example.com/v2/ResourceTypes/EndpointApps", 7. Appendix A.3, = EndpointApp Schema meta.location >> >>>>>> OLD: = "/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:Device" >> >>>>>> NEW: = "/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:EndpointApp" 8. = Appendix A.4, in schema with ID = "urn:ietf:params:scim:schemas:extension:pairingOOB:2.0:Device", >> >>>>>> OLD: "description": "Passkey pairing method for BLE." >> >>>>>> NEW: "description": "Out-of-band pairing method for BLE." >> >>>>>> 9. Appendix A.4, BLE Extension JSON Schema =E2=80=94 mobility = type >> >>>>>> OLD: "type": "bool" >> >>>>>> NEW: "type": "boolean" >> >>>>>> 10. [We=E2=80=99ll come back to this one] >> >>>>>> 11. Section 6.3.1, Table 2 =E2=80=94 clientToken Return column >> >>>>>> OLD: Return =3D N >> >>>>>> New: Return =3D Def >> >>>>>> 12. Section 7.1.3, Table 3 =E2=80=94 isRandom Required column >> >>>>>> OLD: Req =3D T >> >>>>>> NEW: Req =3D F >> >>>>>> 13. Section 7.2.1, prose description of bootstrapKey >> >>>>>> OLD: "This attribute is required, case sensitive, mutable, and = returned by default." >> >>>>>> NEW: "This attribute is required, case sensitive, write only, = and never returned." >> >>>>>> 14. Section 9.2, IANA registrations for BLE pairing method = extensions (pairingNull) =E2=80=94 missing entry >> >>>>>> NEW: >> >>>>>> Schema URI: = urn:ietf:params:scim:schemas:extension:pairingNull:2.0:Device >> >>>>>> Name: Pairing Null >> >>>>>> Resource Type: Device >> >>>>>> Reference: RFC 9944, Section 7.1.3 >> >>>>>> 15. Section 9.2, IANA registrations for Zigbee =E2=80=94 = missing entry >> >>>>>> NEW: >> >>>>>> Schema URI: = urn:ietf:params:scim:schemas:extension:zigbee:2.0:Device >> >>>>>> Name: Zigbee >> >>>>>> Resource Type: Device >> >>>>>> Reference: RFC 9944, Section 7.5 >> >>>>>> 16. Section 9.2, IANA registration for = urn:ietf:params:scim:schemas:extension:endpointAppsExt:2.0:Device =E2=80=94= Reference >> >>>>>> OLD: RFC 9944, Section 7.1.3 >> >>>>>> NEW: RFC 9944, Section 7.6 >> >>>>>> 17. Appendix A.4, BLE Extension JSON Schema =E2=80=94 irk = mutability and returned fields >> >>>>>> OLD: "mutability": "readWrite", "returned": "default" >> >>>>>> NEW: "mutability": "writeOnly", "returned": "never" >> >>>>>> 18. Appendix A.4, pairingJustWorks schema =E2=80=94 key = attribute >> >>>>>> OLD: "required": true >> >>>>>> NEW: "required": false >> >>>>>> 19. Appendix A.7, FDO Extension JSON Schema =E2=80=94 = fdoVoucher mutability and returned fields >> >>>>>> OLD: "mutability": "readWrite", "returned": "default" >> >>>>>> NEW: "mutability": "writeOnly", "returned": "never" >> >>>>>> 0a. Section 6.3.1, Table 2 =E2=80=94 clientToken >> >>>>>> For applicationType: >> >>>>>> OLD: Mutable =3D R >> >>>>>> NEW: Mutable =3D RO >> >>>>>> 20b. Section 6.2, prose description of applicationType >> >>>>>> OLD: "The attribute is required and is not case sensitive. The = attribute is readOnly and should be returned by default." >> >>>>>> NEW: "The attribute is required and is not case sensitive. The = attribute is immutable and should be returned by default." >> >>>>>> 20c. Section 6.3.1, Table 2 =E2=80=94 applicationType Mutable = column >> >>>>>> OLD: Mutable =3D R >> >>>>>> NEW: Mutable =3D Imm >> >>>>>> 21. Section 7.6.2, Table 8 =E2=80=94 devContEntEndpoint and = telEntEndpoint=20 >> >>>>>> For devContEntEndpoint:=20 >> >>>>>> OLD: Mutable =3D R >> >>>>>> NEW: Mutable =3D RO >> >>>>>> For telEntEndpoint:=20 >> >>>>>> OLD: Mutable =3D R >> >>>>>> NEW: Mutable =3D RO >> >>>>>> 22. Section 7.6.1, prose description of = deviceControlEnterpriseEndpoint >> >>>>>> OLD: "This attribute is required, case sensitive, mutable, and = returned by default." >> >>>>>> NEW: "This attribute is required, case sensitive, read-only, = and returned by default." >> >>>>>> 23. Section 7.6.1, prose description of = telemetryEnterpriseEndpoint >> >>>>>> OLD: "This attribute is optional, case sensitive, mutable, and = returned by default." >> >>>>>> NEW: "This attribute is optional, case sensitive, read-only, = and returned by default." >> >>>>>> 24. Section 7.6.2, Table 8 =E2=80=94 $ref >> >>>>>> OLD: $ref row Case Exact =3D F >> >>>>>> NEW: $ref row Case Exact =3D T >> >>>>>> 25. Appendix A.5, DPP Extension Schema =E2=80=94 bootstrapKey >> >>>>>> OLD: "mutability": "readWrite", "returned": "default" >> >>>>>> NEW: "mutability": "writeOnly", "returned": "never" >> >>>>>> 26. [We=E2=80=99ll come back to this one] >> >>>>>> 27. [deleted] >> >>>>>> 28. Section 6.3.1, Table 2 =E2=80=94 missing groups attribute = row >> >>>>>> OLD: (no groups row in Table 2) >> >>>>>> NEW: Add row groups | T | F | T | RO | Def | n/a >> >>>>>> 29. Appendix A.9, endpointAppsExt Extension Schema =E2=80=94 = $ref sub-attribute required >> >>>>>> OLD: "required": false >> >>>>>> NEW: "required": true >> >>>>>> 30. Section 7.1.3, prose =E2=80=94 incorrect cross-reference = to Section 6.1 >> >>>>>> OLD: "Each extension contains the common attributes in Section = 6.1." >> >>>>>> NEW: "Each extension contains the common attributes in Section = 2.1." >> >>>>>>=20 >> >>>>>=20 >> >>>>=20 >> >>>=20 >> >>>=20 >> >>>=20 >> >>> --=20 >> >>> -- >> >>> Best >> >>> Hassan Iqbal >> >>=20 >> >=20 >>=20 --Apple-Mail=_AC615E83-EB13-4864-940E-0D2FBB24020E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As do I.

Thank you = all.

Eliot

On 4 May 2026, at 14:42, Muhammad Shahzad = <mshahza@ncsu.edu> wrote:

Hi All,

I approve this. Thank = you

--
Muhammad Shahzad 

On Mon, May 4, 2026, 8:38=E2=80=AFAM Kaelin Foody = <kfoody@staff.rfc-editor.org> wrote:
Hi *Deb, = Eliot,

*Deb - We have updated the text per Eliot=E2=80=99s most recent reply, = but it seems no further changes are desired here. Please review and let = us know if the current set of updates are acceptable. Please see https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.h= tml.

Eliot - We have updated the files as requested. Please review and let us = know if any additional updates are needed or if you approve the RFC for = publication.

We will request that IANA make their relevant changes after we receive = all other approvals listed on the AUTH48 status page.

The AUTH48 status page for this document is available here:
https://www.rfc-editor.org/auth48/rfc9944

=E2=80=94 FILES (please refresh): =E2=80=94

The updated files have been posted here:
https://www.rfc-editor.org/authors/rfc9944.txt
https://www.rfc-editor.org/authors/rfc9944.pdf
https://www.rfc-editor.org/authors/rfc9944.html
https://www.rfc-editor.org/authors/rfc9944.xml

Diff files showing changes between the last and current version:
https://www.rfc-editor.org/authors/rfc9944-lastdiff.html=
https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.h= tml (side by side)

Diff files showing changes made during AUTH48:
https://www.rfc-editor.org/authors/rfc9944-auth48diff.ht= ml
https://www.rfc-editor.org/authors/rfc9944-auth48rfcdiff= .html (side by side)

Diff files showing all changes:
https://www.rfc-editor.org/authors/rfc9944-diff.html=
https://www.rfc-editor.org/authors/rfc9944-rfcdiff.html<= /a> (side by side)

Thank you,

Kaelin Foody
RFC Production Center

> On Apr 27, 2026, at 2:57=E2=80=AFAM, Eliot Lear <lear@cisco.com> wrote:
>
> Ok.  I=E2=80=99m back, tanned, with much more knowledge of the = Greek Mycenaean and Archaic periods, and raring to go.  I=E2=80=99ve = reviewed the diffs and I want to also address Deb=E2=80=99s points.
>
> First, about =E2=80=9Cread-only=E2=80=9D and =E2=80=9Cimmutable=E2=80= =9D.  This is an artifact of RFC 7643.  =E2=80=9CRead-only=E2=80= =9D means just that.  =E2=80=9CImmutable=E2=80=9D means it can be = written once.
>
> Second, everywhere in the draft, the term should be =E2=80=9Cread-onl= y=E2=80=9D not =E2=80=9Cread only=E2=80=9D (this is a regression).  = Case can remain as is.
>
> Finally:
>
>
>
>> On 23 Apr 2026, at 06:52, Kaelin Foody <kfoody@staff.rfc-editor.org> wrote:
>>
>>
>>> b) Should the update below be implemented?
>>>
>>> Appendix B.6:
>>> Two additional instances of =E2=80=9C...:Devices=E2=80=9D = (plural) appear in this section. Should these instances be updated to = =E2=80=9C:Device=E2=80=9D (singular) as well?
>
>
> Yes, please.
>
> Regards,
>
> Eliot
>
>>
>> We will request that IANA make their relevant changes after we = receive all other approvals listed on the AUTH48 status page.
>>
>> All best,
>>
>> Kaelin Foody
>> RFC Production Center
>>
>>> On Apr 17, 2026, at 7:02=E2=80=AFAM, Hassan <hassaniqbal931@gmail.com> wrote:
>>>
>>> Hi Kaelin,
>>>
>>> Thank you for the updates. Approved from my end.
>>>
>>> On Tue, Apr 14, 2026 at 4:32=E2=80=AFPM Kaelin Foody <kfoody@staff.rfc-editor.org> wrote:
>>> Hi Eliot,
>>>
>>> Thanks for your reply and letting us know you will be out = of office -- we will wait on your reply accordingly.
>>>
>>> We have updated the files and Section 6.3.1 as requested. = Please review the two matters below at your convenience:
>>>
>>> a) For the item below, we have removed a space from the = left margin for both the =E2=80=9Clocation=E2=80=9D line (seen below) = and for the =E2=80=9CresourceType=E2=80=9D line that follows it, to = preserve original indentation. Please review this update in Appendix A.1 = for correctness.
>>>
>>>>> Appendix A.1:
>>>>> We have updated this line per item #6, but it is = now one character too long. Please review and let us know where to = insert a line break for the line below:
>>>>>
>>>>>  "location": "https://example.com/v2/ResourceTypes/EndpointApps=E2= =80=9D,
>>>>
>>>> I think you can just indent one space.
>>>
>>>
>>> b) Should the update below be implemented?
>>>
>>>>> Appendix B.6:
>>>>> Two additional instances of =E2=80=9C...:Devices=E2=80= =9D (plural) appear in this section. Should these instances be updated = to =E2=80=9C:Device=E2=80=9D (singular) as well?
>>>
>>>
>>> Please review the items above and let us know if there are = any outstanding updates remaining.
>>>
>>> The AUTH48 status page for this document is available = here:
>>> https://www.rfc-editor.org/auth48/rfc9944
>>>
>>> =E2=80=94 FILES (please refresh): =E2=80=94
>>>
>>> The updated files have been posted here:
>>> https://www.rfc-editor.org/authors/rfc9944.txt
>>> https://www.rfc-editor.org/authors/rfc9944.pdf
>>> https://www.rfc-editor.org/authors/rfc9944.html
>>> https://www.rfc-editor.org/authors/rfc9944.xml
>>>
>>> Diff files showing changes between the last and current = version:
>>> https://www.rfc-editor.org/authors/rfc9944-lastdiff.html=
>>> https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.h= tml (side by side)
>>>
>>> Diff files showing changes made during AUTH48:
>>> https://www.rfc-editor.org/authors/rfc9944-auth48diff.ht= ml
>>> https://www.rfc-editor.org/authors/rfc9944-auth48rfcdiff= .html (side by side)
>>>
>>> Diff files showing all changes:
>>> https://www.rfc-editor.org/authors/rfc9944-diff.html=
>>> https://www.rfc-editor.org/authors/rfc9944-rfcdiff.html<= /a> (side by side)
>>>
>>> All the best,
>>>
>>> Kaelin Foody
>>> RFC Production Center
>>>
>>> On Apr 11, 2026, at 5:51=E2=80=AFAM, Eliot Lear <lear@cisco.com> wrote:
>>>>
>>>> Hi Kaelin,
>>>>
>>>> Below are my answers.  Please be advised, I=E2=80=99= m going on two weeks of holiday and will have a limited ability to = respond or review changes.  Also see below for the one remaining = other issue which is mildly substantial but hopefully not = controversial.
>>>>
>>>>
>>>>> On 9 Apr 2026, at 20:23, Kaelin Foody <kfoody@staff.rfc-editor.org> wrote:
>>>>>
>>>>> Hi Eliot, all,
>>>>>
>>>>> We have updated the files as requested. These = updates are best viewed here: https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.h= tml.
>>>>>
>>>>> A few follow-up questions regarding these = updates:
>>>>>
>>>>> a) Section 6.3.1, Table 2:
>>>>> We have updated this table accordingly. May we also = add a value for =E2=80=9CImm=E2=80=9D in the legend that appears after = this table?
>>>>>
>>>>> Perhaps:
>>>>> Imm =3D Immutable
>>>>
>>>> Yes.
>>>>
>>>>>
>>>>> b) Section 7.6.2, Table 8:
>>>>> In the =E2=80=9CMutable=E2=80=9D column of this = table, should the $ref attribute=E2=80=99s value be updated from =E2=80=9C= R=E2=80=9D to =E2=80=9CRO=E2=80=9D as well (to match the updates made to = devContEntEndpoint and telEntEndpoint)?
>>>>
>>>> Yes.
>>>>
>>>>>
>>>>> c) Appendix A.1:
>>>>> We have updated this line per item #6, but it is = now one character too long. Please review and let us know where to = insert a line break for the line below:
>>>>>
>>>>>  "location": "https://example.com/v2/ResourceTypes/EndpointApps=E2= =80=9D,
>>>>
>>>> I think you can just indent one space.
>>>>
>>>>>
>>>>> d) Appendix B.6:
>>>>> Two additional instances of =E2=80=9C...:Devices=E2=80= =9D (plural) appear in this section. Should these instances be updated = to =E2=80=9C:Device=E2=80=9D (singular) as well?
>>>>>
>>>>> We will request that IANA make their relevant = changes and request AD approval after we receive your remaining = updates.
>>>>
>>>>
>>>>
>>>> In Section 6.3.1, we wrote:
>>>>
>>>> OLD:
>>>>
>>>>> subjectName:When present, a string that contains = one of two names=E2=80=A6
>>>>
>>>> If certificateInfo is present then subjectName must be = present.  Otherwise we haven=E2=80=99t given sufficient = implementation guidance on how to identify a valid identity.  = Therefore, the proposed change is:
>>>>
>>>> NEW:
>>>>
>>>>> subjectName:A string that contains one of two = names
>>>>
>>>> The table already indicates that subjectName is = required, as does the JSON OpenAPI.
>>>>
>>>> This got missed in earlier review because people = (including myself) may have been thinking about whether the parent = object was present.
>>>>
>>>> Regards,
>>>>
>>>> Eliot
>>>>
>>>>
>>>>
>>>>>
>>>>> The AUTH48 status page for this document is = available here:
>>>>> https://www.rfc-editor.org/auth48/rfc9944
>>>>>
>>>>> =E2=80=94 FILES (please refresh): =E2=80=94
>>>>>
>>>>> The updated files have been posted here:
>>>>> https://www.rfc-editor.org/authors/rfc9944.txt
>>>>> https://www.rfc-editor.org/authors/rfc9944.pdf
>>>>> https://www.rfc-editor.org/authors/rfc9944.html
>>>>> https://www.rfc-editor.org/authors/rfc9944.xml
>>>>>
>>>>> Diff files showing changes between the last and = current version:
>>>>> https://www.rfc-editor.org/authors/rfc9944-lastdiff.html=
>>>>> https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.h= tml (side by side)
>>>>>
>>>>> Diff files showing changes made during AUTH48:
>>>>> https://www.rfc-editor.org/authors/rfc9944-auth48diff.ht= ml
>>>>> https://www.rfc-editor.org/authors/rfc9944-auth48rfcdiff= .html (side by side)
>>>>>
>>>>> Diff files showing all changes:
>>>>> https://www.rfc-editor.org/authors/rfc9944-diff.html=
>>>>> https://www.rfc-editor.org/authors/rfc9944-rfcdiff.html<= /a> (side by side)
>>>>>
>>>>> All best,
>>>>>
>>>>> Kaelin Foody
>>>>> RFC Production Center
>>>>>
>>>>>> On Apr 7, 2026, at 1:45=E2=80=AFPM, Eliot Lear = <lear@cisco.com> wrote:
>>>>>>
>>>>>> Hi Kaelin
>>>>>>
>>>>>> Hassan identified a number of typos and = omissions in his review.  Some of these will need IANA review, as = there are several entries missing.  All of these, I think, are = non-controversial edits.
>>>>>>
>>>>>> There is one exception that we will come back = to after this one.  It=E2=80=99s not that it=E2=80=99s = controversial, but it is a substantive change.
>>>>>>
>>>>>> Eliot
>>>>>> 1. Section 7.4.1, Figure 10 (FDO Example) =E2=80=94= schema URIs in JSON
>>>>>> OLD: = urn:ietf:params:scim:schemas:core:2.0:Devices and = urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Devices
= >>>>>> NEW: = urn:ietf:params:scim:schemas:core:2.0:Device and = urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Device
>>>>>> 2. Appendix A.7, FDO Extension JSON Schema =E2=80= =94 id and meta.location use plural "Devices"
>>>>>> OLD: "id": = "urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Devices" = and "location": "...fido-device-onboard:2.0:Devices"
>>>>>> NEW: "id": = "urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Device" = and "location": "...fido-device-onboard:2.0:Device"
>>>>>> 3. Section 7.5.1, Zigbee deviceEui64Address = description
>>>>>> OLD: "takes the same form as the = deviceMACaddress"
>>>>>> NEW: "takes the same form as the = deviceMacAddress "
>>>>>> 4. Section 7.6.2, description of $ref = attribute
>>>>>> OLD: "EndointApp"
>>>>>> NEW: "EndpointApp"
>>>>>> 5. Appendix A.1, Resource Schema =E2=80=94 = EndpointApp endpoint path
>>>>>> OLD: "endpoint": "/EndpointApp"
>>>>>> NEW: "endpoint": "/EndpointApps" 6. OLD: = "location": "https://example.com/v2/ResourceTypes/EndpointApp", >>>>>> NEW: "location": "https://example.com/v2/ResourceTypes/EndpointApps", = 7. Appendix A.3, EndpointApp Schema meta.location
>>>>>> OLD: = "/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:Device"
>>>>>> NEW: = "/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:EndpointApp" 8. = Appendix A.4, in schema with ID = "urn:ietf:params:scim:schemas:extension:pairingOOB:2.0:Device",
>>>>>> OLD: "description": "Passkey pairing method for = BLE."
>>>>>> NEW: "description": "Out-of-band pairing method = for BLE."
>>>>>> 9. Appendix A.4, BLE Extension JSON Schema =E2=80= =94 mobility type
>>>>>> OLD: "type": "bool"
>>>>>> NEW: "type": "boolean"
>>>>>> 10. [We=E2=80=99ll come back to this one]
>>>>>> 11. Section 6.3.1, Table 2 =E2=80=94 = clientToken Return column
>>>>>> OLD: Return =3D N
>>>>>> New: Return =3D Def
>>>>>> 12. Section 7.1.3, Table 3 =E2=80=94 isRandom = Required column
>>>>>> OLD: Req =3D T
>>>>>> NEW: Req =3D F
>>>>>> 13. Section 7.2.1, prose description of = bootstrapKey
>>>>>> OLD: "This attribute is required, case = sensitive, mutable, and returned by default."
>>>>>> NEW: "This attribute is required, case = sensitive, write only, and never returned."
>>>>>> 14. Section 9.2, IANA registrations for BLE = pairing method extensions (pairingNull) =E2=80=94 missing entry
>>>>>> NEW:
>>>>>> Schema URI: = urn:ietf:params:scim:schemas:extension:pairingNull:2.0:Device
>>>>>> Name: Pairing Null
>>>>>> Resource Type: Device
>>>>>> Reference: RFC 9944, Section 7.1.3
>>>>>> 15. Section 9.2, IANA registrations for Zigbee = =E2=80=94 missing entry
>>>>>> NEW:
>>>>>> Schema URI: = urn:ietf:params:scim:schemas:extension:zigbee:2.0:Device
>>>>>> Name: Zigbee
>>>>>> Resource Type: Device
>>>>>> Reference: RFC 9944, Section 7.5
>>>>>> 16. Section 9.2, IANA registration for = urn:ietf:params:scim:schemas:extension:endpointAppsExt:2.0:Device =E2=80=94= Reference
>>>>>> OLD: RFC 9944, Section 7.1.3
>>>>>> NEW: RFC 9944, Section 7.6
>>>>>> 17. Appendix A.4, BLE Extension JSON Schema =E2=80= =94 irk mutability and returned fields
>>>>>> OLD: "mutability": "readWrite", "returned": = "default"
>>>>>> NEW: "mutability": "writeOnly", "returned": = "never"
>>>>>> 18. Appendix A.4, pairingJustWorks schema =E2=80=94= key attribute
>>>>>> OLD: "required": true
>>>>>> NEW: "required": false
>>>>>> 19. Appendix A.7, FDO Extension JSON Schema =E2=80= =94 fdoVoucher mutability and returned fields
>>>>>> OLD: "mutability": "readWrite", "returned": = "default"
>>>>>> NEW: "mutability": "writeOnly", "returned": = "never"
>>>>>> 0a. Section 6.3.1, Table 2 =E2=80=94  = clientToken
>>>>>> For applicationType:
>>>>>> OLD: Mutable =3D R
>>>>>> NEW: Mutable =3D RO
>>>>>> 20b. Section 6.2, prose description of = applicationType
>>>>>> OLD: "The attribute is required and is not case = sensitive. The attribute is readOnly and should be returned by = default."
>>>>>> NEW: "The attribute is required and is not case = sensitive. The attribute is immutable and should be returned by = default."
>>>>>> 20c. Section 6.3.1, Table 2 =E2=80=94 = applicationType Mutable column
>>>>>> OLD: Mutable =3D R
>>>>>> NEW: Mutable =3D Imm
>>>>>> 21. Section 7.6.2, Table 8 =E2=80=94 = devContEntEndpoint and telEntEndpoint
>>>>>> For devContEntEndpoint:
>>>>>> OLD: Mutable =3D R
>>>>>> NEW: Mutable =3D RO
>>>>>> For telEntEndpoint:
>>>>>> OLD: Mutable =3D R
>>>>>> NEW: Mutable =3D RO
>>>>>> 22. Section 7.6.1, prose description of = deviceControlEnterpriseEndpoint
>>>>>> OLD: "This attribute is required, case = sensitive, mutable, and returned by default."
>>>>>> NEW: "This attribute is required, case = sensitive, read-only, and returned by default."
>>>>>> 23. Section 7.6.1, prose description of = telemetryEnterpriseEndpoint
>>>>>> OLD: "This attribute is optional, case = sensitive, mutable, and returned by default."
>>>>>> NEW: "This attribute is optional, case = sensitive, read-only, and returned by default."
>>>>>> 24. Section 7.6.2, Table 8 =E2=80=94 $ref
>>>>>> OLD: $ref row Case Exact =3D F
>>>>>> NEW: $ref row Case Exact =3D T
>>>>>> 25. Appendix A.5, DPP Extension Schema =E2=80=94 = bootstrapKey
>>>>>> OLD: "mutability": "readWrite", "returned": = "default"
>>>>>> NEW: "mutability": "writeOnly", "returned": = "never"
>>>>>> 26. [We=E2=80=99ll come back to this one]
>>>>>> 27. [deleted]
>>>>>> 28. Section 6.3.1, Table 2 =E2=80=94 missing = groups attribute row
>>>>>> OLD: (no groups row in Table 2)
>>>>>> NEW: Add row groups | T | F | T | RO | Def | = n/a
>>>>>> 29. Appendix A.9, endpointAppsExt Extension = Schema =E2=80=94 $ref sub-attribute required
>>>>>> OLD: "required": false
>>>>>> NEW: "required": true
>>>>>> 30. Section 7.1.3, prose =E2=80=94 incorrect = cross-reference to Section 6.1
>>>>>> OLD: "Each extension contains the common = attributes in Section 6.1."
>>>>>> NEW: "Each extension contains the common = attributes in Section 2.1."
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Best
>>> Hassan Iqbal
>>
>


= --Apple-Mail=_AC615E83-EB13-4864-940E-0D2FBB24020E--