← rfc/
╔══════════════════════════════════════════════════════════════════════════╗
RFC 733 · mail

ARPA AĞI METİN MESAJLARININ BİÇİMİ İÇİN STANDART

Yazar
NIC #41952
Kurum
Tarih
21 Kasım 1977
Durum
Network Working Group Yorum Talebi
Kanal
mail/

RFC 733

NIC #41952

Yerine Geçtiği Belgeler:

ARPA AĞI METİN MESAJLARININ BİÇİMİ İÇİN STANDART

21 Kasım 1977

David H. Crocker
The Rand Corporation

John J. Vittal
Bolt Beranek and Newman Inc.

Kenneth T. Pogran
Massachusetts Institute of Technology

D. Austin Henderson, Jr.
Bolt Beranek and Newman Inc.

(1) Bu çalışma, Savunma Bakanlığına bağlı Defense Advanced Research Projects Agency tarafından N00014-75-C-0661, MDA903-76-C-0212 ve DAHC15-73-C0181 sözleşme numaraları kapsamında desteklenmiştir.

(2) Yazarların posta adresleri şunlardır: D. Crocker, The Rand Corporation, Information Sciences Dept., 1700 Main St., Santa Monica, California 90406; J. Vittal & D. A. Henderson, Bolt Beranek & Newman, 50 Moulton St., Cambridge, Massachusetts 02138; ve K. Pogran, MIT Laboratory for Computer Science, 545 Technology Square, Cambridge, Massachusetts 02139. Yazarların ARPANET adresleri ise şunlardır: DCrocker at Rand-Unix, Vittal at BBN-TenexD, Pogran at MIT-Multics ve Henderson at BBN-TenexD.

ÖNSÖZ

ARPA'nın Computer-Aided Human Communication (CAHCOM) Komitesi, ARPA Ağı metin mesajı (posta) başlıklarının biçimi için bir standart duyurmayı amaçlamaktadır; bu standart, günümüzde Ağ üzerindeki çeşitli mesaj hizmeti alt sistemlerinin gereksinimlerini makul ölçüde karşılayacaktır. Bu belgenin yazarları, bu yeni standardın geliştirilmesi görevi verilen CAHCOM alt komitesini oluşturmaktadır.

Temelde, ARPANET Request for Comments (RFC) 561, "Standardizing Network Mail Headers" ve RFC 680, "Message Transmission Protocol" belgelerinin gözden geçirilmiş bir sürümünü tanımlıyoruz. Bu gözden geçirme, önceki söz diziminin bazı bölümlerini kaldırır ve sıkıştırır ve ağ adresi belirtimine çeşitli özellikler ekler. Özellikle, alıcılar açısından posta kutularına değil kişilere odaklanır ve saklanmış adres listelerine referans verilmesine izin verir. Bu söz diziminin, çoğu kullanıcının kısa vadeli gereksinimlerini karşılamak için yeterli yetenekler sağlayacağını ve bu nedenle geliştiricilere yeni bir posta iletim protokolünü "doğru biçimde" geliştirmek için yeterli alan bırakacağını öngörüyoruz. Ağ topluluğunda böyle bir standart söz dizimi lehine yeterli uzlaşma bulunduğuna inanıyoruz ve bu nedenle şu anda benimsenmesini mümkün görüyoruz. Bu belirtimin daha önceki bir taslağı RFC #724, "Proposed Official Standard for the Format of ARPA Network Messages" başlığıyla yayımlanmış ve ARPANET posta standartlarının arka planı ile ilgili konular hakkında kapsamlı tartışmalar içermiştir.

Bu belirtim bir yıl boyunca geliştirilmiş ve dahil edilmesi gereken yeteneklerin tartışılması için ARPANET posta ortamının kendisi sürekli bir forum olarak kullanılmıştır. Ülke genelinden yirmiden fazla kişi bu tartışmaya katılmıştır ve onların önemli çabalarını burada belirtmek isteriz. Standardın söz dizimi başlangıçta Backus-Naur Form (BNF) meta dili kullanılarak tanımlanmıştır. SRI International'dan Ken L. Harrenstien, BNF'i daha sıkıştırılmış ve daha anlaşılır hale getiren genişletilmiş bir BNF biçimine yeniden kodlamaktan sorumludur.

İÇİNDEKİLER

Önsöz ..................................................... iii

Bölüm

I. Giriş ............................................. 1
II. Çerçeve ................................................ 2

III. Söz Dizimi .................................................. 4

IV. Anlambilim ................................................ 17

V. Örnekler .................................................. 25

Ek

Kaynakça ................................................ 37

I. GİRİŞ

Bu standart, "elektronik posta" çerçevesi içinde bilgisayar kullanıcıları arasında iletilen metin mesajları için bir söz dizimi tanımlar. Standart, ARPANET Request for Comments numaraları 561, "Standardizing Network Mail Headers" ve 680, "Message Transmission Protocol" belgelerinde belirtilmiş olan gayriresmî standartların yerine geçer.

Bu belgede önce genel bir çerçeve açıklanır; ardından resmi söz dizimi tanımlanır ve bunu anlambilim tartışması izler. Son olarak çeşitli örnekler sunulur.

Bu belirtim yalnızca ARPANET üzerindeki ana bilgisayarlar arasında neyin iletileceğini tanımlamak amacıyla hazırlanmıştır. Ağ üzerindeki sistemlerin desteklemesi beklenen özellikleri ya da mesaj oluşturma veya okuma programlarının kullanıcı arayüzlerini belirlemek amacı taşımaz.

Belirtimin gerektirdiği şeyler ile izin verdiği şeyler arasında bir ayrım yapılmalıdır. Mesajlar, resmi olarak yapılandırılmış bilgi bileşenleri açısından karmaşık ve zengin hale getirilebilir veya bu tür bilgilerin en az düzeyde bulunduğu küçük ve basit biçimde tutulabilir. Ayrıca standart, mesajlardaki farklı görsel biçimlerin yorumlanmasını da basitleştirir. Bu basitleştirmeler, resmi belirtimi kolaylaştırır ve mesajlar için resmi anlambilimin ne olduğunu gösterir. Etkilenen yalnızca bir mesajın görsel yönüdür; içindeki bilginin yorumlanması değildir. Uygulayıcılar bu tür görsel ayrımları korumayı tercih edebilir.

II. ÇERÇEVE

ARPANET ortamı dışında var olan birçok mesaj sistemi bulunduğundan ve bunların yanı sıra ARPANET içindeki sistemler de mevcut olduğundan, bu standart tarafından sağlanan genel çerçeveyi ve bunun sonucu ortaya çıkan yetenekleri ve sınırlamaları değerlendirmek yararlı olabilir.

Mesajların metin satırlarından oluşması beklenir. Bu aşamada çizimler, faksimile, konuşma veya yapılandırılmış metinlerin kodlanması için özel düzenlemeler yapılmamıştır.

Veri sıkıştırma veya iletim/depolama verimliliği konularına önemli ölçüde dikkat verilmemiştir. Aslında standart, kullanılan bit sayısı açısından oldukça serbesttir. Örneğin alan adları, kısa özel kodlar yerine serbest metin olarak belirtilmiştir.

Genel bir "memo" çerçevesi kullanılır. Yani bir mesaj, katı bir biçimde düzenlenmiş bazı bilgilerden oluşur ve bunu mesajın ana bölümü izler; bu ana bölüm metindir ve biçimi bu belgede tanımlanmamıştır.

Katı biçimde düzenlenmiş ("header") bölümündeki bazı alanların söz dizimi bu belirtimde tanımlanmıştır; bazı başlık alanları tüm mesajlarda bulunmak zorundadır. Başlıkları birbirinden ayıran söz dizimi, belirli başlıkların iç söz diziminden ayrı olarak tanımlanmıştır. Bu ayrım, son derece basit ayrıştırıcıların mesajların genel yapısı üzerinde çalışabilmesini ve tek tek başlıkların ayrıntılı yapısıyla ilgilenmemesini sağlamak amacıyla yapılmıştır. Ek B, bu basit ayrıştırıcıların geliştirilmesini kolaylaştırmak için sunulmuştur.

Bu belgede tanımlanan alanlara ek olarak, zamanla yaygın kullanıma girecek başka alanların da ortaya çıkması beklenmektedir. Kullanıcı tanımlı başlık alanları, sistemlerin işlevselliğini genişletmesine olanak tanırken aynı zamanda tekdüze bir çerçeveyi korur. Bu yaklaşım TELNET protokolüne benzerdir; burada da kendisini isteğe bağlı olarak genişletebilecek bir mekanizma içeren temel bir standart tanımlanmıştır. Gerektiğinde, bu belgenin yazarları bu "genişletme alanları" için hazırlanan belirtimlerin yayımlanmasını, bu belgenin yayımlanmasında kullanılan mekanizmalar aracılığıyla düzenleyecektir.

