Hi all, We've added these entries to the SCIM Server-Related Schema URIs registry: Schema URI: urn:ietf:params:scim:schemas:extension:pairingNull:2.0:Device Name: Pairing Null Reference: [RFC-ietf-scim-device-model-18, Section 7.1.3]
Schema URI: urn:ietf:params:scim:schemas:extension:zigbee:2.0:Device Name: Zigbee Reference: [RFC-ietf-scim-device-model-18, Section 7.5] Please see https://www.iana.org/assignments/scim thanks, Amanda On Tue May 05 23:29:10 2026, [email protected] wrote: > Approve > > Phil > [email protected] > > > > > > > > On May 5, 2026, at 4:06 PM, Amanda Baber via RT <iana-matrix- > > [email protected]> wrote: > > > > Hi Phil, Paulo (multiple parties in cc), > > > > IANA has received a request from the RFC Editor (see below) to add > > two entries to the SCIM Server-Related Schema URIs registry for > > draft-ietf-scim-device-model during AUTH48. As the designated > > experts, can you approve these registrations? > > > > We understand that if the first response we receive is an approval, > > we can go ahead with the registrations, unless we're asked to wait > > for the second expert. > > > > thanks, > > > > Amanda Baber > > IANA > > > > ===== > > > > 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]
