RFC 9839 dan Unicode yang Bermasalah

• RFC 9839 secara jelas mendefinisikan karakter Unicode bermasalah yang dapat muncul di field teks saat pengembangan perangkat lunak
• RFC ini membahas masalah akibat kurangnya konsistensi penanganan karakter tersebut di berbagai bahasa dan library
• RFC 9839 mengusulkan tiga subset yang lebih sedikit menimbulkan masalah sehingga bisa digunakan secara opsional
• Dibandingkan framework PRECIS yang sudah ada, penerapannya lebih mudah dan sederhana
• Library bahasa Go untuk RFC 9839 juga dirilis untuk membantu penggunaan di dunia nyata

---

Latar belakang dan ringkasan RFC 9839

• Unicode digunakan sebagai standar di hampir semua pemrosesan data teks
• Namun, jika semua karakter Unicode diizinkan saat merancang struktur data atau protokol, masalah bisa muncul
• Paul Hoffman dan penulis mengajukan draft individual ke IETF untuk memberikan kriteria yang jelas atas masalah Unicode yang terus berulang
• Setelah diskusi selama dua tahun, dokumen ini diadopsi sebagai standar resmi dan diterbitkan sebagai RFC 9839
• Dokumen ini menjelaskan secara rinci jenis karakter bermasalah, alasan mengapa karakter tersebut bermasalah (alasan teknis dan standar), serta tiga subset yang bisa dipilih pengguna

Pokok utama RFC 9839

• Ini adalah dokumen yang wajib dijadikan rujukan saat merancang field teks di lingkungan perangkat lunak dan jaringan
• RFC 9839 terdiri dari 10 halaman, relatif ringkas untuk dokumen standar IETF
• Penjelasannya dibuat agar mudah dipahami terutama oleh pengembang perangkat lunak dan insinyur jaringan

Contoh karakter Unicode yang bermasalah

• Sebagai contoh, field username dalam JSON dapat berisi string seperti berikut

  {  
      "username": "\u0000\u0089\uDEAD\uD9BF\uDFFF"  
  }  
  

• Masalah pada tiap code point
  • U+0000 : karakter NULL yang tidak bermakna dan dapat mengganggu perilaku beberapa bahasa pemrograman
  • U+0089 : kode kontrol C1 (CHARACTER TABULATION WITH JUSTIFICATION), yang perilakunya kompleks dan tidak konsisten
  • U+DEAD : karakter surrogate yang tidak berpasangan, masalah yang berasal dari keterbatasan UTF-16. Ini menghasilkan data yang tidak ideal
  • \uD9BF\uDFFF (sebenarnya U+7FFFF) : noncharacter yang menurut standar dilarang untuk dipertukarkan
• Code point seperti di atas dapat menyebabkan ketidakmampuan penanganan yang konsisten di dalam struktur data dan protokol serta memicu error tak terduga
• RFC 9839 secara resmi mendefinisikan karakter bermasalah semacam ini dan menjelaskan dengan jelas jenis yang harus dikecualikan

Desain dan keterbatasan JSON

• Ini bukan tanggung jawab pencipta JSON, Doug Crockford
• JSON dirancang ketika Unicode belum cukup matang, sehingga tidak bisa membatasi himpunan karakter secara ketat
• Karena standar ini kini tidak dapat diubah, diperlukan pendekatan empiris untuk mengecualikan karakter bermasalah

Perbedaan dengan framework PRECIS milik IETF

• Bahkan sebelum RFC 9839 pada tahun 2025, IETF sudah menyediakan berbagai standar seperti RFC 8264 (PRECIS Framework)
  • Framework ini membahas secara rinci cara membersihkan, menerapkan, dan membandingkan string internasionalisasi
  • Dengan panjang 43 halaman, dokumen ini komprehensif baik dari sisi latar belakang maupun solusi
• PRECIS sangat bergantung pada versi Unicode, kompleks, dan sulit diterapkan
• RFC 9839 dibuat ringkas dan berfokus pada kepraktisan, sehingga mudah diadopsi dengan cepat saat mendefinisikan protokol baru

Subset RFC 9839 dan contoh penggunaannya

• RFC 9839 mengajukan tiga subset praktis (scalars, XML, assignables)
• Masing-masing subset sedikit berbeda dalam cakupan karakter bermasalah yang dikecualikan
• Berikut ringkasan tabel tentang bagaimana format data utama dan subset RFC 9839 menangani karakter bermasalah
  • Beberapa format seperti CBOR, TOML, XML, YAML sebagian mengecualikan surrogate atau karakter kontrol
  • I-JSON mengecualikan surrogate dan noncharacter
  • JSON umum, Protobufs tidak mengecualikannya
  • XML, YAML karena karakteristik charset-nya hanya sebagian mengecualikan noncharacter/kode kontrol
    • Catatan: XML dan YAML tidak mengecualikan noncharacter di luar Basic Multilingual Pane

Library RFC 9839 untuk bahasa Go

• Sebuah library Go kecil telah dirilis untuk mendukung validasi karakter terhadap tiga subset RFC 9839
• Library ini sudah diuji dengan cukup baik, meski optimisasi masih berlangsung
• Pengujian dan masukan dari penggunaan nyata sangat diharapkan

Makna RFC 9839 dan proses pengerjaannya

• RFC 9839 diterbitkan secara resmi setelah melalui umpan balik bersama para co-author dan lebih dari 15 revisi draft
• Melalui diskusi dan kontribusi dari banyak ahli komunitas, dokumen ini berkembang menjadi jauh lebih matang daripada draf awalnya
• Kontributor dicantumkan di bagian “Acknowledgements”

Pengalaman pengajuan RFC secara individual

• RFC 9839 diproses sebagai individual submission
• Dibandingkan pendekatan tradisional melalui Working Group, beban usaha dan prosedurnya lebih besar
• Jika dibandingkan dengan pengalaman berpartisipasi di Working Group, pendekatan tradisional lebih efisien dan lebih direkomendasikan