In de typering van de berichten geven de eerste 2 karakters aan om wat voor type bericht het gaat en geven de twee daaropvolgende cijfers een nadere specificatie. Zo wordt met die cijfers aangegeven of het om een bericht met historische gegevens handelt. De synchronisatie berichten wijken daar echter vanaf. De indicatie of het om berichten met historie gaat zit daar in de eerste 2 karakters. Voorstel is om dit in lijn met de andere berichten te trekken. ‘Svxx’ berichten voor synchronisatieverzoekberichten en ‘Saxx’ berichten voor synchronisatie(antwoord) berichten. Hieronder de tabel voor de omzetting van de verschillende berichten:
Huidige naam | Nieuwe naam |
---|---|
Sa01 | Sv01 |
Sa02 | Sv02 |
Sa03 | Sa01 |
Sa04 | Sa02 |
Sh01 | Sv03 |
Sh02 | Sv04 |
Sh03 | Sa03 |
Sh04 | Sa04 |
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0440.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Volgens ons klopt de gepresenteerde conversietabel niet. Een huidig Sh03 bericht is bijvoorbeeld een synchronisatieverzoek en in deze tabel wordt de suggestie gewekt dat het een "antwoord" is, dus een synchronisatiebericht.
Wij hebben echter een veel belangrijker bezwaar tegen dit voorstel.
We willen graag een stabiele standaard, die natuurlijk mee-ontwikkelt met de technische ontwikkelingen, maar die verder zo eenvoudige mogelijk overgang van de ene versie naar de andere versie faciliteert. Wij zien geen enkele inhoudelijke meerwaarde bij dit voorstel, terwijl het wel heel veel risico op fouten geeft bij de overgang naar de nieuwe versie.
Dus wij zien dit wijzigingsverzoek graag zo snel mogelijk afgevoerd worden.
Ruud,
Ik heb inderdaad een foutje gemaakt in de tabel. Bij deze de correcte versie:
Tijdens de StUF Expertgroep van 20 juli 2016 is besloten dit RFC niet goed te keuren en af te voeren.
Sid constateerde dat sommige bestaande codes een nieuwe betekenis hebben gekregen. Bijvoorbeeld code SH03 was voorheen opgenomen als code SH01.
De scope gaan hergebruiken voor andere berichten is naar zijn mening niet wenselijk en kan leiden tot problemen. Het advies is dan ook om niet dezelfde code een nieuwe betekenis te geven.