RDAP’te Alan Adı Durumu ve Kayıt Olayları Nasıl Ayrılır?

Alan adınızla ilgili bir RDAP yanıtını açtığınızda, bir tarafta status, diğer tarafta events görüp ikisinin de aynı şeyi anlattığını düşünebilirsiniz. Özellikle yaklaşan bir sona erme tarihi görülünce, alan adının durumu hakkında acele bir sonuca varmak kolaydır. RDAP alan adı durumu ve olayları aynı tür bilgi değildir: status kayıtlı nesnenin durumunu belirtirken events nesne örneğinde gerçekleşmiş olayları kaydeder. Bu ayrımı kurmak, elinizdeki yanıtı daha sakin ve doğru okumaya yardım eder.

Kısa özet

• Status, kayıtlı nesnenin durumunu belirten bir dizge listesidir; olay günlüğü değildir.
• Events, nesne örneğinde gerçekleşmiş olayları temsil eder ve her olayda olayın tarih-saatini taşıyan eventDate bulunur.
• Gelecek tarihli olaylar mümkündür; sona erme zamanı buna örnek olabilir. Bu nedenle bir olay tarihini durum bilgisinin yerine koymamak gerekir.
• RDAP yanıtlarında bazı kayıt verileri bulunmayabilir; tanınmayan ek üyeler de status veya events gibi yorumlanmamalıdır.

Önce iki soruyu ayırın

RDAP yanıtını okurken önce iki ayrı soru sorun: “Alan adı nesnesinin durumu ne?” ve “Bu nesneyle ilgili hangi olaylar kaydedilmiş?” İlk sorunun karşılığı status alanıdır. RFC 9083, status yapısını kayıtlı nesnenin durumunu belirten dizgelerden oluşan bir dizi olarak tanımlar.

İkinci sorunun karşılığı events alanıdır. Bu yapı, bir nesne sınıfının örneğinde gerçekleşmiş olayları temsil eder. Dolayısıyla events alanı, status alanının geçmişe dönük kopyası ya da alternatif adı değildir. Birinin durum, diğerinin olay bilgisi taşıdığını baştan kabul etmek, yorum hatalarını azaltır.

• Status: Kayıtlı nesnenin durumunu belirten dizge listesi.
• Events: Nesne örneğinde gerçekleşmiş olayların kayıtları.

Kaynak: [2]

Status alanını durum bilgisi olarak okuyun

Status alanının görevi bir olayın ne zaman yaşandığını anlatmak değildir. Bu alan, kayıtlı nesnenin durumunu belirten bir liste olarak tanımlanır. Alan adının durumu hakkında değerlendirme yaparken status içeriğini, events listesindeki tarihlerin yerine koymadan ayrı inceleyin.

Buradaki önemli sınır şudur: Sağlanan RDAP tanımı status alanının bir durum listesi olduğunu söyler, ancak tek başına her olası işletimsel sonucu bu makalede çıkarabileceğiniz anlamına gelmez. Bir status değerine dayanarak işlem planlamadan önce, elinizdeki RDAP yanıtındaki açık bilgiyi ve kayıt kuruluşunuzun sunduğu yönetim bilgisini birbirinden ayırın.

• Bir tarihi status bilgisi gibi okumayın.
• Status ile events alanlarının görevlerini birleştirmeyin.
• Yanıtta açıkça bulunmayan kayıt verisini var saymayın.

Kaynak: [2]

Events alanını zaman çizelgesi olarak okuyun

Events alanındaki her kayıt bir olayla ilgilidir ve eventDate bu kaydın zorunlu parçasıdır. eventDate, olayın gerçekleştiği tarih ve saati içerir. Bu nedenle events bölümünü, alan adı nesnesiyle ilişkilendirilmiş olayların zaman bilgisi olarak okuyabilirsiniz.

Örnek senaryo: Bir RDAP yanıtında events altında tarih-saat içeren bir kayıt gördüğünüzü varsayalım. Bu kayıt, ilgili olayın ne zaman gerçekleştiğini ya da ileri tarihliyse ne zaman gerçekleşmesinin belirtildiğini anlatır. Tek başına bu tarih, status alanındaki durum bilgisinin yerine geçmez. Durum bilgisi için status alanına, zamanla ilgili kayıt için events alanına bakmak gerekir.

• Her olay kaydında eventDate bulunur.
• eventDate olayın tarih ve saatini taşır.
• Olay zamanı ile nesne durumu farklı bilgi türleridir.

Kaynak: [2]

Sona erme tarihini durumla karıştırmayın

RDAP, gelecekte tarihli olaylara izin verir. Standartta bunun bir kullanım alanı, bir nesnenin kayıt kuruluşunda ne zaman sona ereceğini belirtmektir. Bu nedenle events altında gelecekteki bir sona erme zamanının bulunması mümkündür.

Bu bilgi değerlidir, fakat okuma sırası önemlidir. Gelecekteki tarih, geleceğe ilişkin bir olay bilgisidir; status ise kayıtlı nesnenin durumunu belirten alandır. Örnek senaryo: Bir yanıt gelecekteki bir sona erme olayını gösteriyorsa, bunu yaklaşan zaman bilgisi olarak not edin. Ardından alan adının durumunu değerlendirmek için status alanını ayrı okuyun. İki alanı tek bir hükme dönüştürmemek, belirsizliği azaltır.

