stanford-oval/wikipedia huggingface dataset:
Google ürünleri listesi

Google ürünlerine ait ekran yakalama görüntüsü
Google ürünleri listesi Google tarafından satın alınan tüm ana masaüstü, mobil ve çevrimiçi ürünleri içerir. Bu ürünler son ürün ya da beta sürümler olabilir. Liste ayrıca kullanımdan kaldırılmış, birleştirilmiş ya da tekrar isimlendirilmiş ürünleri de içerir. Ürünlerin içinde olan özellikler ayrıca listelenmemiştir.
Mobil > Web uygulamaları

Bu ürünlere mobil bir cihaz üzerinde bir tarayıcıdan erişilebilir.
Mobil > Bağımsız uygulamalar

Bu ürünlerin bir kısmı indirilerek bir mobil cihazdan çalıştırılmalıdır.
Web

Bu ürünlere bir web tarayıcı üzerinden ulaşılmalıdır.
Web > Haritalama

Google uygulamalar sitesine ait ekran yakalama görüntüsü
Programlayıcı (donanım)

Programlayıcı (çip programlayıcı ya da devre programlayıcı) EPROM, EEPROM, Flash, PAL, FPGA ya da programlanabilir lojik devreler gibi geçici olmayan (enerji olmasa da saklanan veri kaybolmayan) dijital devrelerin biçimlendirilmesinde kullanılan elektronik cihazlardır.
Galep-5 Programlayıcı
Özelliği

Devreyi programlamak için gömülü sistem programlayıcı üzerindeki ZIF soket içerisine yerleştirilir ya da programlayıcı devreye ara parçalar ile direkt olarak bağlanır. Bu işlemden sonra yüklenmek istenilen veri devreye sinyaller ile bağlanılan uçlara gönderilir. Bazı devreler programlama verisini almak için seri haberleşme arayüzünü kullanır (JTAG arayüzü ).
Genellikle cihazlar bilgisayarların yazıcı konektörüne, USB girişine ya da LAN arayüzüne bağlanarak kullanılırlar. Bilgisayar üzerindeki yazılım veriyi programlayıcıya bu bağlantı üzerinden gönderir. Ardından devre ve arayüz türü (her devre farklı sayıda bacak sayısına sahip olabilir) seçilir ve programlama işlemi başlar.
Programlayıcılar satın alınabileceği gibi internet üzerinde bulunan acık kaynak donanım projeleri sayesinde isteyen herkes tarafından da yapılabilir. 18 Eylül 2020 tarihinde Wayback Machine sitesinde arşivlendi.
Programlayıcı türleri

Dört genel türde programlayıcı vardır.
Gang programlayıcılar, toplu üretim için kullanılırlar.
Geliştirme programlayıcıları, proje geliştirmek ve küçük çaptaki üretimler için kullanılır.
Cep tipi programlayıcılar proje geliştirmek ve genellikle servis hizmeti sırasında kullanılırlar.
Özel üretim programlayıcılar, sadece belirli türedeki devreleri programlamak için kullanılırlar
Adafruit TinyISP AVR Programlayıcı
WebSocket

WebSocket
WebSocket, tek bir TCP bağlantısı üzerinden tam çift yönlü iletişim kanalı sağlayan bir bilgisayar iletişim protokolüdür. WebSocket protokolü IETF tarafından 2011 yılında RFC 6455 ile standart hale getirilmiş ve WebIDL içerisindeki WebSocket API W3C tarafından standart hale getirilmektedir.
WebSocket, web tarayıcılarında ve web sunucularında uygulanmak üzere tasarlanmıştır, fakat herhangi bir istemci veya sunucu uygulaması tarafından uygulanabilmektedir. WebSocket protokolü, TCP tabanlı bağımsız bir protokoldür. HTTP ile tek ilişkisi, HTTP sunucuları tarafından bir upgrade isteği olarak yorumlanmasıdır. WebSocket protokolü, sunucuya ve sunucudan gerçek zamanlı veri aktarımını sağlayarak, tarayıcı ile web sunucusu arasında etkileşimi sağlamaktadır. Bu, sunucunun istemci istemeden tarayıcıya içerik gönderebileceği ve bağlantıyı açık tutarak istediği zaman mesaj alabilmesini veya gönderebilmesini sağlayan standart bir yöntem ile sağlanmaktadır. Bu şekilde, tarayıcı ile sunucu arasında iki yönlü devam eden bir iletişim gerçekleşebilmektedir. İletişim TCP 80 portu (veya TLS ile şifrelenmiş bağlantılarda 443 portu) üzerinden gerçekleşmektedir ve bu, güvenlik duvarı kullanarak Internet web trafiğini engelleyen ortamlar için bir avantaj olmaktadır. Benzer iki yönlü sunucu-tarayıcı iletişimi Comet gibi standart olmayan stopgap teknolojileri tarafından sağlanmaktaydı.
WebSocket protokolü, Google Chrome, Microsoft Edge, Internet Explorer, Firefox, Safari ve Opera dahil pek çok tarayıcı tarafından desteklenmektedir. WebSocket ayrıca sunucu üzerindeki web uygulamalarının da desteğini gerektirmektedir.
Genel bakış

