RFC-2229 – Protokol Server Kamus

Kelompok Kerja Jaringan R. Faith Permintaan Komentar: 2229 U. North Carolina, Chapel Hill Kategori: Informasi B. Martin Miranda Productions Oktober 1997 
Protokol Server Kamus  Status Memo ini Memo ini memberikan informasi untuk komunitas internet.  Itu tidak menentukan standar Internet dalam bentuk apa pun.  Distribusi memo ini tidak terbatas.  Pemberitahuan Hak Cipta Hak Cipta (C) Masyarakat Internet (1997).  Seluruh hak cipta.  Abstrak Dictionary Server Protocol (DICT) adalah protokol kueri/respons berbasis transaksi TCP yang memungkinkan klien mengakses definisi kamus dari sekumpulan database kamus bahasa alami.  Daftar Isi 1. Pendahuluan .................................................. 2 1.1.  Persyaratan ........................................ 3 2. Ikhtisar Protokol ... .................................. 3 2.1.  Tingkat Tautan ................................................... 3 2.2.  Token Leksikal ................................................... 3 2.3.  Perintah ................................................... 4 2.4.  Tanggapan ................................................... 5 2.4.1.  Tanggapan Status ................................... 5 2.4.2.  Tanggapan Status Umum ................................... 6 2.4.3.  Tanggapan Teks .................................................. 6 3. Detail Perintah dan Tanggapan .. ......................... 7 3.1.  Koneksi Awal ................................... 7 3.2.  Perintah DEFINE ................................... 9 3.3.  Perintah MATCH .................................... 10 3.4.  Catatan tentang Basis Data Virtual .......................... 12 3.5.  Perintah TAMPILKAN ................................... 13 3.5.1.  TAMPILKAN DB ............................................. 13 3.5 .2.  TAMPILKAN STRAT ................................................. 13 3.5.3.  TAMPILKAN INFORMASI ............................................ 14 3.5.4 .  TAMPILKAN SERVER ................................................... 14 3.6.  Perintah KLIEN ................................... 15 Faith & Martin Informational                        
 RFC 2229 A Dictionary Server Protocol Oktober 1997 3.7.  Perintah STATUS ................................... 15 3.8.  Perintah BANTUAN ................................... 15 3.9.  Perintah QUIT ................................... 16 3.10.  Perintah OPTION ................................... 16 3.10.1.  MIME OPSI ................................................... 16 3.11.  Perintah AUTH ................................................... 18 3.12.  Perintah SASLAUTH .................................. 18 4. Perintah Pipelining ......... .......................... 20 5. Spesifikasi URL ............... .................. 20 6. Ekstensi ......................... ............... 22 6.1.  Sintaks Perintah Eksperimental .......................... 22 6.2.  Perintah Eksperimental dan Pipelining .................. 22 7. Ringkasan Kode Respons ........................ ...... 23 8. Contoh Percakapan .................................. 23 8.1.  Contoh 1 - perintah HELP, DEFINE, dan QUIT ........... 24 8.2.  Contoh 2 - perintah SHOW, perintah MATCH .............. 25 8.3.  Contoh 3 - Waktu henti server ........................... 26 8.4.  Contoh 4 - Otentikasi .................. 26 9. Pertimbangan Keamanan ............. .................. 26 10. Referensi ......................... ............... 27 11. Ucapan Terima Kasih ................................ ..... 29 12. Alamat Penulis ................................... 29 13. Lengkap Pernyataan Hak Cipta ................................... 30 1.  Pengantar Selama bertahun-tahun, komunitas Internet mengandalkan protokol "webster" untuk mengakses definisi bahasa alami.  Protokol webster mendukung akses ke satu kamus dan (opsional) ke satu tesaurus.  Dalam beberapa tahun terakhir, jumlah server webster yang tersedia untuk umum di Internet telah menurun secara dramatis.  Untungnya, beberapa kamus dan leksikon yang dapat didistribusikan secara bebas baru-baru ini tersedia di Internet.  Namun, database yang dapat didistribusikan secara bebas ini tidak dapat diakses melalui antarmuka yang seragam, dan tidak dapat diakses dari satu situs.  Mereka seringkali kecil dan tidak lengkap secara individual, tetapi secara kolektif akan menyediakan database kata-kata bahasa Inggris yang menarik dan berguna.  Contohnya termasuk file Jargon [JARGON], database WordNet [WORDNET], versi MICRA dari 1913 Webster's Revised Unabridged Dictionary [WEB1913], dan Free Online Dictionary of Computing [Page 2].  Kamus terjemahan dan non-Inggris juga tersedia (misalnya, kamus FOLDOC sedang diterjemahkan ke dalam bahasa Spanyol).  
Faith & Martin Informational [Page 2]



 RFC 2229 A Dictionary Server Protocol Oktober 1997 Protokol webster tidak cocok untuk menyediakan akses ke sejumlah besar database kamus terpisah, dan ekstensi ke protokol webster saat ini tidak dirasakan sebagai solusi bersih untuk masalah database kamus.  Protokol DICT dirancang untuk menyediakan akses ke beberapa database.  Definisi kata dapat diminta, indeks kata dapat dicari (menggunakan serangkaian algoritme yang diperluas dengan mudah), informasi tentang server dapat diberikan (misalnya, strategi pencarian indeks mana yang didukung, atau basis data mana yang tersedia), dan informasi tentang database dapat disediakan (misalnya, hak cipta, kutipan, atau informasi distribusi).  Selanjutnya, protokol DICT memiliki kait yang dapat digunakan untuk membatasi akses ke beberapa atau semua database.  1.1.  Persyaratan Dalam dokumen ini, kami mengadopsi konvensi yang dibahas dalam Bagian 1.3.2 dari [RFC1122] penggunaan kata-kata dalam huruf besar HARUS, DIBUTUHKAN, HARUS, DIREKOMENDASIKAN, MUNGKIN, dan OPSIONAL untuk menentukan pentingnya setiap persyaratan tertentu yang ditentukan dalam dokumen ini.  Singkatnya: "HARUS" (atau "DIBUTUHKAN") berarti bahwa item tersebut merupakan persyaratan mutlak dari spesifikasi;  "HARUS" (atau "DIREKOMENDASIKAN") berarti mungkin ada alasan yang sah untuk mengabaikan item ini, tetapi implikasi penuhnya harus dipahami sebelum melakukannya;  dan "MUNGKIN" (atau "OPSIONAL") berarti bahwa itemnya adalah opsional, dan dapat dihilangkan tanpa pertimbangan yang matang.  2.  Ikhtisar Protokol 
 2.1.  Tingkat Tautan 
 Protokol DICT mengasumsikan aliran data yang andal seperti yang disediakan oleh TCP.  Ketika TCP digunakan, server DICT mendengarkan pada port 2628. Server ini hanya antarmuka antara program dan database kamus.  Itu tidak melakukan interaksi pengguna atau fungsi tingkat presentasi.  2.2.  Token Leksikal  Perintah dan balasan terdiri dari karakter dari set karakter UCS [RFC2044] menggunakan UTF-8 [RFC2044] pengkodean.  Lebih khusus lagi, menggunakan konvensi tata bahasa dari [RFC822]: Faith & Martin Informational [Page 3] 

 RFC 2229 A Dictionary Server Protocol Oktober 1997 ;  ( Oktal, Desimal.) CHAR=CTL=;  ( 177, 127.) CR= ;  ( 15, 13.) LF= ;  ( 12, 10.) SPASI= ;  ( 40, 32.) HTAB= ;  (11, 9.) = ;  ( 42, 34.) = ;  ( 47, 39.) CRLF=CR LF WS=1*(SPASI / HTAB) dqstring= *( dqtext/quoted-pair)  dqtext=, "", dan CTLs> sqstring= *(dqtext/quoted-pair)  sqtext=, "", and CTLs> dikutip-pair="" CHAR atom=1*, , dan ""> string=* kata=keterangan=* teks=*2.3.  Perintah  Perintah terdiri dari kata perintah yang diikuti oleh nol atau lebih parameter.  Perintah dengan parameter harus memisahkan parameter satu sama lain dan dari perintah dengan satu atau lebih spasi atau karakter tab.  Baris perintah harus lengkap  te dengan semua parameter yang diperlukan, dan tidak boleh berisi lebih dari satu perintah.  Setiap baris perintah harus diakhiri oleh CRLF.  Tata bahasa untuk perintah adalah: command=cmd-word * cmd-word=atom cmd-param=database / strategy / word database=atom strategy=atom Perintah tidak peka huruf besar/kecil.  