Böyle bir çerçeve, belge tonunu ve görünümünü ciddi biçimde sınırlar ve esas olarak kuruluş içi iletişimlerin çoğu ile nispeten yapılandırılmış kuruluşlar arası iletişim için kullanışlıdır. Daha gelişmiş bir ortam, bilgilerin çoklu yazı tipi, çoklu renk ve çok boyutlu biçimde kodlanmasına izin verebilir. Daha sınırlı bir ortam ise — çoğu tek makine mesaj sisteminde olduğu gibi — alan ekleme yeteneğini ve belirli alanları dahil etme kararını daha da kısıtlayacaktır.

Kâğıt tabanlı iletişimle karşılaştırıldığında, bir mesajın alıcısının mesajın görünümü üzerinde olağanüstü derecede kontrol uygulayabilmesi dikkat çekicidir. Mesaj alıcılarının sahip olduğu gerçek kontrol miktarı, kullandıkları mesaj sistemlerinin yeteneklerine bağlıdır.

III. SÖZ DİZİMİ

Bu söz dizimi beş bölüm halinde verilmiştir. İlk bölüm belirtimde kullanılan gösterimi açıklar. İkinci bölüm, sonraki bölümlerde açıklanan daha üst düzey ayrıştırıcıya veri sağlayan temel düzey sözcüksel analizleyicileri açıklar. Üçüncü bölüm mesajlar ve standart başlık alanları için genel bir söz dizimi sunar; dördüncü bölüm adreslerin söz dizimini tanımlar. Son bölüm ise diğer bölümleri destekleyen bazı genel söz dizimi yapılarını açıklar.

A. Gösterim Kuralları

Bu belirtimler genişletilmiş bir Backus–Naur Form (BNF) kullanılarak yapılmıştır. Standart BNF'ten farkları, kural adlandırma yöntemi ile tekrarların ve "yerel" alternatiflerin gösterimidir.

1. Kural adlandırma

Köşeli parantezler ("<", ">") genel olarak kullanılmaz. Bir kuralın adı, "" yerine doğrudan adın kendisidir. Tırnak işaretleri, gerçek metni (büyük ve/veya küçük harf içerebilir) çevreler.

Bazı temel kurallar SPACE, TAB, CRLF, DIGIT, ALPHA gibi büyük harflerle yazılır. Köşeli parantezler, kural tanımlarında ve bu belgenin geri kalanında, kural adlarının kullanımını ayırt etmeyi kolaylaştıracağı durumlarda kullanılır.

2. Parantezler: Yerel alternatifler

Parantez içine alınan öğeler tek bir öğe olarak değerlendirilir. Dolayısıyla "(elem (foo / bar) elem)" ifadesi "(elem foo elem)" ve "(elem bar elem)" biçimlerine izin verir.

3. * yapısı: Tekrar

Bir öğeden önce gelen * karakteri tekrar anlamına gelir. Tam biçimi şöyledir:

<l>*<m>element

Bu ifade, element öğesinin en az <l> ve en fazla <m> kez bulunabileceğini belirtir.

Varsayılan değerler 0 ve sonsuzdur; dolayısıyla *(element) sıfır dahil herhangi bir sayıda kullanıma izin verir; 1*element en az bir kez gerektirir; 1*2element ise bir veya iki kez kullanılmasına izin verir.

4. <number>element

<n>(element) ifadesi <n>*<n>(element) ile eşdeğerdir; yani (element) öğesinin tam olarak <n> kez bulunması gerekir. Örneğin 2DIGIT iki basamaklı bir sayı, 3ALPHA ise üç alfabetik karakterden oluşan bir dizgedir.

5. # yapısı: Listeler

# yapısı * yapısına benzer şekilde aşağıdaki gibi tanımlanır:

<l>#<m>element

Bu ifade, her biri bir veya daha fazla virgül (,) ile ayrılmış en az <l> ve en fazla <m> öğe bulunduğunu gösterir. Bu gösterim, listelerin yaygın biçimini oldukça kolay ifade etmeyi sağlar; örneğin (element *("," element)) kuralı 1#element olarak yazılabilir.

Bu yapı kullanılan her yerde boş öğelere izin verilir, ancak bunlar mevcut öğe sayısına katkıda bulunmaz. Yani (element),,(element) ifadesi geçerlidir fakat yalnızca iki öğe olarak sayılır. Bu nedenle en az bir öğe gerektiğinde en az bir boş olmayan öğe bulunmalıdır.

6. [isteğe bağlı]

Köşeli parantezler isteğe bağlı öğeleri gösterir; [foo bar] ifadesi *1(foo bar) ile eşdeğerdir.

7. ; Yorumlar

Kural metninin sağ tarafında belirli bir boşluk bırakılarak yazılan noktalı virgül (;), satır sonuna kadar devam eden bir yorum başlatır. Bu yöntem, belirtimlerle paralel şekilde yararlı notlar eklemek için basit bir yoldur.

B. Mesajların Sözcüksel Analizi

1. Genel Açıklama

