They need to go to the designated experts. > On 5 May 2026, at 20:17, Amanda Baber via RT <[email protected]> wrote: > > Hi Kaelin, > > Have the new Schema URI registrations already been approved by a designated > expert for the registry? If not, we'll send this request to both experts, > with [email protected] in copy (per the note at the top of the registry), unless > there's an issue with sending the auth48 link to that list. > > Should the auth48archive email address (and everyone else's) also be copied > on the expert review request? > > We've completed the other two changes below ("Out of Band" to "Out-of-Band," > "Wi-fi" to "Wi-Fi"): > > https://www.iana.org/assignments/scim > > thanks, > Amanda > > On Mon May 04 13:52:00 2026, [email protected] wrote: >> Hi IANA, >> >> Please make the following updates to the "SCIM Server-Related Schema >> URIs" registry at >> <https://www.iana.org/assignments/scim/scim.xhtml#server-related> >> to match the edited document at <https://www.rfc- >> editor.org/authors/rfc9944.html#name-device-schema-extensions>. >> >> 1) Please add the following two entries to the registry: >> >> Schema URI: >> urn:ietf:params:scim:schemas:extension:pairingNull:2.0:Device >> Name: Pairing Null >> Reference: RFC 9944, Section 7.1.3 >> >> Schema URI: urn:ietf:params:scim:schemas:extension:zigbee:2.0:Device >> Name: Zigbee >> Reference: RFC 9944, Section 7.5 >> >> 2) Update "Out of Band" to "Out-of-Band”: >> >> OLD: >> Out of Band Pairing for BLE >> >> NEW: >> Out-of-Band Pairing for BLE >> >> 3) Update "Wi-fi" to "Wi-Fi": >> >> OLD: >> Wi-fi Easy Connect >> >> NEW: >> Wi-Fi Easy Connect >> >> Please let us know if you have any questions and thanks in advance for >> your help. >> >> All best, >> >> Kaelin Foody >> RFC Production Center >> >>> On May 4, 2026, at 9:05 AM, Deb Cooley <[email protected]> wrote: >>> >>> I approve. >>> >>> Deb >>> >>> On Mon, May 4, 2026 at 8:38 AM Kaelin Foody <[email protected] >>> editor.org> wrote: >>> Hi *Deb, Eliot, >>> >>> *Deb - We have updated the text per Eliot’s 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. >>> >>> 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 >>> >>> — FILES (please refresh): — >>> >>> 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.html (side by >>> side) >>> >>> 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) >>> >>> 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) >>> >>> Thank you, >>> >>> Kaelin Foody >>> RFC Production Center >>> >>>> On Apr 27, 2026, at 2:57 AM, Eliot Lear <[email protected]> wrote: >>>> >>>> Ok. I’m back, tanned, with much more knowledge of the Greek >>>> Mycenaean and Archaic periods, and raring to go. I’ve reviewed the >>>> diffs and I want to also address Deb’s points. >>>> >>>> First, about “read-only” and “immutable”. This is an artifact of >>>> RFC 7643. “Read-only” means just that. “Immutable” means it can >>>> be written once. >>>> >>>> Second, everywhere in the draft, the term should be “read-only” not >>>> “read only” (this is a regression). Case can remain as is. >>>> >>>> Finally: >>>> >>>> >>>> >>>>> On 23 Apr 2026, at 06:52, Kaelin Foody <[email protected] >>>>> editor.org> wrote: >>>>> >>>>> >>>>>> b) Should the update below be implemented? >>>>>> >>>>>> Appendix B.6: >>>>>> Two additional instances of “...:Devices” (plural) appear in this >>>>>> section. Should these instances be updated to “:Device” >>>>>> (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 AM, Hassan <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Hi Kaelin, >>>>>> >>>>>> Thank you for the updates. Approved from my end. >>>>>> >>>>>> On Tue, Apr 14, 2026 at 4:32 PM Kaelin Foody <[email protected] >>>>>> 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 “location” line (seen below) and for the >>>>>> “resourceType” 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”, >>>>>>> >>>>>>> I think you can just indent one space. >>>>>> >>>>>> >>>>>> b) Should the update below be implemented? >>>>>> >>>>>>>> Appendix B.6: >>>>>>>> Two additional instances of “...:Devices” (plural) appear in >>>>>>>> this section. Should these instances be updated to “:Device” >>>>>>>> (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 >>>>>> >>>>>> — FILES (please refresh): — >>>>>> >>>>>> 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.html (side >>>>>> by side) >>>>>> >>>>>> 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) >>>>>> >>>>>> 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) >>>>>> >>>>>> All the best, >>>>>> >>>>>> Kaelin Foody >>>>>> RFC Production Center >>>>>> >>>>>> On Apr 11, 2026, at 5:51 AM, Eliot Lear <[email protected]> wrote: >>>>>>> >>>>>>> Hi Kaelin, >>>>>>> >>>>>>> Below are my answers. Please be advised, I’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 <[email protected] >>>>>>>> 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.html. >>>>>>>> >>>>>>>> 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 “Imm” in the legend that appears after this table? >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> Imm = Immutable >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>>> >>>>>>>> b) Section 7.6.2, Table 8: >>>>>>>> In the “Mutable” column of this table, should the $ref >>>>>>>> attribute’s value be updated from “R” to “RO” 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”, >>>>>>> >>>>>>> I think you can just indent one space. >>>>>>> >>>>>>>> >>>>>>>> d) Appendix B.6: >>>>>>>> Two additional instances of “...:Devices” (plural) appear in >>>>>>>> this section. Should these instances be updated to “:Device” >>>>>>>> (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… >>>>>>> >>>>>>> If certificateInfo is present then subjectName must be present. >>>>>>> Otherwise we haven’t 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 >>>>>>>> >>>>>>>> — FILES (please refresh): — >>>>>>>> >>>>>>>> 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.html >>>>>>>> (side by side) >>>>>>>> >>>>>>>> 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) >>>>>>>> >>>>>>>> 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) >>>>>>>> >>>>>>>> All best, >>>>>>>> >>>>>>>> Kaelin Foody >>>>>>>> RFC Production Center >>>>>>>> >>>>>>>>> On Apr 7, 2026, at 1:45 PM, Eliot Lear <[email protected]> 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’s not that it’s controversial, but it is a >>>>>>>>> substantive change. >>>>>>>>> >>>>>>>>> Eliot >>>>>>>>> 1. Section 7.4.1, Figure 10 (FDO Example) — 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 — 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 — 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 — mobility type >>>>>>>>> OLD: "type": "bool" >>>>>>>>> NEW: "type": "boolean" >>>>>>>>> 10. [We’ll come back to this one] >>>>>>>>> 11. Section 6.3.1, Table 2 — clientToken Return column >>>>>>>>> OLD: Return = N >>>>>>>>> New: Return = Def >>>>>>>>> 12. Section 7.1.3, Table 3 — isRandom Required column >>>>>>>>> OLD: Req = T >>>>>>>>> NEW: Req = 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) — 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 — 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 >>>>>>>>> — Reference >>>>>>>>> OLD: RFC 9944, Section 7.1.3 >>>>>>>>> NEW: RFC 9944, Section 7.6 >>>>>>>>> 17. Appendix A.4, BLE Extension JSON Schema — irk mutability >>>>>>>>> and returned fields >>>>>>>>> OLD: "mutability": "readWrite", "returned": "default" >>>>>>>>> NEW: "mutability": "writeOnly", "returned": "never" >>>>>>>>> 18. Appendix A.4, pairingJustWorks schema — key attribute >>>>>>>>> OLD: "required": true >>>>>>>>> NEW: "required": false >>>>>>>>> 19. Appendix A.7, FDO Extension JSON Schema — fdoVoucher >>>>>>>>> mutability and returned fields >>>>>>>>> OLD: "mutability": "readWrite", "returned": "default" >>>>>>>>> NEW: "mutability": "writeOnly", "returned": "never" >>>>>>>>> 0a. Section 6.3.1, Table 2 — clientToken >>>>>>>>> For applicationType: >>>>>>>>> OLD: Mutable = R >>>>>>>>> NEW: Mutable = 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 — applicationType Mutable column >>>>>>>>> OLD: Mutable = R >>>>>>>>> NEW: Mutable = Imm >>>>>>>>> 21. Section 7.6.2, Table 8 — devContEntEndpoint and >>>>>>>>> telEntEndpoint >>>>>>>>> For devContEntEndpoint: >>>>>>>>> OLD: Mutable = R >>>>>>>>> NEW: Mutable = RO >>>>>>>>> For telEntEndpoint: >>>>>>>>> OLD: Mutable = R >>>>>>>>> NEW: Mutable = 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 — $ref >>>>>>>>> OLD: $ref row Case Exact = F >>>>>>>>> NEW: $ref row Case Exact = T >>>>>>>>> 25. Appendix A.5, DPP Extension Schema — bootstrapKey >>>>>>>>> OLD: "mutability": "readWrite", "returned": "default" >>>>>>>>> NEW: "mutability": "writeOnly", "returned": "never" >>>>>>>>> 26. [We’ll come back to this one] >>>>>>>>> 27. [deleted] >>>>>>>>> 28. Section 6.3.1, Table 2 — 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 — $ref sub- >>>>>>>>> attribute required >>>>>>>>> OLD: "required": false >>>>>>>>> NEW: "required": true >>>>>>>>> 30. Section 7.1.3, prose — 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 >>>>> >>>> >>> >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