Faith & Martin Informational [Page 4]


 RFC 2229 A Dictionary Server Protocol Oktober 1997 Baris perintah TIDAK HARUS melebihi 1024 karakter, menghitung semua karakter termasuk spasi, pemisah, tanda baca, dan CRLF tambahan.  Tidak ada ketentuan untuk kelanjutan baris perintah.  Karena UTF-8 dapat mengkodekan karakter menggunakan hingga 6 oktet, buffer baris perintah HARUS dapat menerima hingga 6144 oktet.  2.4.  Tanggapan  Tanggapan ada dua macam, status dan tekstual.  2.4.1.  Tanggapan Status

 Respons status menunjukkan respons server terhadap perintah terakhir yang diterima dari klien.  Baris respons status dimulai dengan kode numerik 3 digit yang cukup untuk membedakan semua respons.  Beberapa di antaranya mungkin menandai transmisi teks berikutnya.  Digit pertama dari respons secara luas menunjukkan keberhasilan, kegagalan, atau kemajuan dari perintah sebelumnya (berdasarkan umumnya pada [RFC640,RFC821]): 1yz - Balasan Awal Positif 2yz - Balasan Penyelesaian Positif 3yz - Balasan Positif Menengah 4yz - Balasan Penyelesaian Negatif Sementara 5yz - Balasan Penyelesaian Negatif Permanen Digit berikutnya dalam kode menunjukkan kategori tanggapan: x0z - Sintaks x1z - Informasi (misalnya, bantuan) x2z - Koneksi x3z - Otentikasi x4z - Belum ditentukan x5z - Sistem DICT (Balasan ini menunjukkan status sistem DICT penerima vis-a-vis transfer yang diminta atau tindakan sistem DICT lainnya.) x8z - Ekstensi tidak standar (implementasi pribadi) Kode respons yang tepat yang diharapkan dari setiap perintah adalah rinci dalam deskripsi perintah itu.  Tanggapan status tertentu berisi parameter seperti angka dan string.  Jumlah dan jenis parameter tersebut ditetapkan untuk setiap kode respons untuk menyederhanakan interpretasi respons.  Tanggapan status lainnya tidak memerlukan pengidentifikasi teks tertentu.  Parameter 
Faith & Martin Informational [Page 6]
 RFC 2229 A Dictionary Server Protocol Oktober 1997
 persyaratan dirinci dalam deskripsi perintah yang relevan.  Kecuali untuk parameter detail khusus, teks berikut kode respons bergantung pada server.  Parameter dipisahkan dari kode respons numerik dan satu sama lain oleh satu spasi.  Semua parameter numerik adalah desimal, dan mungkin memiliki nol di depan.  Semua parameter string HARUS sesuai dengan produksi tata bahasa "atom" atau "dqstring".  Jika tidak ada parameter yang ada, dan implementasi server tidak menyediakan teks khusus implementasi, maka MUNGKIN atau TIDAK MUNGKIN ada spasi setelah kode respons.  Kode respons yang tidak ditentukan dalam standar ini dapat digunakan untuk perintah tambahan khusus instalasi apa pun yang juga tidak ditentukan.  Ini harus dipilih agar sesuai dengan pola x8z yang ditentukan di atas.  Penggunaan kode respons yang tidak ditentukan untuk perintah standar dilarang.  2.4.2.  Tanggapan Status Umum  Menanggapi setiap perintah, respons status umum berikut mungkin terjadi: 500 Kesalahan sintaks, perintah tidak dikenali 501 Kesalahan sintaks, parameter ilegal 502 Perintah tidak diterapkan 503 Parameter perintah tidak diterapkan 420 Server tidak tersedia untuk sementara 421 Server dimatikan atas permintaan operator 2.4.3.  Tanggapan Teks  Sebelum teks dikirim, baris respons status numerik, menggunakan kode 1yz, akan dikirim yang menunjukkan teks akan mengikuti.  Teks dikirim sebagai serangkaian baris materi teks yang berurutan, masing-masing diakhiri dengan CRLF.  Satu baris yang hanya berisi titik (kode desimal 46, ".") dikirim untuk menunjukkan akhir teks (yaitu, server akan mengirim CRLF di akhir baris teks terakhir, titik, dan CRLF lainnya ).  Jika sebuah baris teks asli berisi titik sebagai karakter pertama dari baris tersebut, titik pertama tersebut akan digandakan oleh server DICT.  Oleh karena itu, klien harus memeriksa karakter pertama dari setiap baris yang diterima.  Yang dimulai dengan dua periode harus diciutkan dua periode itu menjadi satu periode.  Mereka yang hanya berisi satu periode diikuti oleh CRLF menunjukkan akhir dari respons teks.  
Faith & Martin Informational [Page 6]
  RFC 2229 A Dictionary Server Protocol Oktober 1997  Jika perintah OPTION MIME telah diberikan, semua tanggapan tekstual akan diawali dengan header MIME [RFC2045] diikuti oleh satu baris kosong (CRLF).  Lihat bagian 3.10.1 untuk detail lebih lanjut tentang OPSI MIME.  Setelah respons teks, kode respons 2yz akan dikirim.  Baris teks TIDAK HARUS melebihi 1024 karakter, menghitung semua karakter termasuk spasi, pemisah, tanda baca, titik awal tambahan (jika diperlukan), dan CRLF tambahan.  Karena UTF-8 dapat mengkodekan karakter menggunakan hingga 6 oktet, buffer input baris teks HARUS dapat menerima hingga 6144 oktet.  Secara default, teks definisi HARUS terdiri dari karakter dari set karakter UCS [Page 6] menggunakan UTF-8 [RFC2044] pengkodean.  Pengkodean UTF-8 memiliki keuntungan mempertahankan rentang penuh nilai ASCII AS 7-bit [USASCII].  Klien dan server HARUS mendukung UTF-8, meskipun hanya dalam beberapa cara minimal.  3.  Detail Perintah dan Tanggapan  Di bawah ini, setiap perintah DICT dan tanggapan yang sesuai dijelaskan secara rinci.  Setiap perintah ditampilkan dalam huruf besar untuk kejelasan, tetapi server DICT tidak peka huruf besar-kecil.  Kecuali untuk perintah AUTH dan SASLAUTH, setiap perintah yang dijelaskan di bagian ini HARUS diimplementasikan oleh semua server DICT.  3.1.  Koneksi Awal Ketika klien awalnya terhubung ke server DICT, kode 220 dikirim jika IP klien diizinkan untuk terhubung: 220 kemampuan teks msg-id Kode 220 adalah banner, biasanya berisi nama host dan informasi versi server DICT.  Urutan karakter kedua hingga terakhir dalam spanduk adalah string kemampuan opsional, yang memungkinkan server mendeklarasikan dukungan untuk ekstensi ke protokol DICT.  String kemampuan didefinisikan di bawah ini: kemampuan=[""] msg-atom=1*", ".", dan ""> Faith & Martin Informational [USASCII] 