Bir mesaj başlıklardan ve isteğe bağlı olarak bir gövdeden (yani metin satırları dizisinden) oluşur. Metin bölümü ASCII karakterleri içeren satırların bir dizisidir; başlıklardan boş bir satırla ayrılır (yani CRLF'ten önce hiçbir şey bulunmayan bir satır).

a. Başlıkların katlanması ve açılması

Her başlık öğesi, ASCII karakterlerinden oluşan tek bir mantıksal satır olarak düşünülebilir. Kullanım kolaylığı için bu kavramsal yapının alan gövdesi bölümü çok satırlı bir gösterime (yani "katlanmış" biçime) ayrılabilir.

Genel kural şudur: doğrusal boşluk bulunabilen her yerde (yalnızca LWSP-chars değil), CRLF'in hemen ardından en az bir LWSP-char gelecek şekilde ekleme yapılabilir. Ancak bir başlığın adı ve onu izleyen iki nokta (:), başlık öğesinin başlangıcında yer aldığından birden fazla satıra bölünemez.

Dolayısıyla şu tek satır:

To:  "Joe Dokes & J. Harvey" <ddd at Host>, JJV at BBN

şu şekilde gösterilebilir:

To:  "Joe Dokes & J. Harvey" <ddd at Host>,
     JJV at BBN

ve:

To:  "Joe Dokes & J. Harvey"
                 <ddd at Host>,
     JJV at BBN

ve:

To:  "Joe Dokes
     & J. Harvey" <ddd at Host>, JJV at BBN

Bir başlık alanının bu katlanmış çok satırlı gösteriminden tek satırlı gösterimine geçme süreci "açma" (unfolding) olarak adlandırılır. Açma işlemi, CRLF karakterinin hemen ardından gelen LWSP-char karakterinin yalnızca LWSP-char ile eşdeğer kabul edilmesiyle gerçekleştirilir.

b. Başlık alanlarının yapısı

Başlık alanları açıldıktan sonra, bir field-name ardından bir iki nokta (:) ve ardından bir field-body içerecek şekilde düşünülür. Field-name, yazdırılabilir ASCII karakterlerinden (yani ondalık değeri 33 ile 126 arasında olan, iki nokta hariç karakterler) ve LWSP-chars karakterlerinden oluşmalıdır. Field-body ise herhangi bir ASCII karakterinden oluşabilir (tırnak içine alınmamış bir CRLF hariç; bu zaten açma işlemi sırasında kaldırılmıştır).

Bazı başlık alanlarının field-body bölümleri, bazı sistemlerin ayrıştırmak isteyebileceği bir iç söz dizimine göre yorumlanabilir. Bu tür alanlar "yapılandırılmış" alanlar olarak adlandırılır. Tarih ve adres içeren alanlar buna örnektir. "Subject" ve "Comments" gibi diğer alanlar ise yalnızca metin dizileri olarak değerlendirilir.

NOT: Alan adları, yapılandırılmamış alan gövdeleri ve yapılandırılmış alan gövdeleri her biri kendi bağımsız "sözcüksel" analizleyicisi tarafından taranır.

C. Alan adları

Alan adlarının oluşturulmasını ve okunmasını kolaylaştırmak için LWSP-chars karakterlerinin makul yerlerde serbestçe eklenmesine izin verilir.

Alan adı söz dizimini bu LWSP-chars karakterlerinin açık söz dizimiyle karmaşık hale getirmek yerine bir "sözcüksel" analizleyicinin var olduğu varsayılır. Bu analizleyici, alan adını oluşturan metni LWSP-chars karakterleri ile ayrılmış alan adı atomlarının (fnatoms) bir dizisi olarak yorumlar.

Alan adındaki fnatomlar arasında yalnızca LWSP-chars bulunabileceğine ve CRLF karakterlerinin bulunamayacağına dikkat edilmelidir. Ayrıca yorumlar sözcüksel olarak tanınmaz, ancak parantez içindeki dizgeler alan adlarının bir parçası olarak geçerlidir. Bu kısıtlamalar, yapılandırılmış alan gövdelerinde izin verilenlerden farklıdır.

Özellikle bu, başlık alanı adlarının katlanmış bir başlık öğesinin ilk satırında tamamen yer alması gerektiği ve iki veya daha fazla satıra bölünemeyeceği anlamına gelir.

D. Yapılandırılmamış Alan Gövdeleri

"Subject" ve "Comments" gibi bazı alanlar için herhangi bir yapı varsayılmaz; bunlar, ileti gövdesindekilere benzer şekilde yalnızca metin olarak ele alınır. Katlama kuralları bu alanlara da uygulanır; bu nedenle birkaç satırı kaplayan bu tür alan gövdelerinde ikinci ve sonraki satırlar en az bir LWSP-char kadar girintili olmalıdır.

E. Yapılandırılmış Alan Gövdeleri

Yapılandırılmış alanların yazılmasını ve okunmasını kolaylaştırmak için linear-white-space değerinin (CRLF eklenmesi yoluyla katlamaya izin veren) uygun yerlerde serbestçe eklenmesine izin verilir.

Bu yapılandırılmış alanların söz dizimi tanımlarını bu linear-white-space için açık söz dizimi ile karmaşık hale getirmek yerine, başka bir "leksik" analizörün varlığı varsayılır. Bu analizör, yukarıda açıklanan şekilde yalnızca yapılandırılmamış metin dizileri olan alan gövdelerine uygulanmaz.

Bu analizör, alan gövdesini oluşturan açılmış metni bir dizi leksik sembol olarak yorumlar. Bu semboller şunlardır:

Bu sembollerden ilk üçü kendi kendini sınırlar. Atomlar ise böyle değildir; bu nedenle kendini sınırlayan semboller ve linear-white-space tarafından sınırlandırılırlar. Atom ve quoted-string dizilerinin yeniden oluşturulması amacıyla aralarında tam olarak bir SPACE bulunduğu varsayılır ve kullanılmalıdır.

(Ayrıca Bölüm III.B.3.a içinde, birden fazla bitişik LWSP-char karakterinin ele alınmasına ilişkin kurallara dikkat edin.)

Örneğin, bir adres alanının katlanmış gövdesi:

":sysmail"@   Some-Host,
Muhammed(I am   the greatest)Ali   at(the)WBA

şu leksik sembollere ve türlere ayrıştırılır:

":sysmail"              quoted string
@                       special
Some-Host               atom
,                       special
Muhammed                atom
(I am   the greatest)   comment
Ali                     atom
at                      atom
(the)                   comment
WBA                     atom

Bu adreslerdeki verilerin kanonik gösterimleri aşağıdaki dizelerdir (kelimeler arasında tam olarak bir SPACE bulunduğuna dikkat edin):

:sysmail at Some-Host

ve

Muhammed Ali at WBA

2. Biçimsel Tanımlar

Aşağıdaki ilk dört kural, alanların belirli türü veya iç söz dizimi dikkate alınmadan alanlar için bir meta-söz dizimi gösterir. Kalan kurallar, Bölüm III.C, III.D ve III.E içindeki kurallar tarafından kullanılan temel söz dizimsel yapıları tanımlar.

field       =  field-name ":" [ field-body ] CRLF

field-name  =  fnatom *( LWSP-char [fnatom] )

fnatom      =  1*<herhangi bir CHAR, CTL'ler, SPACE ve ":" hariç>

field-body  =  field-body-contents
               [CRLF LWSP-char field-body]

field-body-contents = <alan gövdesini oluşturan TELNET ASCII karakterleri;
               aşağıdaki bölümlerde tanımlandığı gibi,
               atom, quoted-string ve specials belirteçlerinin
               birleşimlerinden oluşabilir veya metinlerden
               oluşabilir>

CHAR        =  <herhangi bir TELNET ASCII karakteri>           ; (Sekizlik 0–177, Ondalık 0–127)
ALPHA       =  <herhangi bir TELNET ASCII alfabetik karakteri>
DIGIT       =  <herhangi bir TELNET ASCII rakamı>
CTL         =  <herhangi bir TELNET ASCII kontrol karakteri ve DEL>
CR          =  <TELNET ASCII carriage return>
LF          =  <TELNET ASCII linefeed>
SPACE       =  <TELNET ASCII boşluk>
HTAB        =  <TELNET ASCII yatay sekme>
"           =  <TELNET ASCII tırnak işareti>
CRLF        =  CR LF

LWSP-char   =  SPACE / HTAB                 ; semantik = SPACE
linear-white-space = 1*([CRLF] LWSP-char)   ; semantik = SPACE
                                            ; CRLF => katlama

specials    =  "(" / ")" / "<" / ">" / "@"
            /  "," / ";" / ":" / "\\" / "\""

delimiters  =  specials / comment / linear-white-space

text        =  <herhangi bir CHAR, çıplak CR ve/veya çıplak LF dahil,
               ancak CRLF dahil değil>

atom        =  1*<specials ve CTL'ler dışındaki herhangi bir CHAR>

quoted-string = "\"" *(qtext/quoted-pair) "\""

qtext       =  <"\"" ve CR dışındaki herhangi bir CHAR,
               linear-white-space dahil>

comment     =  "(" *(ctext / comment / quoted-pair) ")"

ctext       =  <"(", ")" ve CR hariç herhangi bir CHAR,
               linear-white-space dahil>

quoted-pair =  "\\" CHAR

3. Açıklamalar

a. "White space"

Alan adlarında ve yapılandırılmış alan gövdelerinde birden fazla linear white space TELNET ASCII karakteri (yani HTAB ve SPACE) tek bir boşluk olarak ele alınır ve herhangi bir sembolün etrafında serbestçe bulunabilir.

Tüm başlık alanlarında, en az bir boşluğun gerekli olduğu tek yer katlanmış bir alanın devam satırlarının başlangıcıdır.

Metin, bu standarda göre yorumlamayan süreçlere iletilirken (örneğin ARPANET FTP posta sunucuları), keyfi linear-white-space ve yorum dizilerinin yerine tam olarak bir SPACE kullanılmalıdır.

listesindeki bir öğenin kullanılmasına izin verilen her yerde, LWSP-char karakterleri ondan önce ve/veya sonra da bulunabilir.

Posta gönderme (yani başlık üreten) programlarını yazanlar, yatay sekme TELNET ASCII karakterlerinin başka bir ağ ana makinesinde metnin görünümü üzerindeki etkisinin Ağ genelinde tanımlanmış bir karşılığı olmadığını bilmelidir; bu nedenle ileti başlıklarında sekme kullanımı izin verilmiş olsa da önerilmez.

Ayrıca, TELNET NVT bağlantıları kullanılarak ARPANET üzerinden iletim sırasında verilerin TELNET NVT kurallarına uyması gerektiğini unutmayın (örneğin CR tek başına kullanılacaksa ardından ya LF gelerek CRLF oluşturmalı ya da gelmelidir).

b. Yorumlar

Yorumlar yalnızca yapılandırılmış alanların alan gövdeleri içinde bu şekilde algılanır. Yorum, bir quoted-string içinde olmayan ve eşleşen parantezler içinde yer alan TELNET ASCII karakterlerinden oluşan bir kümedir. Parantezler iç içe olabilir; bu nedenle bir yorum dizisinde tırnaksız bir sol parantez varsa buna karşılık gelen bir sağ parantez de bulunmalıdır.

Bir yorum, iki atom gibi iki leksik sembol dizisi arasında ayırıcı olarak kullanıldığında, dizinin yeniden oluşturulması amacıyla bir SPACE ile leksik olarak eşdeğerdir (örneğin dizi bir FTP posta sunucusuna iletilirken).

Yorumlar FTP sunucusuna aktarılmaz, çünkü yorumlar resmi adresin bir parçası değildir.

Bir yorum birden fazla satıra katlanacaksa katlama söz dizimine uyulmalıdır. Bu nedenle resmi semantik, yorumlar içinde bulunan tırnaksız CRLF değerlerini görmez; ancak bazı ayrıştırma programları bunların varlığını kaydetmek isteyebilir.

c. Sınırlandırma ve Alıntılama Karakterleri

Tırnak karakteri (ters eğik çizgi) ve söz dizimsel birimleri sınırlandıran karakterler genellikle sınırlandırılmış veya alıntılanmış birimlerin parçası olan veri olarak kabul edilmez. Tek istisna SPACE karakteridir.

Özellikle:

quoted-string, comment veya alıntılanmış karakterin parçası değildir.

Bir quoted-string içinde yer alacak bir tırnak işareti, bir yorum içinde yer alacak bir parantez veya her iki durumda da yer alacak bir ters eğik çizgi, alıntı karakteri olan ters eğik çizgi ("\") ile öncelenmelidir.

Bir ifadede ardışık kelimeler arasında, araya yerleştirilen LWSP-char sayısından bağımsız olarak tek bir SPACE bulunduğu varsayılır. Birden fazla SPACE eklemek için LWSP-char karakterleri bir quoted-string'in parçası yapılmalıdır.

Bir quoted string'i sınırlayan tırnak işaretleri ve sonraki karakteri alıntılayan ters eğik çizgiler, veri bu belirtime göre yorumlamayan süreçlerle kullanıldığında (örneğin ARPANET FTP posta sunucuları) quoted-string ile birlikte gönderilmemelidir.

d. Quoted-strings

İzin verilen yerlerde (yani yapılandırılmış alanlardaki kelimelerde) quoted-strings tek bir sembol olarak ele alınır ve söz dizimsel olarak bir atom ile eşdeğerdir.

Bir quoted-string birden fazla satıra katlanacaksa katlama söz dizimine uyulmalıdır. Bu nedenle resmi semantik, quoted-string içinde bulunan çıplak CRLF değerlerini görmez; ancak bazı ayrıştırma programları bunların varlığını kaydedebilir.

Quoted CRLF'ler (bir ters eğik çizgi ardından CR ardından LF) CRLF'nin quoted-string içinde veri olduğunu açıkça gösterir. Quoted CRLF'ler ayrıştırılırken ardından gelen ilk LWSP-char karakterinin kaldırılması uygundur.

e. Köşeleme Karakterleri

Doğru şekilde iç içe yerleştirilmesi gereken üç tür köşeleme vardır:

f. Belirli Atomların Büyük/Küçük Harf Bağımsızlığı

Söz diziminde alfabetik sabit dizeler olarak gösterilen bazı atomlar büyük ve küçük harflerin herhangi bir birleşimiyle görünebilir. Bunlar şunları içerir:

Bir atom bu sabitlerden biriyle eşleştirilirken büyük/küçük harf dikkate alınmaz.

Örneğin "From", "FROM" ve diğer harf varyasyonları eşdeğer kabul edilir.

III. Söz Dizimi

B. Leksik Analiz

"from" ve hatta "FroM" aynı şekilde ele alınmalıdır. Bununla birlikte bu belirtimde gösterilen büyük/küçük harf kullanımı ileti oluşturan süreçler için önerilir. Bu belirtim düzeyinde büyük/küçük harfin diğer kelimeler ve metinler için önemli olduğunu unutmayın. Ayrıca aşağıdaki Bölüm IV.A.1.f'ye bakın.

g. Uzun satırların katlanması

Her başlık öğesi (ileti alanı), alan adı ve alan gövdesinden oluşan tek bir satırda temsil edilebilir; ayrıştırıcının gördüğü yapı budur. Okunabilirliği artırmak için uzun başlık öğelerinin field-body kısmının gerçek başlık içinde birden fazla satıra "katlanması" önerilir. "Uzun" genellikle 65 veya 72 karakterden fazla olarak yorumlanır. İlk uzunluk sınır olarak önerilir ancak bu standart tarafından zorunlu tutulmaz.

h. Backspace karakterleri

Backspace TELNET ASCII karakterleri (ASCII BS, ondalık 8) metinler ve quoted-string'ler içinde üst üste yazım etkisi oluşturmak için bulunabilir; ancak metnin veya quoted-string'in başlangıcının soluna taşacak şekilde üst üste yazım oluşturan herhangi bir backspace kullanımı yasaktır.

C. İLETİLERİN GENEL SÖZ DİZİMİ

NOT: Gösterim kurallarındaki bir özellik nedeniyle söz dizimi "Date", "From", "Sender" ve "Reply-To" alanlarının bulunduğunda belirli bir sırada olması gerektiğini gösterir. Bu başlık öğeleri benzersiz olmalıdır (tam olarak bir kez bulunmalıdır). Ancak gerçekte başlık alanlarının belirli bir sırada bulunması zorunlu değildir; tek istisna ileti gövdesinin başlıklardan SONRA gelmesidir. Okunabilirlik ve basit sistemler tarafından kolay ayrıştırma için başlıkların "Date", "From", "Subject", "Sender", "To", "cc" vb. sırasıyla gönderilmesi önerilir. Bu belirtim çoğu optional-field için birden fazla kullanımına izin verir. Ancak bunların yorumlanması burada tanımlanmamıştır ve kullanımları güçlü biçimde önerilmez.

Çeşitli alanların gövdeleri için aşağıdaki söz dizimi, her alan gövdesini tek bir uzun dize (veya satır) olarak tanımlıyormuş gibi düşünülmelidir. Leksik Analiz bölümü (Bölüm II.B), bu uzun dizelerin gerçek iletilerde birden fazla satırda nasıl temsil edilebileceğini açıklar.

C. İletiler

message     =  fields *( CRLF *text )       ; İlk boş satırdan
                                            ; sonraki her şey
                                            ; ileti gövdesidir

fields      =  date-field                   ; Oluşturma zaman damgası
               originator-fields            ; ve yazar kimliği
               *optional-field              ; gereklidir: diğerleri
                                            ; isteğe bağlıdır

originator-fields =
               (  "From"     ":" mailbox    ; Tek yazar
                 ["Reply-To" ":" #address] )
            /  (  "From"     ":" 1#address  ; Birden fazla yazar ve
                  "Sender"   ":" mailbox    ; makine dışı adresler
                 ["Reply-To" ":" #address] ); olabilir

date-field  =  "Date"       ":" date-time

optional-field  =
               "To"         ":" #address
            /  "cc"         ":" #address
            /  "bcc"        ":" #address    ; Gizli kopya
            /  "Subject"    ":" *text
            /  "Comments"   ":" *text
            /  "Message-ID" ":" mach-id     ; Yalnızca bir tane
            /  "In-Reply-To"":" #(phrase / mach-id)
            /  "References" ":" #(phrase / mach-id)
            /  "Keywords"   ":" #phrase
            /  extension-field              ; Ek belirtimlerde
                                            ; tanımlanır
            /  user-defined-field           ; Benzersiz alan adı
                                            ; olmalıdır ve
                                            ; yerini başka
                                            ; tanımlar alabilir

extension-field = <Bu belirtime resmi bir genişletme olarak
               yayımlanan bir belgede tanımlanan herhangi bir alan>

user-defined-field = <Bu belirtimde veya buna yönelik yayımlanmış
               bir genişletmede tanımlanmamış herhangi bir alan;
               bu tür alanların adları benzersiz olmalıdır ve
               yayımlanmış genişletmeler tarafından
               yerleri alınabilir>

D. Alıcı Öğeleri

GENEL ALICI ÖĞELERİNİN SÖZ DİZİMİ

address     =  host-phrase                  ; Makine mailbox
            / ( [phrase] "<" #address ">")  ; Bireysel / Liste
            / ( [phrase] ":" #address ";")  ; Grup
            /  quoted-string                ; Serbest metin
            / (":" ( "Include"              ; Dosya, adres listesi ile
                   / "Postal"               ; (ABD) posta adresi
                   / atom )                 ; Genişletilmiş veri türü
               ":" address)

mailbox     =  host-phrase / (phrase mach-id)

mach-id     =  "<" host-phrase ">"          ; İçerik asla
                                            ; değiştirilmemelidir!

E. Destekleyici Yapılar

host-phrase =  phrase host-indicator       ; Temel adres

host-indicator =  1*( ("at" / "@") node )  ; En sağdaki node
                                            ; ağ hiyerarşisinin
                                            ; en üstündedir;
                                            ; en soldaki
                                            ; host olmalıdır

node        =  word / 1*DIGIT               ; Resmi host veya
                                            ; ağ adı ya da
                                            ; ondalık adres

date-time   =  [ day-of-week "," ] date time

day-of-week =  "Monday"    / "Mon"  / "Tuesday"   / "Tue"
            /  "Wednesday" / "Wed"  / "Thursday"  / "Thu"
            /  "Friday"    / "Fri"  / "Saturday"  / "Sat"
            /  "Sunday"    / "Sun"

date        =  1*2DIGIT ["-"] month
               ["-"] (2DIGIT / 4DIGIT)       ; gün ay yıl
                                             ; örn. 20 Aug [19]77

month       =  "January"   / "Jan"  / "February"  / "Feb"
            /  "March"     / "Mar"  / "April"     / "Apr"
            /  "May"                / "June"      / "Jun"
            /  "July"      / "Jul"  / "August"    / "Aug"
            /  "September" / "Sep"  / "October"   / "Oct"
            /  "November"  / "Nov"  / "December"  / "Dec"

time        =  hour zone                    ; ANSI ve Askerî
                                            ; (saniyeler isteğe bağlı)

hour        =  2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ]
                                            ; 0000[00] - 2359[59]

zone        = ( ["-"] ( "GMT"
                 / "NST"                    ; Newfoundland: -3:30
                 / "AST" / "ADT"            ; Atlantic:  -4 / -3
                 / "EST" / "EDT"            ; Eastern:   -5 / -4
                 / "CST" / "CDT"            ; Central:   -6 / -5
                 / "MST" / "MDT"            ; Mountain:  -7 / -6
                 / "PST" / "PDT"            ; Pacific:   -8 / -7
                 / "YST" / "YDT"            ; Yukon:     -9 / -8
                 / "HST" / "HDT"            ; Haw/Ala   -10 / -9
                 / "BST" / "BDT"            ; Bering:   -11 / -10
                   1ALPHA       ))          ; Askerî: Z = GMT;
                                            ; A:-1; (J kullanılmaz)
                                            ; M:-12; N:+1; Y:+12
            / ( ("+" / "-") 4DIGIT )        ; Yerel fark
                                            ; saat/dak. (HHMM)

phrase      =  1*word                       ; Kelime dizisi.
                                            ; Ayırma anlamsal
                                            ; olarak = SPACE

word        =  atom / quoted-string

IV. Anlambilim

A. Adres Alanları

1. Genel

a. Bir adres belirtimindeki host-phrase'in phrase kısmının (yani posta kutusu için host tarafından kullanılan adın) anlamı, alıcı FTP Server'ın izin verdiği her şey olabilir (örneğin, TENEX sistemleri şu anda "P. D. Q. Bach" biçimindeki adresleri anlamaz, ancak başka bir sistem anlayabilir).

Bir posta kutusunun, zorunlu olarak dosya depolamayla ilişkili olmayan kavramsal bir varlık olduğuna dikkat edin. Örneğin bazı siteler postayı satır yazıcılarında yazdırmayı ve çıktıyı alıcının masasina ulaştırmayı tercih edebilir.

Bir bireyin birden fazla posta kutusu olabilir ve bir grup birey postayı tek bir birim olarak almak isteyebilir (yani bir dağıtım listesi). Bir adres listesinin (#address) ikinci ve üçüncü alternatifleri, alt adres listelerinden oluşan bir koleksiyonun adlandırılmasına izin verir. Alıcı posta kutuları, bu adlandırılmış listelerin köşeli ayraçlı bölümünde ("<" - ">" veya ":" - ";") belirtilir.

Köşeli parantezlerin ("<", ">") kullanımı, birden fazla posta kutusuna sahip bireyler ve özel posta kutusu listeleri için amaçlanmıştır; belirtim böyle bir iç içe kullanıma izin verse de bunun bir seviyeden fazla iç içe kullanılması beklenmez. İki nokta / noktalı virgül (":", ";") kullanımı ise gruplar için amaçlanmıştır. Grupların iç içe olması beklenebilir (yani alt gruplar içerebilir). Hem bireyler hem de gruplar için, iletilen mesajın bir kopyası listelenen her posta kutusuna gönderilmelidir. Özel bir liste durumunda adreslerin nasıl ele alınacağı bu bölümün ilgili alt bölümlerinde tanımlanmıştır.

b. Adres olarak çıplak quoted-string ifadelerinin dahil edilmesine (yani dördüncü adres-biçimi alternatifi) sözdizimsel kolaylık amacıyla izin verilir, ancak kullanımları için herhangi bir anlamsal tanım yapılmamıştır. Bununla birlikte, bir adres listesi çoğaltılırken tüm üyelerinin, quoted-string ifadeleri de dahil olmak üzere çoğaltılması makul kabul edilir.

c. :Include: belirtimleri, saklanmış adres listeleri (#address) içeren bir veya daha fazla konuma başvurmak için kullanılır. Birden fazla konuma başvuruluyorsa, Include ifadesinin adres kısmı <address> için "Individual / List" alternatifine uygun şekilde köşeli parantezlerle çevrili bir liste (#address) olmalıdır. Bileşen adreslerin bir host-phrase'e çözümlenmesi gerekir; bu yapı içinde yalnızca bunların anlamı vardır. Belirtilen host-phrase'lerin phrase kısmı, başvurulan host'un bir dosyaya çözümleyebileceği metni içermelidir.

Bu standart bir protokol değildir ve bu nedenle verinin dosyadan nasıl alınacağını belirlemez. Ancak aşağıdaki gereksinimler konulmuştur:

Bu mekanizmanın programların bu tür listeleri otomatik olarak alabilmesine izin vermesi amaçlanmıştır.

Böyle bir dosya başvurusunun yorumlanması aşağıdaki gibidir. Bu, belirli bir uygulama şemasını ima etmek için değil, adres listelerine dosya içeriği dahil etme fikrini anlamayı kolaylaştırmak için sunulmuştur:

d. :Postal: belirtimleri (ABD) posta adreslerini belirtmek için kullanılır, ancak quoted-string adresleriyle aynı şekilde ele alınabilir. Bir posta adresleri listesine başvurmak için liste <address> için "Individual / List" alternatifine uymalıdır. :Include: alternatifi de geçerlidir.

e. ":" atom ":" sözdizimi, özel veri türüne sahip adresleri belirtmek için genel bir mekanizma olarak tasarlanmıştır. Genişletme alanlarında olduğu gibi, bu belgeyi hazırlayanlar bu genişletilmiş veri türleri için yayımlanacak belirtimleri düzenleyecektir. Tanımlanmış bir anlambilim yoksa, bu biçimdeki herhangi bir adres bir quoted-string adresi olarak ele alınabilir.

f. Bir düğüm adı ağın veya host'un resmi adı olmalıdır ya da mesaj oluşturulduğu anda o ağ veya host için ağ adresini gösteren ondalık bir sayı olabilir. Sayı kullanımı güçlü biçimde önerilmez ve yalnızca yerel ad tablolarını zaman zaman atlamak gerektiği durumlar nedeniyle izin verilmiştir. ARPANET için resmi adlar, Menlo Park, California'daki SRI International bünyesindeki Network Information Center tarafından tutulur.

Bir mesajın başka bir ağdaki bir host'a iletilebileceği veya taşınabileceği durumlarda, tam hiyerarşik adresler belirtilmelidir. Bunlar, at-sign veya "at" göstergeleriyle ayrılmış bir dizi kelime olarak ifade edilir. İletişim ortamının, kök düğümleri arasındaki bağlantılar dışında bağımsız "ağaçlar" şeklinde düzenlenmiş ağlardan oluştuğu varsayılır. Yani yalnızca kökler bu bağımsız ağlar arasında geçit görevi görebilir. Başka gerçek bağlantılar mevcut olsa da bu tür bir organizasyon varsayımının, host'lar arasında GEÇERLİ — her zaman en VERİMLİ olmasa da — yolları tanımlamak için güvenilir bir yöntem sağlayacağı düşünülmektedir. Bu nedenle tipik bir tam posta kutusu belirtimi şöyle görünebilir:

Friendly User @ hosta @ local-net1 @ major-netq

En basit durumda, posta gönderen host mesajı belirtilen son düğüme (en sağdaki) iletmeli, belirtimden bu düğüm referansını kaldırmalı ve kalan host-phrase'i alıcı host'a (ARPANET'te onun FTP sunucusuna) işlenmek üzere iletmelidir. Bu yaklaşım, host göstergesinin kalan kısmını yalnızca ifadenin sonlandırıcı bölümü olarak ele alır.

NOT: Bir host göstergesinin herhangi bir kısmı bu standarda göre veri yorumlamayan bir sürece iletilirken (örneğin ARPANET FTP sunucuları), "at" yerine "@" kullanılmalı ve öncesinde ya da sonrasında herhangi bir LWSP-chars bulunmamalıdır. Yukarıdaki örnek kullanıldığında, aşağıdaki dize major-netq geçidine iletilir:

Friendly User@hosta@local-net1

Gönderen host ağ ortamı hakkında daha fazla bilgiye sahipse, mesajı daha verimli bir yol üzerinden göndermeli ve alıcı host'a verdiği host-phrase biçiminde uygun değişiklikler yapmalıdır.

IV. Anlambilim

A. Adres Alanları

Yukarıdaki belirtimi örnek olarak kullanmak gerekirse: Eğer gönderen hostb aynı zamanda local-net1'in bir parçasıysa, mesajı doğrudan hosta'ya gönderebilir ve hosta'nın posta alma programına yalnızca "Friendly User" ifadesini verir. Eğer hostb, hostc ile birlikte local-net2'nin bir parçasıysa ve hosta ile hostc'nin başka bir local-net'in parçası olduğunu biliyorsa, hostb mesajı hostc'ye "Friendly User@hosta" adresiyle gönderebilir.

Bir host-phrase içindeki phrase, yalnızca belirtilen alıcı host için anlamlı olacak şekilde tasarlanmıştır. Diğer tüm host'lar için phrase yorumlanmayan bir dize olarak ele alınmalıdır. Phrase üzerinde hiçbir büyük/küçük harf dönüşümü (otomatik olarak) yapılmamalıdır. Phrase yerel host'un posta gönderme programına iletilir; gerekiyorsa bu phrase üzerinde büyük/küçük harf eşlemesini yaparak postayı teslim etmek hedef host'un posta alma (dağıtım) programının sorumluluğundadır.

2. Gönderen Alanları

UYARI: Standart, From, Sender ve Reply-To alanlarıyla mümkün olan tüm kombinasyonların yalnızca bir alt kümesine izin verir. Bu sınırlama bilinçli olarak konulmuştur.

a. From

Bu alan, bu mesajın gönderilmesini isteyen kişi(ler)in kimliğini içerir. Mesaj oluşturma süreci varsayılan olarak bu alanı, mesajı giren AJANI (kişi veya süreç) belirten tek bir makine adresi olacak şekilde ayarlamalıdır. Eğer bu yapılmazsa, "Sender" alanı MUTLAKA bulunmalıdır; eğer yapılırsa, "Sender" alanı isteğe bağlıdır.

b. Sender

Bu alan, mesajı gönderen AJANIN (kişi veya süreç) kimliğini içerir. Gönderenin mesajın yazarı olmadığı durumlarda veya bir yazar grubundan mesajı gerçekte kimin gönderdiğini belirtmek için kullanılması amaçlanmıştır. Eğer "Sender" alanının içeriği "From" alanıyla tamamen aynıysa, "Sender" alanının bulunması gerekmez ve kullanımı önerilmez (yine de geçerlidir); özellikle "Sender" alanı "From" alanıyla aynı değilse MUTLAKA bulunmalıdır.

Sender host-phrase'i, standart bir adres yerine belirli bir ajana (yani bir insan kullanıcıya veya bilgisayar programına) karşılık gelmesi gereken bir phrase içerir. Bu, alanın posta göndermekten sorumlu tek AJANI (kişi veya süreç) tanımlamasının beklendiğini ve yalnızca postanın gönderildiği posta kutusunun adını içermemesi gerektiğini gösterir. Örneğin paylaşılan bir oturum açma adı kullanılıyorsa, yalnızca adın kendisi yeterli olmayacaktır. Bu ajana referans veren host-phrase'in phrase kısmının bir bilgisayar sistemi terimi olması beklenir; ağ metin mesajı bağlamı dışında kullanılabilen genel bir kişi referansı olmamalıdır.

"Sender" alanının yerine getirdiği kritik işlev, postanın gönderilmesinden sorumlu ajanı tanımlamak olduğundan ve bilgisayar programları davranışlarından sorumlu tutulamayacağından, bir bilgisayar programı bir mesaj oluşturduğunda o programdan sorumlu İNSANIN "Sender" alanı host-phrase'inin bir parçası olarak belirtilmesi güçlü biçimde önerilir.

c. Reply-To

Bu alan, yanıtların gönderileceği posta kutu(ları)nı belirtmek için genel bir mekanizma sağlar. Bu özelliğin üç tipik kullanım biçimi ayırt edilebilir.

Reply-To alanlarının makine adresi (yani host-phrase) içermesi zorunlu değildir. Ancak geçerli bir ağ adresinin hiç bulunmaması, yazılım sistemlerinin kullanıcılara postaya kolayca yanıt vermede otomatik yardım sağlamasını genellikle engeller.

NOT: Mesajlara yanıt için otomatik olarak adres listeleri oluşturan sistemler için aşağıdaki öneriler yapılmaktadır:

Bu öneri yalnızca gönderen alanları için geçerlidir ve yanıtların bu mesajın diğer alıcılarına da gönderilmemesi gerektiğini ima etmez. Ek olarak hangi olanakların sağlanacağına ilgili posta işleme programları karar verecektir.

3. Alıcı Alanları

a. To

Bu alan mesajın birincil alıcılarının kimliğini içerir.

b. cc

Bu alan mesajın ikincil alıcılarının kimliğini içerir.

c. Bcc

Bu alan mesajın ek alıcılarının kimliğini içerir. Bu alanın içeriği, mesajın birincil ve ikincil alıcılarına gönderilen kopyalara dahil edilmez. Bazı sistemler "Bcc" alanının metnini yalnızca yazar(lar)ın kopyasına dahil etmeyi seçebilirken, diğerleri bunu "Bcc" listesinde belirtilen tüm kişilere gönderilen metne de dahil edebilir.

B. Referans Belirtim Alanları

1. Message-ID

Bu alan BU mesajın BU sürümüne başvuran benzersiz bir tanımlayıcı (phrase) içerir. Mesaj tanımlayıcısının benzersizliği onu oluşturan host tarafından garanti edilir. Bu tanımlayıcı makineler tarafından okunabilir olacak şekilde tasarlanmıştır ve insanların anlamlandırması zorunlu değildir. Bir mesaj tanımlayıcısı belirli bir mesajın tam olarak tek bir örneğine karşılık gelir; mesajın daha sonraki revizyonlarının her biri yeni bir mesaj tanımlayıcısı almalıdır.

2. In-Reply-To

Bu alanın içeriği, bu iletinin yanıt verdiği önceki yazışmaları tanımlar. Bu alanda ileti tanımlayıcıları kullanılıyorsa, bunların mach-id belirtim biçimini kullanması gerektiğine dikkat edin.

3. References

Bu alanın içeriği, bu iletinin atıfta bulunduğu diğer yazışmaları tanımlar. İleti tanımlayıcıları kullanılıyorsa, bunların mach-id belirtim biçimini kullanması gerektiğine dikkat edin.

4. Keywords

Bu alan, virgüllerle ayrılmış anahtar kelimeleri veya ifadeleri içerir.

C. Diğer Alanlar ve Sözdizimsel Öğeler

1. Subject

"Subject" alanı, iletinin doğasını yeterli biçimde özetlemek veya belirtmek için gerekli olduğu kadar bilgi sağlamak amacıyla tasarlanmıştır.

2. Comments

İletinin gövdesinin içeriğini bozmadan iletiye metin yorumları eklenmesine izin verir.

3. Extension-field

Bu belgede nispeten sınırlı sayıda ortak alan tanımlanmıştır. Ağ postası gereksinimleri doğrultusunda ek alanlar standartlaştırılabilir. Bu belgenin yazarları, bu tür tanımların temel belirtime uzantılar olarak yayımlanmasını düzenleyecektir.

4. User-defined-field

Ağ postası kullanıcıları ek başlık alanları tanımlamakta ve kullanmakta serbesttir. Bu tür alanların adları, mevcut belirtimde veya herhangi bir extension-field tanımında zaten kullanılmamış olmalıdır ve bu kullanıcı tanımlı alanların genel sözdizimi, bu belirtimin alanları sınırlama ve satır katlama kurallarına uymalıdır. Extension-field yayımlama süreci nedeniyle, bir kullanıcı tanımlı alanın adı önceden alınmış olabilir.

D. Tarihler ve Saatler

Eğer dahil edilmişse, haftanın günü tarih belirtiminin ima ettiği gün olmalıdır.

Saat dilimi çeşitli şekillerde belirtilebilir. Askerî standart her bölge için tek bir karakter kullanır. "Z" Greenwich Mean Time anlamına gelir; "A" bir saat daha erkeni, "M" ise 12 saat daha erkeni gösterir; "N" bir saat sonrayı, "Y" ise 12 saat sonrayı gösterir. "J" harfi kullanılmaz.

Kalan diğer iki biçim ANSI standardı X3.51-1975'ten alınmıştır. Bunlardan biri GMT'den olan fark miktarının açıkça belirtilmesine izin verir; diğeri ise Kuzey Amerika'daki saat dilimlerini belirtmek için yaygın 3 karakterli dizeleri kullanır.

V. Örnekler

A. Adresler

  1. Alfred E. Neuman

  2. Neuman@BBN-TENEXA

Bu iki "Alfred E. Neuman" örneği, yerel ana bilgisayarın posta gönderme (dağıtım) programının (bazen "mailer" olarak da adlandırılır) ve uzak ana bilgisayarın FTP sunucusunun çalışması açısından aynı anlama sahiptir. İlk örnekte "Alfred E. Neuman" ifadesi mailer tarafından yok sayılır, çünkü "Neuman at BBN-TENEXA" alıcıyı tamamen belirtir. İkinci örnek gereksiz bilgi içermez ve yine "Neuman@BBN-TENEXA" hedef alıcıdır.

  1. Al Neuman at BBN-TENEXA

Bu, "Al Neuman " ile aynıdır. Yani "Al Neuman" tam ifadesi FTP sunucusuna iletilir. Tüm FTP sunucularının çok kelimeli tanımlayıcıları kabul etmediğine dikkat edin; bazıları kabul etse bile her kelimeyi farklı bir alıcı olarak değerlendirebilir (bu durumda iletiyi "Al" için bir kopya ve "Neuman" için bir kopya göndermeye çalışır).

  1. "George Lovell, Ted Hackle"

Bu biçim, tek bir posta kutusunun birkaç kullanıcı tarafından paylaşıldığını belirtmek için kullanılabilir. Tırnak içindeki dize, "Shared-Mailbox at Office-1" hedef posta kutusunu tamamen belirttiği için kaynak ana bilgisayarın mailer'ı tarafından yok sayılır.

  1. Wilt (the Stilt) Chamberlain at NBA

"(the Stilt)" bir yorumdur ve kaynak sistemin mailer'ına verilen hedef posta kutusu adresine DAHİL EDİLMEZ. Adres "Wilt Chamberlain" dizgesidir ve birinci ve ikinci kelimeler arasında tam olarak bir boşluk bulunur. (Tırnak işaretleri dahil edilmez.)

B. Adres Listeleri

Gourmets:  Pompous Person <WhoZiWhatZit at Cordon-Bleu>,
           Cooks:  Childs at WGBH, Galloping Gourmet at
                   ANT (Australian National Television);,
           Wine Lovers:  Cheapie at Discount-Liquors,
                         Port at Portugal;;,
Jones at SEA

Bu grup listesi örneği, yorumların kullanımını, grupların iç içe yerleştirilmesini ve adreslerle grupların birlikte kullanılmasını gösterir. "Jones at SEA" ifadesinden önce gelen ardışık iki noktalı virgülün Jones'un Gourmets grubunun bir üyesi OLMADIĞI anlamına geldiğine dikkat edin.

C. Gönderici Öğeleri

1. Author-sent

George Jones ana bilgisayarına "Jones" olarak giriş yapar. Postayı kendisi gönderir.

From:  Jones at Host

veya

From:  George Jones <Jones at Host>

2. Secretary-sent

George Jones ana bilgisayarına Jones olarak giriş yapar. SHost üzerinde Secy olarak giriş yapan sekreteri onun adına posta gönderir. Postaya verilecek yanıtların elbette George'a gitmesi gerekir.

From:    George Jones <Jones at Host>
Sender:  Secy at SHost

3. Paylaşılan dizin veya temsili olmayan dizin adı

George Jones ana bilgisayarına Group at Host olarak giriş yapar. Postayı kendisi gönderir; yanıtlar Group posta kutusuna gitmelidir.

From:  George Jones <Group at Host>

4. Paylaşılan dizin kullanıcısı için sekreter tarafından gönderim

George Jones'un sekreteri, Host üzerinde Secy at Host olarak giriş yapmış durumdayken George adına ve Group üyesi sıfatıyla posta gönderir. Yanıtlar Group'a gitmelidir.

From:   George Jones <Group at Host>
Sender: Secy at Host

"Jones" ile "<" arasında boşluk bulunmasının zorunlu olmadığını, ancak boşluk eklemenin okunabilirliği artırdığını unutmayın (diğer örneklerde olduğu gibi).

5. Sekreterin yazarın tam temsilcisi olarak hareket etmesi

George Jones sekreterinden (Secy at Host) Group sıfatıyla onun adına bir ileti göndermesini ister. Tüm yanıtların sekreteri tarafından ele alınmasını ister.

From:     George Jones <Group at Host>
Sender:   Secy at Host
Reply-To: Secy at Host

6. Çevrimiçi posta kutusu olmayan kullanıcı için temsilci

George'un ARPANET kullanmayan bir arkadaşı olan Sarah ziyarettedir. George'un sekreteri Sarah'nın bilgisayar dünyasındaki bir arkadaşına posta gönderir. Yanıtlar posta kutusu Jones at Host olan George'a gitmelidir.

From:     Sarah Friendly
Sender:   Secy at Host
Reply-To: Jones at Host

7. Bir komite üyesi tarafından gönderim

George bir komitenin üyesidir. İletisine verilecek yanıtların tüm komite üyelerine gitmesini ister.

From:     George Jones
Sender:   Jones at Host
Reply-To: Big-committee: Jones at Host,
                         Smith at Other-Host,
                         Doe at Somewhere-Else;

George Big-committee listesinde kendisini saymamış olsaydı örtük bir yanıt alamayacağını unutmayın; "Reply-To" alanının varlığı "From" alanında adı geçen kişiye yanıt gönderilmesini geçersiz kılar.

8. YANLIŞ kullanım örneği

George yanıtın sekreterine gitmesini ister; bu nedenle sekreteri "From" alanından onun posta kutusu adresini çıkarır ve yalnızca adını bırakır; ancak bu kendi başına bir posta kutusu adresi değildir.

From:   George Jones
Sender: Secy at SHost

BUNA İZİN VERİLMEZ. Yanıtlar hiçbir zaman örtük olarak "Sender" alanına gönderilmez; George'un sekreterinin "Reply-To" alanını kullanması gerekirdi veya posta oluşturan programın sekreteri buna zorlaması gerekirdi.

9. Bir komite üyesi için temsilci

George'un sekreteri, "Big-committee" üyelerinin tamamı tarafından ortaklaşa hazırlanmış bir ileti gönderir.

From:   Big-committee: Jones at Host,
                      Smith at Other-Host,
                      Doe at Somewhere-Else;
Sender: Secy at SHost

V. Örnekler

D. Tam Başlıklar

1. Gerekli en az alan

Date:  26 August 1976 1429-EDT
From:  Jones at Host

2. Ek alanlardan bazılarını kullanarak

Date: 26 August 1976 1430-EDT
From: George Jones <Group at Host>
Sender: Secy at SHOST
To: Al Neuman at Mad-Host,
    Sam Irving at Other-Host
Message-ID: <some string at SHOST>

3. Karşılaşabileceğiniz en karmaşık örneklerden biri

Date     : 27 Aug 1976 0932-PDT
From     : Ken Davis <KDavis at Other-Host>
Subject  : Re: The Syntax in the RFC
Sender   : KSecy at Other-Host
Reply-To : Sam Irving at Other-Host
To       : George Jones <Group at Host>,
           Al Neuman at Mad-Host
cc       : Important folk:
           Tom Softwood <Balsa at Another-Host>,
           Sam Irving at Other-Host;,
           Standard Distribution::Include:
            </main/davis/people/standard at Other-Host,
             "<Jones>standard.dist.3" at Tops-20-Host>,
           (The following Included Postal list is part
           of Standard Distribution.)
           :Postal::Include: Non-net-addrs@Other-host;,
           :Postal: "Sam Irving, P.O. Box 001, Las Vegas,
                     Nevada" (So that he can stay
                     apprised of the situation)
Comment  : Sam is away on business. He asked me to handle
           his mail for him. He'll be able to provide a
           more accurate explanation when he returns
           next week.
In-Reply-To: <some string at SHOST>
Special (action): This is a sample of multi-word field-
           names, using a range of characters. There
           could also be a field-name "Special (info)".
Message-ID: <4231.629.XYzi-What at Other-Host>

Ek

A. Sözdizimi Kurallarının Alfabetik Listesi

APPENDIX

A. SÖZDİZİMİ KURALLARININ ALFABETİK LİSTESİ

address     = host-phrase / quoted-string
            / (*phrase "<" #address ">")
            / (*phrase ":" #address ";")
            / (":" ("Include" / "Postal" / atom) ":" address)

ALPHA       = <herhangi bir TELNET ASCII alfabetik karakter>

atom        = 1*<specials ve CTLs dışındaki herhangi bir CHAR>

CHAR        = <herhangi bir TELNET ASCII karakteri>

comment     = "(" *(ctext / comment / quoted-pair) ")"

CR          = <TELNET ASCII carriage return>

CRLF        = CR LF

ctext       = <"(", ")", CR, LF hariç herhangi bir CHAR ve
              linear-white-space dahil>

CTL         = <herhangi bir TELNET ASCII kontrol karakteri ve DEL>

date        = 1*2DIGIT ["-"] month ["-"] (2DIGIT / 4DIGIT)

date-field  = "Date" ":" date-time

date-time   = [day-of-week ","] date time

day-of-week = "Monday" / "Mon" / "Tuesday" / "Tue"
            / "Wednesday" / "Wed" / "Thursday" / "Thu"
            / "Friday" / "Fri" / "Saturday" / "Sat"
            / "Sunday" / "Sun"

delimiters  = specials / comment / linear-white-space

DIGIT       = <herhangi bir TELNET ASCII rakamı>

extension-field = <Bu belirtime resmi bir uzantı olarak
                  yayımlanmış bir belgede tanımlanan herhangi
                  bir alan>

field       = field-name ":" [field-body] CRLF

fields      = date-field originator-fields *optional-field

field-body  = field-body-contents
              [CRLF LWSP-char field-body]

field-body-contents = <field-body'yi oluşturan TELNET ASCII
                      karakterleri; aşağıdaki bölümlerde
                      tanımlandığı gibi atom, quoted-string
                      ve specials belirteçlerinin
                      birleşimlerinden oluşabilir veya
                      metinlerden oluşabilir>

field-name  = fnatom *(LWSP-char [fnatom])

fnatom      = 1*<CTLs, SPACE ve ":" hariç herhangi bir CHAR>

host-indicator = 1*(("at" / "@") node)

host-phrase = phrase host-indicator

hour        = 2DIGIT [":"] 2DIGIT [[":"] 2DIGIT]

HTAB        = <TELNET ASCII horizontal-tab>

LF          = <TELNET ASCII linefeed>

linear-white-space = 1*([CRLF] LWSP-char)

LWSP-char   = SPACE / HTAB

mach-id     = "<" host-phrase ">"

mailbox     = host-phrase / (phrase mach-id)

message     = fields *(CRLF *text)

month       = "January" / "Jan" / "February" / "Feb"
            / "March" / "Mar" / "April" / "Apr"
            / "May" / "June" / "Jun"
            / "July" / "Jul" / "August" / "Aug"
            / "September" / "Sep" / "October" / "Oct"
            / "November" / "Nov" / "December" / "Dec"

node        = word / 1*DIGIT

optional-field =
              "To"         ":" #address
            / "cc"         ":" #address
            / "bcc"        ":" #address
            / "Subject"    ":" *text
            / "Comments"   ":" *text
            / "Message-ID" ":" mach-id
            / "In-Reply-To"":" #(phrase / mach-id)
            / "References" ":" #(phrase / mach-id)
            / "Keywords"   ":" #phrase
            / extension-field
            / user-defined-field

originator-fields =
              ("From" ":" mailbox
               ["Reply-To" ":" #address])
            / ("From" ":" 1#address
               "Sender" ":" mailbox
               ["Reply-To" ":" #address])

phrase      = 1*word

quoted-pair = "\\" CHAR

quoted-string = <"> *(qtext / quoted-pair) <">

qtext       = <">, CR veya LF hariç herhangi bir CHAR ve
              linear-white-space dahil>

SPACE       = <TELNET ASCII boşluk>

specials    = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":"
            / "\\" / <">

text        = <herhangi bir CHAR, tek başına CR ve/veya LF dahil,
              ancak CRLF hariç>

time        = hour zone

user-defined-field = <Bu belirtimde tanımlanmamış veya bu
                     belirtime bir uzantı olarak yayımlanmamış
                     herhangi bir alan; bu tür alan adları
                     benzersiz olmalı ve yayımlanmış uzantılar
                     tarafından önceden alınabilir>

word        = atom / quoted-string

zone        = (("+" / "-") 4DIGIT)
            / (["-"] (1ALPHA
            / "GMT" / "NST" / "AST" / "ADT" / "EST" / "EDT"
            / "CST" / "CDT" / "MST" / "MDT" / "PST" / "PDT"
            / "YST" / "YDT" / "HST" / "HDT" / "BST" / "BDT"))

<">         = <TELNET ASCII tırnak işareti>

Ek

B. Basit Ayrıştırma

Bazı posta okuma yazılım sistemleri yalnızca asgari düzeyde işlem yapmak isteyebilir; yapılandırılmış alan gövdelerinin iç sözdizimini yok sayarak bunları yapılandırılmamış alan gövdeleriyle aynı şekilde ele alabilir. Bu tür yazılımlar yalnızca şu ayrımları yapmalıdır:

Aşağıda verilen kısaltılmış sözdizimi kuralları bu amaç için yeterlidir. Bunlar iletilerin sınırlı bir görünümünü tanımlar ve bu belirtimin ana bölümünde verilen sözdizimi kurallarının bir alt kümesidir. Küçük bir istisna olarak, alan gövdelerinin içeriği yalnızca metinden oluşur.

SÖZDİZİMİ

message         = *field *(CRLF *text)

field           = field-name ":" [field-body] CRLF

field-name      = fnatom *(LWSP-char [fnatom])

fnatom          = 1*<CTLs, SPACE ve ":" hariç herhangi bir CHAR>

field-body      = *text [CRLF LWSP-char field-body]

ANLAMSAL AÇIKLAMA

Başlıklar ileti gövdesinden önce yer alır ve boş bir satırla (yani ardışık iki CRLF ile) sonlandırılır.

Bir başlık alanını devam ettiren satır SPACE veya HTAB karakteriyle başlar; bir alanı başlatan satır ise iki nokta üst üste olmayan yazdırılabilir bir karakterle başlar.

Bir field-name, bir veya daha fazla yazdırılabilir karakterden (iki nokta üst üste hariç) oluşur ve her biri bir veya daha fazla SPACE veya HTAB ile ayrılır. Bir field-name TEK bir satırda bulunmalıdır. Alan adları karşılaştırılırken büyük ve küçük harf ayrımı yapılmaz.

Kaynakça

ANSI. Bilgi alışverişi için evrensel zamanın, yerel zaman farklarının ve Amerika Birleşik Devletleri zaman dilimi referanslarının gösterimleri. ANSI X3.51-1975; American National Standards Institute: New York, 1975.

Bhushan, A.K. Dosya Aktarım Protokolü. ARPANET Request for Comments, No. 354, Network Information Center No. 10596; Augmentation Research Center, Stanford Research Institute: Menlo Park, Temmuz 1972.

Bhushan, A.K. Dosya Aktarım Protokolü Üzerine Yorumlar. ARPANET Request for Comments, No. 385, Network Information Center No. 11357; Augmentation Research Center, Stanford Research Institute: Menlo Park, Ağustos 1972.

Bhushan, A.K., Pogran, K.T., Tomlinson, R.S. ve White, J.E. Ağ Postası Başlıklarının Standartlaştırılması. ARPANET Request for Comments, No. 561, Network Information Center No. 18516; Augmentation Research Center, Stanford Research Institute: Menlo Park, Eylül 1973.

Feinler, E.J. ve Postel, J.B. ARPANET Protokol El Kitabı. Network Information Center No. 7104; Augmentation Research Center, Stanford Research Institute: Menlo Park, Nisan 1976. (NTIS AD A003890).

McKenzie, A. Dosya Aktarım Protokolü. ARPANET Request for Comments, No. 454, Network Information Center No. 14333; Augmentation Research Center, Stanford Research Institute: Menlo Park, Şubat 1973.

McKenzie, A. TELNET Protokol Özellikleri. Network Information Center No. 18639; Augmentation Research Center, Stanford Research Institute: Menlo Park, Ağustos 1973.

Myer, T.H. ve Henderson, D.A. Mesaj İletim Protokolü. ARPANET Request for Comments, No. 680, Network Information Center No. 32116; Augmentation Research Center, Stanford Research Institute: Menlo Park, 1975.

Neigus, N. Dosya Aktarım Protokolü. ARPANET Request for Comments, No. 542, Network Information Center No. 17759; Augmentation Research Center, Stanford Research Institute: Menlo Park, Temmuz 1973.

Pogran, K., Vittal, J., Crocker, D. ve Henderson, A. ARPA ağ mesajlarının biçimi için önerilen resmi standart. ARPANET Request for Comments, No. 724, Network Information Center No. 37435; Augmentation Research Center, Stanford Research Institute: Menlo Park, Mayıs 1977.

Postel, J.B. Gözden Geçirilmiş FTP Yanıt Kodları. ARPANET Request for Comments, No. 640, Network Information Center No. 30843; Augmentation Research Center, Stanford Research Institute: Menlo Park, Haziran 1974.