1 Probleemstelling

1.1 Omschrijving

Volgens het Logisch Ontwerp BRP bevat het Null-bericht (ook wel de Verwerkbevestiging genoemd) geen berichtkop en geen berichtinhoud. In termen van de mailboxserver en het sPd-protocol: de MessageBody is leeg. Bij het ontwerp van de BRP Berichten API is er echter voor gekozen om óók bij het Null-bericht het element berichtType op te nemen in de berichtkop, om ervoor te zorgen dat het element berichtInhoud geen leeg JSON-object is en ook om te zorgen dat op dit punt alle berichttypen het element berichtType ín de berichtInhoud hebben staan. Daarmee zijn de specificaties van de BRP Berichten API gaan afwijken van het Logisch Ontwerp en dat wordt met deze wijziging in orde gebracht door het Logisch Ontwerp aan te passen.

1.2 Herkomst

Deze wijziging komt voort uit de constatering (tijdens testen) dat de specificaties van de BRP Berichten API afwijken van het Logisch Ontwerp.

1.3 Raakvlakken

Er zijn vooralsnog geen raakvlakken met andere LO-wijzigingen.

2 Oplossing

2.1 Huidige situatie

In de huidige definitie van het Null-bericht is als volgt: zowel de kop als de inhoud zijn leeg (LO BRP, par. 5.4.9.2).

2.2 Oplossing

Het Null-bericht in het nieuwe JSON-formaat moet voortaan het element berichtType bevatten in de kop van het bericht. Null-berichten in het oude TLV-formaat die worden uitgewisseld via de mailboxserver of via de webservice StuurGBAbericht, blijven zoals ze zijn: leeg.

In par. 5.4.9.2 van het LO BRP wordt de definitie van het Null-bericht dan dus als volgt:

NB: in par. 5.1.7.1 staat bij de beschrijving van het kop-element “berichtnummer” vermeld dat dit element in de BRP Berichten API wordt aangeduid als “berichtType”. Omwille van de consistentie in de beschrijving van alle berichten gebruiken we hier tijdelijk “Berichtnummer”. Wanneer de mailboxserver, de webservice StuurGBAbericht en dus ook het TLV-berichtformaat worden uitgefaseerd, zullen deze benamingen overal in het LO in lijn worden gebracht met de naamgeving in de BRP Berichten API.

2.3 Openstaande punten

Er zijn na implementatie van deze LO-wijziging geen openstaande punten.

3 Invoering

Aangezien de specificaties van de BRP Berichten API al vereisen dat berichtType is opgenomen in de kop van het Null-bericht, en bij nieuwe aansluitingen op de BRP Berichten API wordt getest tegen die specificaties, zou deze wijziging in het Logisch Ontwerp geen impact moeten hebben op bestaande systemen. Daarom wordt deze wijziging opgenomen in LO BRP versie 2027.Q1 van 1 januari 2027.

4 Gevolgen

4.1 Documentatie

Deze wijziging in LO BRP heeft geen gevolgen voor andere logisch ontwerpen (LO BSN, LO BRPk, LO BES en LO PBK) en ook niet voor de HUP en de WIR.

4.2 Gemeenten

Geen gevolgen.

4.3 Afnemers

Geen gevolgen.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

Geen gevolgen.

4.6 RvIG-systemen

Geen gevolgen.

1 Probleemstelling

1.1 Omschrijving

Begin augustus 2026 maakte het eilandstaatje Nauru bekend dat het voortaan (in het Engels) Naoero heet, of voluit: de Republiek Naoero. De nieuwe naam sluit beter aan bij bij de uitspraak en spelling in de eigen landstaal. In de Country Codes Collection behorend bij ISO 3166 is de nieuwe naam ook overgenomen en daarom doen we dat ook in de BRP landentabel, zij het met een trema op de e: Naoëro (spreek uit: Nau-ee-ro). Het trema is toegevoegd om de uitspraak in het Nederlands zo veel mogelijk te laten lijken op hoe Naoëranen de naam van hun land zelf uitspreken.

1.2 Herkomst

Deze wijziging komt voort uit de berichten in de media over de nieuwe naam van Nauru en de wens om in de landentabel zo min mogelijk af te wijken van de internationale standaard ISO 3166.

1.3 Raakvlakken

Er zijn geen raakvlakken met andere LO-wijzigingen.

2 Oplossing

2.1 Huidige situatie

In de huidige landentabel komt het land Nauru voor, met BRP-code 7057.

2.2 Oplossing

In de landentabel wordt de naam van Nauro gewijzigd in Naoëro. Alle andere gegevens in de tabelregel blijven gelijk: zowel de BRP-code als de ISO 3166-codes.