[Page 30]  RFC 2229 A Dictionary Server Protocol Oktober 1997 Kemampuan individu dijelaskan oleh satu msg-atom. Misalnya, string  dapat digunakan untuk menggambarkan server yang mendukung ekstensi yang memungkinkan HTML atau keluaran terkompresi.  Nama kemampuan yang dimulai dengan "x" atau "X" dicadangkan untuk ekstensi eksperimental, dan TIDAK HARUS ditentukan dalam spesifikasi protokol DICT di masa mendatang.  Beberapa dari kemampuan ini dapat memberi tahu klien bahwa fungsionalitas tertentu tersedia atau dapat diminta.  Kemampuan berikut saat ini ditentukan: mime Perintah OPTION MIME didukung auth Perintah AUTH didukung kerberos_v4 Mekanisme SASL Kerberos versi 4 didukung gssapi SASL GSSAPI [RFC2078] mekanisme didukung skey Mekanisme SASL S/Key [RFC1760] didukung eksternal Mekanisme eksternal SASL didukung urutan karakter terakhir dalam spanduk adalah msg-id, mirip dengan format yang ditentukan dalam [RFC822].  Deskripsi yang disederhanakan diberikan di bawah ini: msg-id="" ;  Spesifikasi id pesan unik=local-part "@" domain local-part=msg-atom *("." msg-atom) domain=msg-atom *("." msg-atom) Perhatikan bahwa, berbeda dengan [RFC822], spasi dan pasangan kutipan tidak diperbolehkan dalam msg-id.  Pembatasan ini membuat msg-id lebih mudah bagi klien untuk menemukan dan menguraikan tetapi tidak secara signifikan mengurangi manfaat keamanan apa pun, karena msg-id mungkin panjangnya sewenang-wenang (sebagaimana dibatasi oleh batas panjang respons yang ditetapkan di tempat lain dalam dokumen ini).  Perhatikan juga bahwa kurung buka dan tutup adalah bagian dari msg-id dan harus disertakan dalam string yang digunakan untuk menghitung checksum MD5.  Id pesan ini akan digunakan oleh klien saat merumuskan string otentikasi yang digunakan dalam perintah AUTH.  Jika IP klien tidak diizinkan untuk terhubung, maka kode 530 akan dikirim sebagai gantinya: 530 Akses ditolak Respons kegagalan sementara juga dimungkinkan: 420   Server tidak tersedia untuk sementara 421 Server dimatikan atas permintaan operator 
Faith & Martin Informational [Page 9]


 RFC 2229 A Dictionary Server Protocol Oktober 1997 Misalnya, kode respons 420 harus digunakan jika server saat ini tidak dapat melakukan fork a proses server (atau saat ini tidak dapat memperoleh  er sumber daya yang diperlukan untuk melanjutkan dengan koneksi yang dapat digunakan), tetapi diharapkan dapat melakukan fork atau memperoleh sumber daya ini dalam waktu dekat.  Kode respons 421 harus digunakan ketika server telah dimatikan atas permintaan operator, atau ketika kondisi menunjukkan bahwa kemampuan untuk melayani lebih banyak permintaan dalam waktu dekat tidak mungkin.  Ini dapat digunakan untuk memungkinkan penghentian sementara server yang dimediasi oleh operator, atau untuk menunjukkan bahwa server yang terkenal telah dihapus secara permanen dari layanan (dalam hal ini, pesan teks mungkin memberikan informasi lebih lanjut).  3.2.  Perintah DEFINE  DEFINE kata basis data 3.2.1.  Keterangan Perintah ini akan mencari kata yang ditentukan dalam database yang ditentukan.  Semua server DICT HARUS mengimplementasikan perintah ini.  Jika nama database ditentukan dengan tanda seru (kode desimal 33, "!"), maka semua database akan dicari sampai ditemukan kecocokan, dan semua kecocokan dalam database tersebut akan ditampilkan.  Jika nama database ditentukan dengan bintang (kode desimal 42, "*"), maka semua kecocokan di semua database yang tersedia akan ditampilkan.  Dalam kedua kasus khusus ini, database akan dicari dalam urutan yang sama seperti yang dicetak oleh perintah "SHOW DB".  Jika kata tidak ditemukan, maka kode status 552 dikirim.  Jika kata ditemukan, maka kode status 150 dikirim, menunjukkan bahwa satu atau lebih definisi mengikuti.  Untuk setiap definisi, kode status 151 dikirim, diikuti dengan badan tekstual definisi.  Tiga parameter pertama yang dibatasi spasi setelah kode status 151 memberikan kata yang diambil, nama database (yang sama dengan kolom pertama dari perintah SHOW DB), dan deskripsi singkat untuk database (yang sama dengan kolom kedua dari perintah SHOW DB).  Nama pendek cocok untuk dicetak sebagai: Dari nama: sebelum definisi dicetak.  Ini memberikan informasi sumber bagi pengguna.  Faith & Martin Informational [Page 9]


 RFC 2229 A Dictionary Server Protocol Oktober 1997 Badan tekstual dari setiap definisi diakhiri dengan urutan CRLF periode CRLF.  Setelah semua definisi dikirim, kode status 250 dikirim.  Perintah ini dapat memberikan informasi waktu opsional (yang bergantung pada server dan tidak dimaksudkan untuk diuraikan oleh klien).  Informasi tambahan ini berguna saat men-debug dan menyetel server.  3.2.2.  Tanggapan  550 Basis data tidak valid, gunakan "TAMPILKAN DB" untuk daftar basis data 552 Tidak cocok 150 n definisi diambil - definisi mengikuti 151 kata nama basis data - teks mengikuti 250 ok ( informasi waktu opsional di sini) Kode respons 150 dan 151 memerlukan parameter khusus sebagai bagian dari teksnya.  Klien dapat menggunakan parameter ini untuk menampilkan informasi di terminal pengguna.  Untuk kode 150, parameter 1 menunjukkan jumlah definisi yang diambil.  Untuk kode 151, parameter 1 adalah kata yang diambil, parameter 2 adalah nama database (nama pertama seperti yang ditunjukkan oleh "SHOW DB") dari definisi yang telah diambil, dan parameter 3 adalah deskripsi singkat database (kolom kedua dari perintah "SHOW DB").  3.3.  Perintah PERTANDINGAN  MATCH kata strategi database  3.3.1.  Keterangan Perintah ini mencari indeks untuk kamus, dan melaporkan kata-kata yang ditemukan menggunakan strategi tertentu.  Tidak semua strategi berguna untuk semua kamus, dan beberapa kamus mungkin mendukung strategi pencarian tambahan (misalnya, pencarian terbalik).  Semua server DICT HARUS menerapkan perintah MATCH, dan HARUS mendukung strategi "tepat" dan "awalan".  Ini mudah diterapkan dan umumnya yang paling berguna.  Strategi lain bergantung pada server.  Strategi "tepat" sama persis dengan kata, meskipun server yang berbeda mungkin memperlakukan data non-alfanumerik secara berbeda.  Kami telah menemukan bahwa perbandingan case-insensitive yang mengabaikan non-alfanumerik [Page 30]Faith & Martin Informational [PZ85]



 