HTTP’den farklı olarak, WebSocket protokolü tam çift yönlü iletişim sağlamaktadır. İlave olarak, WebSocket TCP protokolünün üzerinde mesaj akışına imkân tanımaktadır. TCP tek başına, mesaj kavramı kullanmadan byte akışı ile ilgilenmektedir. WebSocket protokolünden önce, 80 protokolü üzerinden tam çift yönlü iletişim Comet kanalları üzerinden yapılabilmekteydi; fakat, Comet uygulaması çok yaygın değildir ve TCP el sıkışması ve HTTP başlıkları yüzünden küçük mesajlar için verimsiz olmaktadır. WebSocket protokolü, webin güvenlik ilkelerini etkilemeksizin bu problemleri çözmeyi amaçlamaktadır.
WebSocket protokolü tanımı, şifreli ve şifresiz trafik için kullanılan iki yeni uniform resource identifier (URI) formatı olan ws ve wss ifadelerini tanımlamaktadır. Şema adı ve fragment dışında (# desteklenmemektedir), diğer URI bileşenleri için genel URI biçimini kullanacak şekilde tanımlanmıştır.
Tarayıcının Geliştirici Araçlarını kullanarak, geliştiriciler WebSocket paketleri ile WebSocket el sıkışmasını inceleyebilmektedir.
Tarih

WebSocket, HTML5 tanımında ilk olarak, TCP tabanlı soket API’si yerine TCPConnection olarak anılmıştır. Haziran 2008’de, Michael Carter tarafından, WebSocket olarak bilinen protokolün ilk versiyonu olan bir takım çalışma gerçekleştirilmiştir.
Bunun üzerine kısa bir süre sonra Ian Hickson ve Michael Carter tarafından #whatwg IRC chat odasındaki işbirliği ile WebSocket ismi verilmiştir ve sonrasında Ian Hickson tarafından HTML5 tanımında yer alacak şekilde yazılmıştır ve Michael Carter tarafından bir blog üzerinde duyurulmuştur. Aralık 2009’da, varsayılan olarak WebSocket protokolü standartlarını tamamen uygulayan ilk tarayıcı Google Chrome 4 olmuştur. Sonrasında, Şubat 2010’da WebSocket protokolünün geliştirilmesi, W3C ve whatwg IRC grubundan IET’ye geçmiştir ve Ian Hickson gözetiminde iki değişime uğramıştır.
Protokol tamamlandıktan ve birden çok tarayıcı tarafından varsayılan olarak desteklendikten sonra, Aralık 2011’de Ian Fette gözetiminde RFC tamamlanmıştır.
Browser implementation

WebSocket protokolünün güvenli bir versiyonu, Firefox 6, Safari 6, Google Chrome 14, Opera 12.10 ve Internet Explorer 10 tarafından uygulanmaktadır. Detaylı bir protokol test raporu bu tarayıcıların spesifik protokol özelliklerine uyumluluğunu listelemektedir.
Protokolün daha eski ve daha az güvenli bir versiyonu, Opera 11, Safari 5 ve iOS 4.2'de bulunan Safari mobil versiyonunda uygulanmıştır. iOS7'deki BlackBerry tarayıcısı WebSocket protokolünü uygulamaktadır. Açıklıklar yüzünden, Firefox 4 ve 5 ile Opera 11 üzerinde devre dışı bırakılmıştır.
Ayrıca, SPDY üzerinde WebSocket protokolünün deneysel bir uygulamasına imkân tanıyan Google Chrome için --enable-websocket-over-spdy komut satırı anahtarı bulunmaktadır.
| Protokol | Taslak Tarihi  | Internet Explorer | Firefox (PC) | Firefox (Android) | Chrome (PC, Mobile) | Safari (Mac, iOS) | Opera (PC, Mobile) | Android Browser  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| hixie-7517 Mart 2017 tarihinde Wayback Machine sitesinde arşivlendi. | 4 Şubat 2010 | 4 | 5.0.0 |  |  |  |  |  |
| hixie-76 20 Mart 2017 tarihinde Wayback Machine sitesinde arşivlendi.  hybi-00 20 Mart 2017 tarihinde Wayback Machine sitesinde arşivlendi. | 6 Mayıs 2010  23 Mayıs 2010 | 4.0 (devre dışı bırakıldı) | 6 | 5.0.1 | 11.00 (disabled) |  |  |  |
| 7 hybi-07 20 Mart 2017 tarihinde Wayback Machine sitesinde arşivlendi. | 22 Nisan 2011 | 6 |  |  |  |  |  |  |
| 8 hybi-10 20 Mart 2017 tarihinde Wayback Machine sitesinde arşivlendi. | 11 Temmuz 2011 | 7 | 7 | 14 |  |  |  |  |
| 13 RFC 6455 | Aralık 2011 | 10 | 11 | 11 | 16 | 6 | 12.10 | 4.4 |
Protokol El Sıkışması

Bir WebSocket bağlantısı kurmak için istemci, aşağıdaki örnekte gösterildiği gibi sucununun WebSocket el sıkışma cevabı gönderdiği bir WebSocket el sıkışma isteği göndermektedir.
İstemci isteği (HTTP’de olduğu gibi, her bir satır \r\n ile bitmektedir ve sonda ilave bir boş satır bulunmak zorundadır):
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com
Sunucunun cevabı:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
El sıkışma, sunucuların aynı port üzerinden hem HTTP bağlantılarını hem de WebSocket bağlantılarını işleyebilmesi açısından HTTP’ye benzemektedir. Bağlantı kurulduğunda, iletişim, HTTP protokolüne uymayan iki taraflı bir ikili protokole dönüşmektedir.
Upgrade başlığına ek olarak, istemci base64 ile kodlanmış rastgele bytelardan oluşan bir Sec-WebSocket-Key başlığını da göndermektedir. Sunucu ise Sec-WebSocket-Accept başlığı ile anahtar değerinin özeti ile cevap vermektedir. Bu yöntem, önceki bir WebSocket trafiğinin tekrar oynatılmasını engellemeye çalışmaktadır ve herhangi bir kimlik doğrulama, gizlilik veya bütünlük kontrolü sağlamamaktadır. Özet fonksiyonu 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 sabit değerini Sec-WebSocket-Key başlığındaki (base64 kodlaması çözülmemiş) değere eklemekte, SHA-1 özet fonksiyonunu uygulamakta ve sonucu base64 kullanarak kodlamaktadır.
Bağlantı kurulduktan sonra, istemci ve sunucu WebSocket verisini tam çift yönlü modda gönderebilmektedir. Veri, payload tarafından takip edilen küçük bir başlık ile minimal bir şekilde çerçevelenmektedir. WebSocket iletişimi, tek bir mesajın birkaç veri çerçevesi içerisine dağılabileceği mesajlarla tanımlanmaktadır. Bu, verinin ilk kısmının bilindiği fakat mesajın toplam büyüklüğünün bilinmediği durumlarda, mesajların gönderilebilmesine izin vermektedir (FIN biti ile işaretlenip sona erişilene kadar veri çerçevelerini arka arkaya göndermektedir). Protokol üzerinde yapılan eklentilerle, farklı veri akışlarının eşzamanlı olarak çoklanması için de kullanılabilmektedir (örneğin bir soketin kullanımını tek bir büyük payload için tekelleştirilmesini önlemek için).
(Güvenlik açısından) Sunucu tarafında bağlantı kurulurken Origin başlığının doğrulanması, Siteler Arası WebSocket Çalma (Cross-Site WebSocket Hijacking) saldırılarına karşı koruma açısından önem taşımaktadır. Bu saldırı bağlantı çerezler veya HTTP kimlik doğrulaması ile doğrulandığında mümkün olabilmektedir. WebSocket üzerinden hassas veriler iletilirken, WebSocket bağlantısını doğrulamak için token veya benzer koruma mekanizmalarının kullanılması faydalı olacaktır.
Proxy geçişi

WebSocket protokolü istemci uygulamaları, web tarayıcısının hedef makine ve porta bağlanırken bir vekil sunucu kullanıp kullanmadığını tespit etmeye çalışmaktadır ve eğer kullanıyorsa, kalıcı bir tünel oluşturmak için HTTP CONNECT metodunu kullanmaktadır.
WebSocket protokolünün kendisi vekil sunucuların ve güvenlik duvarlarının farkında olmasa da, HTTP’ye uygun bir el sıkışmayı desteklemektedir ve böylece HTTP sunucularının varsayılan HTTP ve HTTPS portlarını (80 ve 443) bir WebSocket ağ geçidiyle veya sunucusuyla paylaşmasına izin vermektedir. WebSocket protokolü, WebSocket ve Güvenli WebSocket bağlantılarını belirtmek için ws:// ve wss:// öneklerini tanımlamaktadır. Her iki yöntemde, bağlantıyı WebSocket’a yükseltmek için bir HTTP yükseltme mekanizması kullanmaktadır. Bazı vekil sunucular şeffaftır ve WebSocket ile çalışabilmektedir; diğerleri ise WebSocket protokolünün çalışmasını engelleyecektir ve bağlantının sonlanmasına yol açacaktır. Bazı durumlarda, ilave vekil sunucu yapılandırması gerekebilmektedir ve bazı vekil sunucuların WebSocket protokolünü desteklemesi için yükseltilmesi gerekebilmektedir.
Eğer şifrelenmemiş WebSocket trafiği, WebSocket desteği olmayan bir şeffaf vekil sunucu üzerinden akıyorsa, bağlantı muhtemelen başarısız olacaktır.
Eğer şifreli WebSocket bağlantısı kullanılıyorsa, Güvenli WebSocket bağlantısında Transport Layer Security (TLS) kullanılması, tarayıcı bir vekil sunucu kullanacak şekilde yapılandırıldığında, HTTP CONNECT komutunun çalıştırılmasını sağlamaktadır. Bu, Güvenli WebSocket istemcisi ile WebSocket sunucusu arasında HTTP vekil sunucusu aracılığıyla düşük seviye birebir TCP iletişimini sağlayan bir tünel kurmaktadır. Şeffaf vekil sunucularda, tarayıcı vekil sunucunun varlığından habersizdir ve hiçbir HTTP CONNECT paketi yollanmamaktadır. Ancak, kablodaki trafik şifreli olduğu için, aradaki şeffaf vekil sunucular şifreli trafiğin geçmesine izin verebilmektedir. Bu yüzden, Güvenli WebSocket kullanıldığında, WebSocket bağlantısının başarılı olma ihtimali artmaktadır. Şifrelemenin olması kaynak kullanımı açısından bir miktar yük oluşturacaktır, fakat güvenli bir tünel üzerinden geçebileceği için daha yüksek bir başarı oranı sağlamaktadır.
2010 ortalarında verilen bir taslak (hixie-76 versiyonu) ters vekil sunucularla ve ağ geçitleriyle uyumluluğu, başlıklardan sonra 8 byte’dan oluşan bir anahtar eklediği ve bu anahtarı Content-Length: 8 başlığında belirtmediği için bozmuştur. Bu veri tüm aradaki cihazlar tarafından iletilmeyeceği için protokol başarısızlığına yol açabilmektedir. Bu yüzden, daha yeni taslaklar (örneğin hybi-09) bu problemi çözerek anahtar veriyiSec-WebSocket-Key başlığına koymaktadır.
Çap Protokolü

Çap, Uzun Vadeli Evrim (LTE) ve IP Multimedya Sistemlerinde (IMS) kimlik doğrulama, yetkilendirme ve muhasebe (AAA) bilgilerini değiş tokuş etmek için kullanılan yeni nesil endüstri standardı bir protokoldür. Daha önceki RADIUS protokolünden evrimleşmiştir. RADIUS "Remote Authentication Dial-in User Service" tanımından alan ve uygulama katmanlı protokollerden biridir. İletişim yöntemi olarak Network UDP protokolünü kullanır. Server (Sunucu) / Client (İstemci) mimarisini kullanır.İnternet protokol paketindeki uygulama katmanı protokollerine aittir.
Çap Uygulamaları, Genişletilebilir Kimlik Doğrulama Protokolü (EAP) ile kullanım için olanlar gibi yeni komutlar ve/veya nitelikler ekleyerek temel protokolü genişletir.
RADIUS ile karşılaştırma

Adı kelime oyunu, (çapın yarıçapının iki katı) öncülü olan RADİUS protokolünden türetilmiştir. Çap doğrudan geriye dönük olarak uyumlu değildir, ancak RADİUS için bir yükseltme yolu sağlar. Çapın sağladığı ancak RADİUS ta eksik olan ana özellikler şunlardır:
SCTP desteği
Yetenek pazarlığı
Uygulama katmanı onayları; Çap, yük devretme yöntemlerini ve durum makinelerini tanımlar (RFC 3539 )
Genişleme; yeni komutlar tanımlanabilir
32 Bit sınırlarında hizalama
Ayrıca: RADIUS gibi, hem yerel hem de dolaşımdaki AAA durumlarında çalışması amaçlanmıştır. UDP kullanan RADIUS'tan farklı olarak TCP veya SCTP kullanır. RADIUS'tan farklı olarak şifreleme içermez, ancak aktarım düzeyinde güvenlik (IPSEC veya TLS) ile korunabilir. AV tanımlayıcısının temel boyutu, temel AV tanımlayıcı boyutu olarak 8 bit kullanan radius'un aksine 32 bittir. RADIUS gibi, durum bilgisi olan modların yanı sıra durumsuz modları da destekler. RADIUS gibi uygulama katmanı onayını destekler ve yük devretmeyi tanımlar. Çap, 3GPP standartları tarafından tanımlanan birçok farklı arabirim için kullanılır ve her arabirim tipik olarak yeni komutlar ve nitelikler tanımlar.
Uygulamalar

Çap Uygulaması bir yazılım uygulaması değildir, ancak Çap temel protokolünün, hem yerel hem de dolaşım durumlarında ağ erişimi veya IP mobilitesi gibi uygulamalar için bir Kimlik Doğrulama, Yetkilendirme ve Hesaplama (AAA) çerçevesi sağlaması amaçlanmıştır. RFC 6733 tüm Diameter uygulamaları tarafından kullanılan mesaj formatı, taşıma, hata raporlama, muhasebe ve güvenlik hizmetlerini belirtir. Bu belgede tanımlanan Çap temel protokolü, RFC 3588 ve RFC 5719'u geçersiz kılar ve tüm yeni Çap uygulamaları tarafından desteklenmesi gerekir. RFC 7075 te Çap protokolü, uygulamadan bağımsız bir "yönlendirme aracısı" tarafından kontrol edilen mesaj yeniden yönlendirme özelliği içerir. Bazı durumlarda, bir operatör, tek tek ana bilgisayarlar belirtmeden mesajları alternatif bir etki alanına yönlendirmek isteyebilir.RFC 7075 bir Çap sunucusunun veya proxy'nin (düğüm), Basit Adlandırma Yetkilisi İşaretçisi (S-NAPTR) dinamik eş bulma için kullanılmadığında böyle bir yeniden yönlendirmeyi gerçekleştirebileceği uygulamaya özel bir mekanizmayı belirtir. Bu yeni işlevi gerçekleştiren bir düğüme "Realm-based Redirect Server" adı verilir.RFC 6733 ve RFC 7075'te tanımlanan Çap temel protokolüne dayalı bir protokoldür (Eskiler: RFC 3588 ). Her uygulama bir uygulama tanımlayıcısı tarafından tanımlanır ve yeni komut kodları ve/veya yeni zorunlu AVP'ler (Öznitelik-Değer Çifti ) ekleyebilir. Bir isteğe bağlı AVP eklemek için yeni bir uygulama gerekmez.
Çap uygulamalarına örnekler:
Çap Mobil IPv4 Uygulaması (MobileIP, RFC 4004 )
Çap Ağ Erişim Sunucusu Uygulaması (NASREQ, RFC 7155 )(Eski: RFC 4005 )
Çap Genişletilebilir Kimlik Doğrulama Protokolü Uygulaması (RFC 4072 )
Çap Kredi-Kontrol Uygulaması (DCCA, RFC 8506 ])(Eski: RFC 4006 )
Çap Oturum Başlatma Protokolü Uygulaması (RFC 4740 )
3GPP IP Multimedya Alt Sistemindeki çeşitli uygulamalar
Ev Abone Sunucusu (HSS), aramaları ve oturumları işleyen IMS ağ varlıklarını destekleyen ana kullanıcı veritabanıdır. Abone konumu işlevi veya SLF, belirli bir kullanıcı profili ile ilişkili ev abone sunucusu (HSS) hakkında bilgi sağlayan bir IP multimedya alt sistemi içindeki bir işlevdir. Hem HSS hem de SLF, Çap protokolünü kullanarak iletişim kurar.
(Genel Önyükleme Mimarisi): Sunucusu İşlevi
Tarih