2.3 Openstaande punten

Volgens de Commissie Aardrijkskundige Namen van de Nederlandse Taalunie gaat ISO op een later moment ook de Alpha-3-code van dit land wijzigen van NRU naar NRO. Zodra dat gebeurd is, zal ook die code in de landentabel worden aangepast.

3 Invoering

De wijziging wordt doorgevoerd op 1 januari 2027. Omdat alleen de naam van het land wijzigt, is er geen impact op persoonslijsten en de code 7057 komt sowieso maar heel weinig voor.

4 Gevolgen

4.1 Documentatie

Deze wijziging hoeft alleen doorgevoerd te worden in tabel 34.

4.2 Gemeenten

Gemeenten moeten er rekening mee houden dat de aangepaste naam moet kunnen worden getoond op schermen, uittreksels uit de BRP, aangevraagde reisdocumenten en dergelijke.

4.3 Afnemers

Afnemers moeten er rekening mee houden dat de aangepaste naam moet kunnen worden getoond op schermen en in documenten.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

De (ei)landen van het Caribisch deel van het Koninkrijk moeten er rekening mee houden dat de aangepaste naam moet kunnen worden getoond op schermen en op uittreksels uit de PIVANOBO.

4.6 RvIG-systemen

RvIG moet de nieuwe naam invoeren in de Tabellen Applicatie, er tijdig een Dw01-bericht voor verspreiden en de nieuwe inhoud van de tabel publiceren op de website. In de BRP-V en de RNI moet de nieuwe naam ook kunnen worden getoond op schermen en in documenten.

1 Probleemstelling

1.1 Omschrijving

Nu tabel 34 Landentabel is geactualiseerd per 1 april 2026 en alle namen in overeenstemming zijn gebracht met de adviezen van de Nederlandse Taalunie, is het ook goed om dit te doen voor tabel 32 Nationaliteitentabel. Het is immers niet logisch om te spreken van Kenia in plaats van Kenya, maar de nationaliteit nog wel “Kenyaans” te noemen. Ook staan er wat onjuiste namen in de tabel. Met deze wijziging wordt de nationaliteitentabel “opgefrist”.

1.2 Herkomst

Deze wijziging komt voort uit een analyse van verschillen tussen de namen nationaliteitentabel en de aanwijzingen van de Nederlandse Taalunie en de wens om die verschillen te minimaliseren.

1.3 Raakvlakken

Er zijn geen raakvlakken met andere LO-wijzigingen.

2 Oplossing

2.1 Huidige situatie

In de huidige nationaliteitentabel komen namen soms niet overeen met de aanbevelingen van de Nederlandse Taalunie.

2.2 Oplossing

Namen van nationaliteiten worden aangepast conform de aanwijzingen van de Nederlandse Taalunie. Als zowel de spelling met oe is toegestaan, als die met een u (zoals bij Oeganda / Uganda), kiezen we voor oe. Als de naam van een nationaliteit wijzigt, wijzigt alleen de inhoud van element 05.12 Omschrijving nationaliteit. De datum ingang tabelregel en de eventuele datum beëindiging tabelregel wijzigen niet. Er is dan ook geen impact op persoonslijsten.

Hieronder volgt een overzicht van alle wijzigingen in de namen van nationaliteiten:

2.3 Openstaande punten

Er zijn na de inwerkingtreding van deze wijziging geen openstaande punten.

3 Invoering

De wijzigingen worden bij voorkeur doorgevoerd op 1 januari 2027.

4 Gevolgen

4.1 Documentatie

Deze wijziging hoeft alleen doorgevoerd te worden in tabel 32 Nationaliteitentabel.

4.2 Gemeenten

Gemeenten moeten er rekening mee houden dat de aangepaste namen van nationaliteiten kunnen worden getoond op schermen en op uittreksels uit de hun burgerzakensystemen. Verder moeten ze de bijbehorende tabelberichten kunnen verwerken.

4.3 Afnemers

Afnemers moeten er rekening mee houden dat de aangepaste namen kunnen worden getoond op schermen en in documenten. Verder moeten ze de bijbehorende tabelberichten kunnen verwerken.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

De (ei)landen van het Caribisch deel van het Koninkrijk moeten er rekening mee houden dat de aangepaste namen van nationaliteiten kunnen worden getoond op schermen en op uittreksels uit de PIVANOBO.

4.6 RvIG-systemen

De BRP-V en de RNI moeten de aangepaste namen kunnen tonen op schermen en in documenten. Verder moeten ze de bijbehorende tabelberichten kunnen verwerken.