RFC 2229 A Dictionary Server Protocol Oktober 1997
 karakter dan yang melipat spasi berguna untuk Kamus bahasa Inggris.  Perbandingan lain mungkin lebih sesuai untuk bahasa lain atau saat menggunakan rangkaian karakter yang diperluas.  Strategi "awalan" mirip dengan "tepat", kecuali hanya membandingkan bagian pertama kata.  Server yang berbeda dapat mengimplementasikan algoritme ini secara berbeda.  Persyaratannya adalah bahwa ada strategi dengan nama "tepat" dan "awalan" sehingga klien sederhana dapat menggunakannya.  Strategi lain yang mungkin dipertimbangkan oleh pelaksana server adalah kecocokan berdasarkan substring, sufiks, ekspresi reguler, soundex [Page 9] , dan algoritma Levenshtein [PZ85].  Dua yang terakhir ini sangat berguna untuk mengoreksi kesalahan ejaan.  Strategi berguna lainnya melakukan semacam pencarian "terbalik" (yaitu, dengan mencari definisi untuk menemukan kata yang disarankan oleh kueri).  Jika nama database ditentukan dengan tanda seru (kode desimal 33, "!"), maka semua database akan dicari sampai ditemukan kecocokan, dan semua kecocokan dalam database tersebut akan ditampilkan.  Jika nama database ditentukan dengan bintang (kode desimal 42, "*"), maka semua kecocokan di semua database yang tersedia akan ditampilkan.  Dalam kedua kasus khusus ini, database akan dicari dalam urutan yang sama seperti yang dicetak oleh perintah "SHOW DB".  Jika strategi ditentukan menggunakan titik (kode desimal 46, "."), maka kata tersebut akan dicocokkan menggunakan strategi default yang bergantung pada server, yang seharusnya menjadi strategi terbaik yang tersedia untuk pemeriksaan ejaan interaktif.  Ini biasanya merupakan turunan dari algoritma Levenshtein [PZ85].  Jika tidak ada kecocokan yang ditemukan di salah satu database yang dicari, maka kode status 552 akan dikembalikan.  Jika tidak, kode status 152 akan dikembalikan diikuti dengan daftar kata yang cocok, satu per baris, dalam bentuk: kata basis data Ini membuat respons langsung berguna dalam perintah DEFINE.  Badan tekstual daftar kecocokan diakhiri dengan urutan CRLF periode CRLF.  Mengikuti daftar, kode status 250 dikirim, yang mungkin termasuk waktu khusus server dan informasi statistik, seperti yang dibahas di bagian perintah DEFINE.  Faith & Martin Informational [Page 11]  
 RFC 2229 A Dictionary Server Protocol Oktober 1997  3.3.2 .  Tanggapan  550 Basis data tidak valid, gunakan "SHOW DB" untuk daftar basis data 551 Strategi tidak valid, gunakan "SHOW STRAT" untuk daftar strategi 552 Tidak cocok 152 n cocok ditemukan - teks mengikuti 250 ok (informasi waktu opsional di sini) Kode respons 152 memerlukan parameter khusus sebagai bagian dari teksnya.  Parameter 1 harus jumlah kecocokan yang diambil.  3.4.  Catatan tentang Basis Data Virtual 
 Kemampuan untuk mencari semua database yang disediakan menggunakan satu perintah diberikan menggunakan khusus "*" dan "!"  database.  Namun, terkadang, klien mungkin ingin mencari beberapa tetapi tidak semua database yang disediakan oleh server tertentu.  Salah satu alternatifnya adalah klien menggunakan perintah SHOW DB untuk mendapatkan daftar database dan deskripsi, dan kemudian (mungkin dengan bantuan manusia), pilih subset database ini untuk pencarian interaktif.  Setelah pemilihan ini dilakukan sekali, hasilnya dapat disimpan, misalnya, dalam file konfigurasi klien.  Alternatif lain adalah server menyediakan database "virtual" yang menggabungkan beberapa database biasa menjadi satu.  Misalnya, database virtual dapat disediakan yang mencakup semua kamus terjemahan, tetapi tidak termasuk kamus atau tesauri biasa.  Khusus "*" dan "!"  database dapat dianggap sebagai nama database virtual yang menyediakan akses ke semua database.  Jika server mengimplementasikan database virtual, maka khusus "*" dan "!"  database mungkin harus mengecualikan database virtual lainnya (karena mereka hanya menyediakan informasi yang diduplikasi di database lain).  Jika database virtual didukung, mereka harus terdaftar sebagai database biasa dengan perintah SHOW DB (walaupun, karena "*" dan "!" diperlukan, mereka tidak perlu dicantumkan).  Basis data virtual adalah detail spesifik implementasi yang sama sekali tidak berdampak pada protokol DICT.  Protokol DICT melihat database virtual dan non-virtual dengan cara yang sama.  Kami menyebutkan database virtual di sini, karena mereka memecahkan   masalah pemilihan database yang juga bisa diselesaikan dengan perubahan protokol.  Misalnya, setiap kamus dapat diberi atribut, dan protokol dapat diperluas untuk menentukan pencarian di database dengan atribut tertentu.  Namun, ini tidak perlu memperumit parsing dan analisis yang harus dilakukan oleh implementasi.  Selanjutnya, kecuali klasifikasi 
Faith & Martin Informational [Page 12]

 
RFC 2229 A Dictionary Server Protocol Oktober 1997
 sistemnya sangat umum, ada risikonya akan membatasi jenis database yang dapat digunakan dengan protokol DICT (walaupun protokol telah  n dirancang dengan mempertimbangkan database bahasa manusia, ini berlaku untuk aplikasi database read-only, terutama yang memiliki kunci alfanumerik semi-unik dan data tekstual).  3.5.  Perintah TAMPILKAN  3.5.1.  TAMPILKAN DB TAMPILKAN DB TAMPILKAN DATABASES 3.5.1.1.  Keterangan Menampilkan daftar database yang saat ini dapat diakses, satu per baris, dalam bentuk: deskripsi database Badan tekstual dari daftar database diakhiri dengan periode CRLF urutan CRLF .  Semua server DICT HARUS mengimplementasikan perintah ini.  Perhatikan bahwa beberapa database mungkin dibatasi karena domain klien atau kurangnya otentikasi pengguna (lihat perintah AUTH dan SASLAUTH di bagian 3.11 dan 3.12).  Informasi tentang database ini tidak tersedia sampai otentikasi dilakukan.  Sampai saat itu, klien akan berinteraksi dengan server seolah-olah database tambahan tidak ada.  3.5.1.2.  Tanggapan  110 n database hadir - teks mengikuti 554 Tidak ada database Kode respons 110 memerlukan parameter khusus.  Parameter 1 harus jumlah database yang tersedia untuk pengguna.  3.5.2.  TAMPILKAN STRAT STRATEGI TAMPILKAN STRATEGI Faith & Martin Informational [Page 14] 

  RFC 2229 A Dictionary Server Protocol Oktober 1997  
3.5.2.1.  Keterangan Menampilkan daftar strategi pencarian yang saat ini didukung, satu per baris, dalam bentuk: deskripsi strategi Badan tekstual dari daftar strategi diakhiri dengan periode CRLF CRLF urutan.  Semua server DICT HARUS mengimplementasikan perintah ini.  3.5.2.2.  Tanggapan  111 n strategi tersedia - teks mengikuti 555 Tidak ada strategi yang tersedia Kode respons 111 memerlukan parameter khusus.  Parameter 1 harus jumlah strategi yang tersedia.  3.5.3.  TAMPILKAN INFO
 TAMPILKAN database INFO 3.5.3.1.  Keterangan Menampilkan sumber, hak cipta, dan informasi lisensi tentang database yang ditentukan.  Informasi adalah teks bentuk bebas dan cocok untuk ditampilkan kepada pengguna dengan cara yang sama seperti definisi.  Tubuh tekstual informasi diakhiri dengan urutan CRLF periode CRLF.  Semua server DICT HARUS mengimplementasikan perintah ini.  3.5.3.2.  Tanggapan  550 Basis data tidak valid, gunakan "TAMPILKAN DB" untuk daftar basis data 112 informasi basis data berikut Kode respons ini tidak memerlukan parameter khusus.  3.5.4.  TAMPILKAN SERVER
 TAMPILKAN SERVER 3.5.4.1.  Keterangan Menampilkan informasi server lokal yang ditulis oleh administrator lokal.  Ini dapat mencakup informasi tentang database atau strategi lokal, atau informasi administratif seperti siapa yang harus dihubungi untuk mengakses database yang memerlukan otentikasi.  Semua server DICT HARUS mengimplementasikan perintah ini.  Faith & Martin Informational [Page 14] 
 RFC 2229 A Dictionary Server Protocol Oktober 1997 