Çap protokolü ilk olarak 1998'de Pat R. Calhoun, Glen Zorn ve Ping Pan tarafından RADIUS'un sınırlamalarının üstesinden gelebilecek kimlik doğrulama, yetkilendirme ve muhasebe (AAA ) için bir çerçeve sağlamak üzere geliştirildi. RADIUS'un güvenilirlik, ölçeklenebilirlik, güvenlik ve esneklikle ilgili sorunları vardı. RADIUS, uzaktan erişim, IP mobilitesi ve ilke denetimi ile etkin bir şekilde başa çıkamazdı. Çap protokolü, istemciler tarafından AAA ve kaynak denetimi gerçekleştirmek için kullanılan bir ilke protokolünü tanımlar. Bu, tek bir sunucunun birçok hizmet için ilkeleri yönetmesine izin verir.
RADIUS gibi, Çap da AAA işlevselliği sağlar, ancak UDP yerine TCP ve SCTP kullanır, bu nedenle iletişim sorunlarının algılanmasını ve ele alınmasını bu protokollere devreder. Çap protokolü, 3. Nesil Ortaklık Projesi (3GPP) IP Multimedya Alt Sisteminin (IMS) geliştirilmesiyle daha da geliştirilmiştir. S6a, S6b, Gx, Gy, Sy, Rx, Cx, Dh, Dx, Rf, Ro, Sh ve Zh arayüzleri Çap uygulamaları tarafından desteklenir. Uzantıların kullanımı yoluyla protokol, proxy'leri, aracıları, güçlü güvenliği, mobil IP'yi, ağ erişim sunucularını (NASREQ), muhasebe ve kaynak yönetimini desteklemek için genişletilebilir olacak şekilde tasarlanmıştır.
Protokol açıklaması