• Events gelecekte tarihli olabilir.
• Sona erme zamanı, gelecek tarihli olay kullanımına örnektir.
• Gelecekteki olay tarihi status bilgisinin yerine geçmez.

Kaynak: [2]

Eksik alanlar ve özel üyeler karşısında temkinli olun

Bir RDAP yanıtında kayıt verisi taşıyan bazı JSON üyeleri hiç bulunmayabilir. Sunucular, zorunlu olmayan kayıt verisi üyelerini kendi politikalarına göre atlayabilir. Bu yüzden events görünmüyorsa, yalnızca bu yanıta bakarak bir olay listesi olmadığı sonucunu kesin biçimde kurmayın; alanın yanıt içinde bulunmadığını söylemekle yetinin.

RDAP sunucuları standartta belirtilmeyen ek JSON üyeleri de ekleyebilir. İstemcilerin tanımadıkları üyeleri görmezden gelmesi önerilir. Okurken de aynı yaklaşım yararlıdır: Tanımadığınız bir alanı, adı benzer görünüyor diye status veya events ile eş tutmayın. Önce bunun standart bir alan olup olmadığını doğrulayın.

• Zorunlu olmayan kayıt verisi üyeleri yanıtta olmayabilir.
• Tanınmayan JSON üyeleri hata anlamına gelmez.
• Standart dışı bir alanı status ya da events olarak yorumlamayın.

Kaynak: [2]

Pratik bir okuma sırası oluşturun

Bir RDAP yanıtını incelerken önce status alanını bulun ve bunu durum bilgisi olarak ayrı not edin. Sonra events alanı varsa olay kayıtlarını ve eventDate değerlerini zaman bilgisi olarak inceleyin. Gelecekte tarihli bir olay görürseniz, bunun geleceğe ilişkin olabileceğini dikkate alın; özellikle sona erme zamanının bu şekilde belirtilebildiğini unutmayın.

Son olarak yanıtın eksik veya tanınmayan üyeler içerebileceğini hesaba katın. Bu yaklaşım, görünmeyen veriyi varsaymayı ve ek alanlara gereğinden fazla anlam yüklemeyi önler. RDAP yanıtı size iki farklı bilgi türü sunar: durum ve olay. Sağlıklı değerlendirme, bunları ayrı tutmakla başlar.

• Status bilgisini ayrı kaydedin.
• Events kayıtlarındaki eventDate değerlerini ayrı inceleyin.
• Gelecek tarihli olayları durum bilgisinin yerine koymayın.
• Bulunmayan veya tanınmayan üyelerden kesin sonuç çıkarmayın.

Kaynak: [2]

Uygulama kontrol listesi

• Status alanını olay kaydı olarak değil, kayıtlı nesnenin durum listesi olarak okuyun.
• Events alanını varsa olay kayıtları için inceleyin.
• Her olay kaydındaki eventDate değerini olayın tarih-saat bilgisi olarak değerlendirin.
• Gelecekteki bir olay tarihini durum bilgisiyle eş tutmayın.
• Sona erme zamanının geleceğe tarihli olay olarak belirtilebileceğini dikkate alın.
• Yanıtta bulunmayan isteğe bağlı kayıt verisini varsaymayın.
• Tanınmayan JSON üyelerini status veya events olarak yorumlamayın.

RDAP yanıtında status, kayıtlı alan adı nesnesinin durumunu belirten bir listedir; events ise nesneyle ilgili gerçekleşmiş olayları ve bunların zamanını taşır. Gelecek tarihli olaylar, sona erme zamanı gibi bilgileri gösterebilir. Bu nedenle durum bilgisini status alanından, tarihsel veya ileri tarihli olay bilgisini events alanından okuyun; yanıtın eksik ya da standart dışı üyeler içerebileceğini de göz önünde bulundurun.

Sık sorulan sorular

RDAP’te status alanı bir olay günlüğü müdür?

Hayır. Status, kayıtlı nesnenin durumunu belirten dizgelerden oluşan bir listedir. Olayları temsil eden yapı events alanıdır.

Events içindeki tarih alanı zorunlu mudur?

Evet. Bir olay kaydındaki eventDate, olayın gerçekleştiği tarih ve saati içeren zorunlu bir dizgedir.

RDAP’te sona erme zamanı gelecekteki bir olay olarak görünebilir mi?

Evet. RDAP gelecekte tarihli olaylara izin verir; kayıt kuruluşundaki sona erme zamanını belirtmek bunun kullanım alanlarından biridir.

RDAP yanıtında events alanı yoksa ne anlama gelir?

Kayıt verisi taşıyan zorunlu olmayan JSON üyeleri, sunucunun politikasına göre yanıtta bulunmayabilir. Bu nedenle alanın yokluğu, yalnızca bu yanıtta yer almadığını gösterir.

Kaynaklar

[2] rfc9083.txt