3.5.4.2.  Tanggapan  114 informasi server berikut Kode respons ini tidak memerlukan parameter khusus.  3.6.  Perintah KLIEN  teks KLIEN  3.6.1.  Keterangan Perintah ini memungkinkan klien untuk memberikan informasi tentang dirinya sendiri untuk kemungkinan logging dan tujuan statistik.  Semua klien HARUS mengirim perintah ini setelah terhubung ke server.  Semua server DICT HARUS mengimplementasikan perintah ini (perhatikan, bahwa server tidak harus melakukan apa pun dengan informasi yang diberikan oleh klien).   3.6.2.  Tanggapan  250 ok (informasi waktu opsional di sini) Kode respons ini tidak memerlukan parameter khusus.  3.7.  Perintah STATUS  STATUS 3.7.1.  Keterangan Menampilkan beberapa waktu khusus server atau informasi debugging.  Informasi ini mungkin berguna dalam men-debug atau menyetel server DICT.  Semua server DICT HARUS mengimplementasikan perintah ini (perhatikan, bahwa bagian teks dari respons tidak ditentukan dan dapat dihilangkan).  3.7.2.  Tanggapan  210 (waktu opsional dan informasi statistik di sini) Kode respons ini tidak memerlukan parameter khusus.  3.8.  Perintah BANTUAN  TOLONG 
Faith & Martin Informational [Page 15]

 RFC 2229 A Dictionary Server Protocol Oktober 1997
  3.8.1.  Keterangan Memberikan ringkasan singkat dari perintah yang dipahami oleh implementasi server DICT ini.  Teks bantuan akan disajikan sebagai respons tekstual, diakhiri oleh satu titik pada satu baris dengan sendirinya.  Semua server DICT HARUS mengimplementasikan perintah ini.  3.8.2.  Tanggapan  113 teks bantuan berikut Kode respons ini tidak memerlukan parameter khusus.  3.9.  Perintah KELUAR  BERHENTI  3.9.1.  Keterangan Perintah ini digunakan oleh klien untuk keluar dari server dengan bersih.  Semua server DICT HARUS mengimplementasikan perintah ini.  3.9.2.  Tanggapan  221 Menutup Koneksi Kode respons ini tidak memerlukan parameter khusus.  3.10.  Perintah OPSI  3.10.1.  OPSI MIME OPSI MIME 3.10.1.1.  Keterangan Meminta agar semua tanggapan teks diawali dengan header MIME [RFC2045] diikuti oleh satu baris kosong (CRLF).  Jika klien meminta opsi ini, maka klien HARUS dapat mem-parsing header Content-Type dan Content-transfer-encoding, dan HARUS dapat mengabaikan respons tekstual yang memiliki konten atau penyandian yang tidak didukung.  Klien HARUS mendukung pengkodean UTF-8 [RFC2044], yang minimal berarti bahwa klien HARUS mengenali pengkodean multi-oktet UTF-8 dan mengubahnya menjadi beberapa simbol yang dapat dicetak oleh klien.  Faith & Martin Informational [RFC1939] 

 RFC 2229 A Dictionary Server Protocol Oktober 1997 Jika klien meminta opsi ini, maka server akan menyediakan header MIME.  Jika tajuk kosong, respons teks akan dimulai dengan satu baris kosong (CRLF), dalam hal ini klien HARUS menafsirkan ini sebagai tajuk default.  Header default untuk otentikasi SASL adalah: Content-type: application/octet-stream Content-transfer-encoding: base64 Header default untuk semua respons tekstual lainnya adalah: Content-type: text/plain;  charset=utf-8 Content-transfer-encoding: 8bit Jika OPTION MIME tidak ditentukan oleh klien, maka server dapat membatasi konten informasi yang diberikan kepada klien.  Misalnya, definisi dapat disertai dengan gambar dan klip audio, tetapi server tidak dapat mengirimkan informasi ini kecuali jika klien dapat mengurai header format MIME.  Perhatikan bahwa, karena batasan panjang baris dan semantik akhir respons, pengkodean transfer konten "biner" TIDAK HARUS digunakan.  Di masa depan, ekstensi ke protokol dapat disediakan yang memungkinkan klien untuk meminta pengkodean biner, tetapi default HARUS selalu bahwa klien dapat mencari urutan "CRLF .CRLF" untuk menemukan akhir dari respons teks saat ini.  Ini memungkinkan klien untuk dengan mudah melewati respons teks yang memiliki jenis atau penyandian yang tidak didukung.  Di masa depan, setelah pengalaman yang signifikan dengan database besar dalam berbagai bahasa telah diperoleh, dan setelah mengevaluasi kebutuhan untuk menentukan set karakter dan pengkodean lainnya (misalnya, pengkodean terkompresi atau BASE64), ekstensi standar untuk protokol ini harus diusulkan yang memungkinkan klien untuk meminta jenis konten atau penyandian tertentu.  Harus diperhatikan bahwa ekstensi ini tidak memerlukan jabat tangan yang mengalahkan pipelining.  Sementara itu, ekstensi pribadi harus digunakan untuk menjelajahi ruang parameter guna menentukan cara terbaik untuk menerapkan ekstensi ini.  OPTION MIME adalah kemampuan server yang DIBUTUHKAN, semua server DICT HARUS mengimplementasikan perintah ini.  3.10.1.2.  Tanggapan  250 ok (informasi waktu opsional di sini) Perhatikan bahwa beberapa implementasi server lama, yang diselesaikan sebelum dokumen ini diselesaikan, akan mengembalikan kode status 500 jika perintah ini tidak dilaksanakan.  Klien HARUS dapat menerima perilaku ini, 
Faith & Martin Informational [Page 17]

 
RFC 2229 A Dictionary Server Protocol Oktober 1997 membuat asumsi default.  Klien juga dapat memeriksa string kemampuan di header kode status 220 untuk menentukan apakah server mendukung kemampuan ini.  3.11.  Perintah AUTH AUTH username otentikasi-string 3.11.1.  Keterangan Klien dapat mengotentikasi dirinya sendiri ke server menggunakan nama pengguna dan kata sandi.  String otentikasi akan dihitung seperti pada protokol APOP yang dibahas dalam [Page 16].  Secara singkat, otentikasi-string adalah checksum MD5 dari rangkaian msg-id (diperoleh dari spanduk awal) dan "rahasia bersama" yang disimpan dalam file konfigurasi server dan klien.  Karena pengguna tidak harus mengetikkan rahasia bersama ini saat mengakses server, rahasia bersama dapat berupa frasa sandi yang panjangnya sewenang-wenang.  Karena kemudahan komputasi dalam menghitung checksum MD5, rahasia bersama harus jauh lebih panjang daripada kata sandi biasa.  Otentikasi dapat membuat lebih banyak database kamus tersedia untuk sesi saat ini.  Misalnya, mungkin ada beberapa database yang dapat didistribusikan secara publik yang tersedia untuk semua pengguna, dan database pribadi lainnya hanya tersedia untuk pengguna yang diautentikasi.  Atau, server mungkin memerlukan otentikasi dari semua pengguna untuk meminimalkan pemanfaatan sumber daya pada mesin server.  Otentikasi adalah kemampuan server opsional.  Perintah AUTH MUNGKIN diimplementasikan oleh server DICT.  3.11.2.  Tanggapan  230 Otentikasi berhasil 531 Akses ditolak, gunakan "TAMPILKAN INFO" untuk informasi server Kode respons ini tidak memerlukan parameter khusus.  3.12.  Perintah SASLAUTH
 Mekanisme SASLAUTH, respons awal, respons SASLRESP 