Çap temel protokolü, RFC 6733 (Eskiler: RFC 3588 ve RFC 5719 ) tarafından tanımlanır ve bir AAA protokolü için minimum gereksinimleri tanımlar. Çap Uygulamaları, yeni komutlar, nitelikler veya her ikisini ekleyerek temel protokolü genişletebilir. Çap güvenliği IPsec veya TLS tarafından sağlanır. IANA, RFC 6733 bölüm 11.4'te belirtildiği gibi, Çapa 3868 numaralı TCP ve SCTP bağlantı noktası atamıştır.
Protokol açıklaması > Paket formatı

Çap, Mesaj (Paket) tabanlı protokoldür. İstek Mesajları ve Cevap Mesajları olmak üzere iki tür mesaj vardır. Paket, Çap mesajıyla ilgili bilgileri kapsüllemek için bir Çap başlığından ve değişken sayıda Öznitelik-Değer Çiftlerinden veya AVP'lerden oluşur.
| Bit ofseti |  0 |  1 |  2 |  3 |  4 |  5 |  6 |  7 |  8 |  9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 0 | versiyon | versiyon | versiyon | versiyon | versiyon | versiyon | versiyon | versiyon | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu | mesaj uzunluğu |
| 32 | R | P | E | T |   |   |   |   | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu | komut kodu |
64: uygulama kimliği
96: hop-by-hop kimliği
128: uçtan uca kimlik
160 ...: AVP'ler ...
Protokol açıklaması > Sürüm