3.12.1.  Keterangan Simple Authentication and Security Layer (SASL) saat ini sedang dikembangkan [RFC2222].  Protokol DICT menyimpan perintah SASLAUTH dan SASLRESP untuk metode otentikasi ini.  Hasil 
Faith & Martin Informational [Page 18]
 
RFC 2229 A Dictionary Server Protocol Oktober 1997 otentikasi sukses dengan SALSAUTH akan sama dengan hasil otentikasi AUTH yang berhasil: lebih banyak database kamus mungkin tersedia untuk saat ini  sesi nt.  Respon awal adalah parameter opsional untuk perintah SASLAUTH, dikodekan menggunakan pengkodean BASE64 [RFC2045].  Beberapa mekanisme SASL memungkinkan penggunaan parameter ini.  Jika otentikasi SASL didukung oleh server DICT, maka parameter ini HARUS juga didukung.  Otentikasi SASL tipikal akan dimulai oleh klien menggunakan perintah SASLAUTH.  Server akan membalas dengan kode status 130, diikuti dengan tantangan.  Tantangan akan diikuti oleh kode status 330, yang menunjukkan bahwa klien sekarang harus mengirim respons ke server.  Bergantung pada detail mekanisme SASL yang saat ini digunakan, server akan melanjutkan pertukaran menggunakan kode status 130, tantangan, dan kode status 330;  atau server akan menggunakan kode status 230 atau 531 untuk menunjukkan otentikasi berhasil atau gagal.  Tantangan yang dikirim oleh server ditentukan oleh mekanisme sebagai token biner dengan panjang yang berubah-ubah, dan harus dikirim menggunakan respons tekstual DICT standar, seperti yang dijelaskan di bagian 2.4.3.  Jika OPTION MIME tidak disetel, maka encoding BASE64 HARUS digunakan.  Jika OPTION MIME diatur, maka BASE64 adalah pengkodean default, seperti yang ditentukan di bagian 3.10.1.  Klien akan mengirim semua tanggapan menggunakan perintah SASLRESP dan parameter yang dikodekan BASE64.  Respons yang dikirim oleh klien didefinisikan oleh mekanisme sebagai token biner dengan panjang sewenang-wenang.  Ingat bahwa baris perintah DICT mungkin hanya sepanjang 1024 karakter, jadi respons yang diberikan oleh klien DICT terbatas.  Jika mekanisme yang ditentukan dalam perintah SASLAUTH tidak didukung, maka kode status 532 akan dikembalikan.  Otentikasi adalah kemampuan server opsional.  Perintah SASLAUTH MUNGKIN diimplementasikan oleh server DICT.  3.12.2.  Tanggapan  130 tantangan mengikuti 330 kirim respons 230 Otentikasi berhasil 531 Akses ditolak, gunakan "TAMPILKAN INFO" untuk informasi server 532 Akses ditolak, mekanisme tidak dikenal Faith & Martin Informational [Page 19] 
 [Page 30]RFC 2229 A Dictionary Server Protocol Oktober 1997 Kode respons ini tidak memerlukan parameter khusus.  4.  Perintah Pipelining
 Semua server DICT HARUS dapat menerima banyak perintah dalam satu operasi pengiriman TCP.  Menggunakan operasi pengiriman TCP tunggal untuk beberapa perintah dapat meningkatkan kinerja DICT secara signifikan, terutama dalam menghadapi tautan jaringan latensi tinggi.  Kemungkinan masalah implementasi untuk server DICT yang akan mencegah pemipaan perintah serupa dengan masalah yang mencegah pemipaan di server SMTP.  Masalah-masalah ini dibahas secara rinci dalam [RFC1854], yang harus dikonsultasikan oleh semua pelaksana server DICT.  Implikasi utamanya adalah bahwa implementasi server DICT TIDAK HARUS menyiram atau kehilangan konten buffer input TCP dalam keadaan apa pun.  Klien DICT dapat menyalurkan beberapa perintah dan harus memeriksa respons untuk setiap perintah satu per satu.  Jika server telah dimatikan, kemungkinan semua perintah tidak akan diproses.  Misalnya, klien DICT sederhana dapat menyalurkan urutan perintah CLIENT, DEFINE, dan QUIT saat terhubung ke server.  Jika server dimatikan, kode respons awal yang dikirim oleh server mungkin 420 (sementara tidak tersedia) bukan 220 (banner).  Dalam hal ini, definisi tidak dapat diambil, dan klien harus melaporkan dan melakukan kesalahan atau mencoba kembali perintah.  Jika server berfungsi, mungkin dapat mengirim kembali spanduk, definisi, dan pesan terminasi dalam satu operasi pengiriman TCP.  5.  Spesifikasi URL
 Skema URL DICT digunakan untuk merujuk pada definisi atau daftar kata yang tersedia menggunakan protokol DICT:     dict://;@: /D: : :  dict://;@: /M: : : :  Sintaks "/d" menentukan perintah DEFINE (bagian 3.2), sedangkan "/m" menentukan perintah MATCH (bagian 3.3).  Faith & Martin Informational [Page 20] 
 RFC 2229 A Dictionary Server Protocol Oktober 1997
 Beberapa atau semua ";@", ": ", "", "[PZ85] ", dan "" dapat dihilangkan .  "" biasanya akan dihilangkan, tetapi ketika disertakan, ini menentukan definisi ke-n atau kecocokan sebuah kata.  Metode untuk mengekstrak informasi ini secara tepat dari server tidak tersedia menggunakan protokol DICT.  Namun, klien yang menggunakan spesifikasi URL dapat memperoleh semua definisi atau kecocokan, lalu memilih salah satu yang ditentukan.  Jika ";@" dihilangkan, tidak ada otentikasi yang dilakukan.  Jika ": " dihilangkan, port default (2628) HARUS digunakan.  Jika "" dihilangkan, "!"  HARUS digunakan (lihat bagian 3.2).  Jika "" dihilangkan, "."  HARUS digunakan (lihat bagian 3.3).  ";@" menentukan nama pengguna dan jenis otentikasi yang dilakukan.  Untuk "", string "AUTH" menunjukkan bahwa otentikasi APOP menggunakan perintah AUTH akan dilakukan, sedangkan string "SASLAUTH=" menunjukkan bahwa perintah SASLAUTH dan SASLRESP akan digunakan, dengan "" menunjukkan jenis otentikasi SASL yang akan digunakan. digunakan.  Jika "" adalah bintang (kode desimal 42, "*"), maka klien akan memilih beberapa jenis otentikasi.  Setiap kali otentikasi diperlukan, klien HARUS meminta informasi tambahan (misalnya, frasa sandi) dari pengguna.  Berbeda dengan [Page 20], kata sandi teks yang jelas tidak diizinkan di URL.  Tanda titik dua yang tertinggal dapat dihilangkan.  Misalnya, URL berikut mungkin menentukan definisi atau kecocokan: dict://dict.org/d:shortcake: dict://dict.org/d:shortcake:dict://dict.org/d:shortcake:wordnet : dict://dict.org/d:shortcake:wordnet:1 dict://dict.org/d:abcdefgh dict://dict.org/d:sun dict://dict.org/d:sun: :1 dict://dict.org/m:sun dict://dict.org/m:sun::soundex dict://dict.org/m:sun:wordnet::1 dict://dict.org /m:sun::soundex:1 dict://dict.org/m:sun::: 
Faith & Martin Informational [Page 21]



  RFC 2229 A Dictionary Server Protocol Oktober 1997  

6.  Ekstensi Protokol ini dirancang agar database teks datar dapat digunakan dengan server setelah analisis dan pemformatan minimum.  Pengalaman kami adalah bahwa hanya membangun indeks untuk database mungkin cukup untuk membuatnya berguna dengan server DICT.  Kemampuan untuk menyajikan teks yang telah diformat sebelumnya sangat penting karena database yang tersedia secara bebas sering didistribusikan sebagai file teks datar tanpa informasi mark-up semantik (dan sering berisi "seni ASCII" yang menghalangi otomatisasi bahkan pemformatan sederhana).  Namun, mengingat database dengan informasi mark-up yang memadai, dimungkinkan untuk menghasilkan output dalam berbagai format yang berbeda (misalnya, HTML sederhana atau SGML yang lebih canggih).  Spesifikasi pemformatan berada di luar cakupan dokumen ini.  Persyaratan untuk negosiasi format (termasuk set karakter dan pengkodean lainnya) rumit dan harus diperiksa dari waktu ke waktu karena lebih banyak pengalaman diperoleh.  Kami menyarankan agar penggunaan format yang berbeda, serta fitur server lainnya, dieksplorasi sebagai ekstensi protokol.  6.1.  Sintaks Perintah Eksperimental Perintah satu huruf dicadangkan untuk debugging dan pengujian, TIDAK HARUS didefinisikan dalam spesifikasi protokol DICT di masa mendatang, dan TIDAK HARUS digunakan oleh perangkat lunak klien mana pun .  Perintah yang dimulai dengan huruf "X" dicadangkan untuk ekstensi eksperimental, dan TIDAK HARUS didefinisikan dalam spesifikasi protokol DICT di masa mendatang.  Penulis perangkat lunak klien harus memahami bahwa perintah ini bukan bagian dari protokol DICT dan mungkin tidak tersedia di semua server DICT.   6.2.  Perintah Eksperimental dan Pipelining Perintah eksperimental harus dirancang sehingga klien dapat menyalurkan perintah eksperimental tanpa mengetahui apakah server mendukung perintah tersebut (misalnya, alih-alih menggunakan negosiasi fitur ).  Jika server tidak mendukung perintah, maka kode respons dalam seri 5yz (biasanya 500) akan diberikan, memberi tahu klien bahwa ekstensi tidak didukung.  Tentu saja, tergantung pada kerumitan ekstensi yang ditambahkan, negosiasi fitur mungkin diperlukan.  Untuk membantu meminimalkan waktu negosiasi, fitur yang didukung server dapat diumumkan di spanduk (kode 220) menggunakan parameter kemampuan opsional.  Faith & Martin Informational [Page 22] 


 
 RFC 2229 A Dictionary Server Protocol Oktober 1997 7.  Ringkasan Kode Respons Di bawah ini adalah ringkasan kode respons.  Sebuah bintang   pada kolom pertama menunjukkan respon telah mendefinisikan argumen yang harus diberikan.  110 n basis data hadir - teks mengikuti 111 n strategi tersedia - teks mengikuti 112 informasi basis data mengikuti 113 teks bantuan mengikuti 114 informasi server mengikuti 130 tantangan mengikuti 150 n definisi diambil - definisi mengikuti 151 kata nama basis data - teks mengikuti 152 n kecocokan ditemukan - teks mengikuti 210 (waktu opsional dan informasi statistik di sini) 220 msg-id teks 221 Menutup Koneksi 230 Otentikasi berhasil 250 ok (informasi pengaturan waktu opsional di sini) 330 kirim respons 420 Server tidak tersedia untuk sementara 421 Server dimatikan atas permintaan operator 500 Sintaks kesalahan, perintah tidak dikenali 501 Kesalahan sintaks, parameter ilegal 502 Perintah tidak diterapkan 503 Parameter perintah tidak diterapkan 530 Akses ditolak 531 Akses ditolak, gunakan "SHOW INFO" untuk informasi server 532 Akses ditolak, mekanisme tidak diketahui 550 Database tidak valid, gunakan "SHOW DB" untuk daftar database 551 Strategi tidak valid, gunakan "SHOW STRAT" untuk daftar strategi 552 Tidak cocok 554 Tidak ada database pres  ent 555 Tidak ada strategi yang tersedia 
8.  Contoh Percakapan

 Ini adalah contoh percakapan yang mungkin diharapkan dengan server DICT biasa.  Notasi "C:" menunjukkan perintah yang ditetapkan oleh klien, dan "S:" menunjukkan respons yang dikirim oleh server.  Baris kosong disertakan untuk kejelasan dan tidak menunjukkan baris baru yang sebenarnya dalam transaksi.  Faith & Martin Informational [Page 23]


  RFC 2229 A Dictionary Server Protocol Oktober 1997   8.1.  Contoh 1 - perintah HELP, DEFINE, dan QUIT C: [ client initiates connection ] S: 220 dict.org dictd (versi 0.9)  C: HELP S: 113 Teks bantuan berikut S: DEFINE kata basis data mencari kata dalam basis data S: MATCH strategi basis data mencocokkan kata dalam basis data menggunakan strategi S: [ more server-dependent help text ] S: .  S: 250 Perintah selesai C: DEFINE !  penguin S: 150 1 definisi ditemukan: daftar berikut S: 151 "penguin" wn "WordNet 1.5" : teks definisi berikut S: penguin S: 1. n: burung berkaki pendek yang tidak bisa terbang dari selatan yang dingin khususnya.  Antartika S: daerah yang memiliki kaki dan sayap berselaput yang dimodifikasi sebagai sirip S: .  S: 250 Perintah lengkap C: DEFINE shortcake S: 150 2 definisi ditemukan: list berikut S: 151 "shortcake" wn "WordNet 1.5" : teks berikut S: shortcake S: 1. n: biskuit sangat pendek yang diolesi dengan buah manis dan kami  S: krim kocok S: .  S: 151 "Shortcake" web1913 "Webster's Dictionary (1913)" : teks berikut S: Shortcake S: Short"cake`, n. S: Kue sarapan tanpa pemanis yang disingkat dengan mentega atau lemak babi, S: digulung tipis, dan dipanggang . S: . S: 250 Perintah selesai C: DEFINE abcdefgh S: 552 Tidak cocok Faith & Martin Informational [Page 24]


 RFC 2229 A Dic  Protokol Server tionary Oktober 1997

 C: keluar S: 221 Menutup koneksi 
8.2.  Contoh 2 - TAMPILKAN perintah, perintah MATCH
 C: SHOW DB S: 110 3 database hadir: daftar berikut S: wn "WordNet 1.5" S: foldoc "Free On -Line Dictionary of Computing" S: jargon "Hacker Jargon File" S: .  S: 250 Perintah selesai C: SHOW STRAT S: 111 5 strategi yang ada: daftar mengikuti S: tepat "Cocokkan kata dengan tepat" S: awalan "Cocokkan awalan kata" S: substring "Cocokkan substring di mana pun di kata" S: regex "Cocokkan menggunakan ekspresi reguler" S: reverse "Mencocokkan kata-kata yang diberikan kata kunci definisi" S: .  S: 250 Perintah selesai C: MATCH foldoc regex "s.si" S: 152 7 kecocokan ditemukan: daftar berikut S: foldoc Fast SCSI S: foldoc SCSI S: foldoc SCSI-1 S: ​​foldoc SCSI-2 S: foldoc SCSI- 3 S: foldoc Ultra-SCSI S: foldoc Wide SCSI S: .  S: 250 Perintah selesai C: COCOK dengan substring "abcdefgh" S: 552 Tidak cocok Faith & Martin Informational [Page 25]
 
 