Bu alan Çap Taban Protokolünün sürümünü gösterir. 2014 itibarıyla, desteklenen tek değer 1'dir  .
Protokol açıklaması > Mesaj uzunluğu

Mesaj Uzunluğu alanı, başlık alanları ve dolgulu AVP'ler dahil olmak üzere, Çap mesajının bayt cinsinden uzunluğunu gösterir.
Protokol açıklaması > Komut bayrakları

" R " (Talep) biti – Ayarlanmışsa, mesaj bir istektir. Temizlenirse, mesaj bir cevaptır.
" P " (Proxiable) biti – Ayarlanmışsa, mesaj düğümlenebilir, iletilebilir veya yeniden yönlendirilebilir. Silinmişse, mesaj yerel olarak İŞLENMELİDİR.
" E " (Hata) biti – Ayarlanırsa, mesaj bir protokol hatası içerir ve mesaj, bu komut için açıklanan CCF'ye uymaz. "E" bit seti olan mesajlara genellikle hata mesajları denir. Bu bit istek mesajlarında AYARLANMAMALIDIR.
" T " (Potansiyel olarak yeniden iletilen mesaj) biti – Bu işaret, yinelenen isteklerin kaldırılmasına yardımcı olmak için bir bağlantı yük devretme prosedüründen sonra ayarlanır. Henüz onaylanmayan istekleri yeniden gönderirken, bir bağlantı hatası nedeniyle olası bir yinelemenin göstergesi olarak ayarlanır.
Protokol açıklaması > Uygulama Kimliği