RFC 2229 A Dictionary Server Protocol Oktober 1997
 8.3.  Contoh 3 - Waktu henti server  C: [ client initiates connection ] S: 420 Server sementara tidak tersedia C: [ client initiates connection ] S: 421 Server dimatikan atas permintaan operator  8.4 .  Contoh 4 - Otentikasi C: [ client initiates connection ] S: 220 dict.org dictd (versi 0.9)  C: TAMPILKAN DB S: 110 1 database hadir: daftar berikut S: gratis "Database gratis" S: .  S: 250 Perintah selesai C: AUTH joesmith otentikasi-string S: 230 Otentikasi berhasil C: SHOW DB S: 110 2 database hadir: daftar berikut S: gratis "Database gratis" S: berlisensi "Database berlisensi lokal" S: .  S: 250 Perintah selesai 
9.  Pertimbangan Keamanan RFC ini tidak menimbulkan masalah keamanan.  Faith & Martin Informational [Page 25] 


 RFC 2229 A Dictionary Server Protocol Oktober 1997 
10.  Referensi [US Patents 1261167 (1918) and 1435663        (1922)] US-ASCII.  Set Karakter Berkode - Kode Standar Amerika 7-Bit untuk Pertukaran Informasi.  Standar ANSI X3.4-1986, ANSI, 1986. [Page 2] Howe, Denis, ed.  Kamus Komputasi On-Line Gratis,  [RFC2044] ISO/IEC 10646-1:1993.  Standar Internasional -- Teknologi informasi -- Universal Multiple-Octet Coded Character Set (UCS) -- Bagian 1: Arsitektur dan Bidang Multibahasa Dasar.  UTF-8 dijelaskan dalam Lampiran R, diadopsi tetapi belum diterbitkan.  UTF-16 dijelaskan dalam Lampiran Q, diadopsi tetapi belum diterbitkan.  [JARGON] File Jargon peretas online, versi 4.0.0, 25 JULI 1996,  [KNUTH73] Knuth, Donald E. "The Art of Computer Programming", Volume 3: Sorting and Searching (Addison-Wesley Publishing Co., 1973, halaman 391 dan 392).  Knuth mencatat bahwa metode soundex awalnya dijelaskan oleh Margaret K. Odell dan Robert C. Russell [US Patents 1261167 (1918) and 1435663        (1922)].  [PZ85] Pollock, Joseph J. dan Zamora, Antonio, "Koreksi ejaan otomatis dalam teks ilmiah dan ilmiah," CACM, 27(4): April 1985, 358-368.  [RFC640] Postel, J., "Revised FTP Reply Codes", RFC 640, Juni, 1975. [RFC977] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, Agustus 1982. [RFC822] Crocker, D., "Standar untuk Format Pesan Teks Internet ARPA", STD 11, RFC 822, Agustus 1982. [RFC977] Kantor, B., dan P Lapsley, "Protokol Transfer Berita Jaringan: Standar yang Diusulkan untuk Transmisi Berita Berbasis Aliran", RFC 977, Februari 1986. [RFC2045] Freed, N. , dan N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Bagian Satu: Format Badan Pesan Internet", RFC 2045, November 1996. Faith & Martin Informational [Page 27] 


RFC 2229 A Dictionary Server Protocol Oktober 1997
 [RFC1738] Berners-Lee, T., Masinter, L. dan M. McCahill , "Uniform Resource Locators (URL)", RFC 1738, Desember 1994. [RFC1760] Haller, N., "The S/KEY Sistem Kata Sandi Sekali Pakai", RFC 1760, Februari 1995. [RFC1985] Freed, N., dan A. Cargille, "Perpanjangan Layanan SMTP untuk Command Pipelining", RFC 1854, Oktober 1995. [RFC1939] Myers, J., dan M. Rose, "Post Office Protocol - Versi 3", STD 53, RFC 1939, Mei 1996. [RFC2044] Yergeau, F., "UTF-8, format transformasi Unicode dan ISO 10646", RFC 2044, Oktober 1996. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., dan T. Berners-Lee, "Protokol Transfer Hypertext -- HTTP/1.1", RFC 2068, Januari 1997. [RFC2078] Linn, J., "Antarmuka Program Aplikasi Layanan Keamanan Umum, Versi 2", RFC 2078, Januari 1997. [RFC2222] Myers, J., "Lapisan Otentikasi dan Keamanan Sederhana (SASL )", RFC 2222, Oktober 1997. [WEB1913] Webster's Revised Unabridged Dictionary (G & C. Merriam Co., 1913, diedit oleh Noah Porter).  Versi online disiapkan oleh MICRA, Inc., Plainfield, NJ dan diedit oleh Patrick Cassidy .  Untuk informasi lebih lanjut, lihat , dan  [WORDNET] Miller, GA (1990), ed.  WordNet: Basis Data Leksikal On-Line.  Jurnal Internasional Leksikografi.  Volume 3, Nomor 4. Faith & Martin Informational [Page 28] 


  RFC 2229 A Dictionary Server Protocol Oktober 1997 

11.  Ucapan Terima Kasih  Terima kasih kepada Arnt Gulbrandsen dan Nicolai Langfeldt atas banyak diskusi yang bermanfaat.  Terima kasih kepada Bennet Yee, Doug Hoffman, Kevin Martin, dan Jay Kominek untuk pengujian ekstensif dan umpan balik pada implementasi awal server DICT.  Terima kasih kepada Zhong Shao atas saran dan dukungannya.  Terima kasih kepada Brian Kanto, Phil Lapsley, dan Jon Postel karena telah menulis RFC teladan yang dikonsultasikan selama persiapan dokumen ini.  Terima kasih kepada Harald T. Alvestrand, yang komentarnya membantu menyempurnakan dokumen ini.  12.  Alamat Penulis  Rickard E. Faith EMail: Faith@cs.unc.edu (atau Faith@acm.org) Bret Martin EMail: bamartin@miranda.org sebagian besar pekerjaan ini diselesaikan saat Bret Martin masih menjadi mahasiswa di Universitas Yale.  Faith & Martin Informational [Page 29] 



 
RFC 2229 A Dictionary Server Protocol Oktober 1997
 13.  Pernyataan Hak Cipta Lengkap  Hak Cipta (C) Masyarakat Internet (1997).  Seluruh hak cipta.  Dokumen ini dan terjemahannya dapat disalin dan diberikan kepada orang lain, dan karya turunan yang mengomentari atau menjelaskannya atau membantu penerapannya dapat disiapkan, disalin, diterbitkan dan dan didistribusikan, seluruhnya atau sebagian, tanpa batasan dalam bentuk apa pun. , dengan ketentuan bahwa pemberitahuan hak cipta di atas dan paragraf ini disertakan pada semua salinan dan karya turunan tersebut.  Namun, dokumen ini sendiri tidak boleh dimodifikasi dengan cara apa pun, seperti dengan menghapus pemberitahuan hak cipta atau referensi ke Internet Society atau organisasi Internet lainnya, kecuali jika diperlukan untuk tujuan mengembangkan standar Internet di mana prosedur untuk hak cipta ditentukan dalam proses Standar Internet harus diikuti, atau sebagaimana diperlukan untuk menerjemahkannya ke dalam bahasa selain bahasa Inggris.  Izin terbatas yang diberikan di atas bersifat abadi dan tidak akan dicabut oleh Internet Society atau penerus atau penerimanya.  Dokumen ini dan informasi yang terkandung di sini disediakan atas dasar "APA ADANYA" dan MASYARAKAT INTERNET DAN SATGAS TEKNIK INTERNET MENAFIKAN SEMUA JAMINAN, TERSURAT MAUPUN TERSIRAT, TERMASUK NAMUN TIDAK TERBATAS PADA JAMINAN BAHWA PENGGUNAAN INFORMASI DI SINI TIDAK AKAN MELANGGAR HAK APA PUN ATAU JAMINAN TERSIRAT APA PUN UNTUK DIPERDAGANGKAN ATAU KESESUAIAN UNTUK TUJUAN TERTENTU.  Informasi Faith & Martin [Page 30]  
Baca selengkapnya