Uygulama Kimliği, mesajın hangi Çap uygulaması için geçerli olduğunu belirlemek için kullanılır. Uygulama bir kimlik doğrulama uygulaması, bir muhasebe uygulaması veya satıcıya özel bir uygulama olabilir.
Uygulama Kimliği, mesajın hangi Çap uygulaması için geçerli olduğunu belirlemek için kullanılır. Uygulama bir kimlik doğrulama uygulaması, bir muhasebe uygulaması veya satıcıya özel bir uygulama olabilir.
Başlıktaki Uygulama Kimliği alanının değeri, mesajda yer alan ilgili Uygulama Kimliği AVP'leriyle aynıdır. Örneğin Çap Kredi-Kontrol Uygulaması için Kredi-Kontrol-Talebi (CCR) ve Kredi-Kontrol-Cevap (CCA) Komutundaki Uygulama-Kimliği ve Yetki-Uygulama-Kimlik Özelliğinin değeri 4'tür.
| Uygulama Kimliği | Kısaltma | Tam Ad | Kullanım |
| --- | --- | --- | --- |
| 0 | Temel | Çap Ortak Mesajları | Çap protokolü dernek kurma/yırtma/bakım |
| 16777216 | Cx/Dx | 3GPP Cx/Dx | IMS I/S-CSCF'den HSS arayüzüne |
| 16777217 | Ş | 3GPP Ş | VoIP/IMS SIP Uygulama Sunucusu - HSS arayüzü |
| 16777236 | Rx | 3GPP Rx | Politika ve şarj kontrolü |
| 16777238 | gx | 3GPP Gx | Politika ve şarj kontrolü |
| 16777251 | S6a/S6d | 3GPP S6a/S6d | LTE Dolaşım sinyali |
| 16777252 | S13 | 3GPP 13 | EIR ve MME arasındaki arayüz |
| 16777255 | SLg | 3GPP LCS SLg | Konum hizmetleri |
| 16777345 | S6t | 3GPP S6t | SCEF ve HSS arasındaki arayüz |