RCTE Üzerine Tartışma

Aşağıda, RFC 718’in yayımlanmasını izleyen RCTE konulu bir diyalogun önemli bölümü yer almaktadır.

15-Tem-76 Nancy Mimno (BBN-NET)

Jon,

RFC 718’i okudum ve özellikle "üçüncü sorun" ya da giriş arabelleğinin temizlenmesi kısmıyla ilgili bazı yorumlarım var.

Belirtilen uygulamanın ters olduğunu düşünüyorum: RCTE modu uzlaşmasının normal durumunda sunucu "WILL RCTE" gönderir ve kullanıcı "DO RCTE" gönderir; ters durumda ise sunucu "DO RCTE" ve kullanıcı "WILL RCTE" gönderir. Ayrıca, sunucunun "DO RCTE" göndermesinin, kullanıcı sürecinin "WILL (ya da WON'T) RCTE" ile yanıt vermesini gerektirdiğinin ve bu yanıtın eşzamanlama işareti olduğunun açıkça belirtilmesi muhtemelen yerinde olacaktır.
Sorun gerçektir ve RCTE protokolünün bir "girişi temizle, sayaçları sıfırla" işleviyle daha iyi olacağını düşünüyorum. Soru, bunun şimdi nasıl yapılacağıdır. Dün Ray ile konuşurken, bunu RCTE ile sınırlı olmayan genel bir işlev olarak düşündüğünü öğrendim; nitekim TENEX, bağlantı RCTE modunda olsun ya da olmasın, "giriş arabelleğini temizle" için "ters RCTE" seçeneğini gönderiyor. Bu durumda, "RCTE seçeneğinin normal kullanımıyla karıştırılamaz" ifadesi her zaman doğru olmayacaktır. İkimizin de mevcut çözümün yalnızca geçici bir çözüm olması gerektiği konusunda hemfikir olduğumuzu düşünüyorum.
Bu işlevi, eşzamanlama-verii̇şareti (synch-datamark) dizisini kullanarak gerçekleştirmek için farklı bir yol öneriyorum. İlk olarak, RCTE seçeneğinin bu işlevin sayaçları sıfırlamasını ve elbette verii̇şareti ile eşzamanlı olacak şekilde bir "giriş arabelleğini (veriden) temizle" işlemi gerçekleştirmesini açıkça gerektirmesi gerekir. Bu, sayaçların sıfırlanması dışında, şu anda olduğu haliyle büyük ölçüde aynıdır; RCTE içindeyken eşzamanlama-verii̇şaretinin alınmasının muhtemelen zaten tanımlanması gerekiyordu. RCTE, her iki taraf da kabul etmedikçe çalışmayacağından, eşzamanlama-verii̇şareti için "girişi temizle ve sayaçları sıfırla" anlamı RCTE seçeneğinin zorunlu bir parçası olmak zorunda olacaktır. İkinci olarak, eşzamanlama-verii̇şareti "tek yönlü" bir işlev olduğundan, bağlantının bir tarafının diğer tarafa "bana bir eşzamanlama-verii̇şareti gönder" demesini sağlayacak bir yol gereklidir. Yeni Telnet protokolü belirtimi, Abort Output’un (AO) bu amaçla kullanılabileceğini ima ediyordu; değilse, belki yeni bir işlev tanımlanabilir. Yine, RCTE seçeneği AO’nun bu yorumunu gerektiren (ya da çok güçlü biçimde öneren) açık bir ifade içermelidir. RCTE dışı mod için bu hoş bir fikir olsa da muhtemelen gerekli değildir. Ray geçici olarak kabul etti—TENEX’te (sunucu tarafında) çalışabileceğini düşünüyor. Senin ve Doug Dodds’un (TENEX kullanıcı RCTE) yorumlarını almak isterim. Değişmesi gerekecek başka mevcut RCTE uygulaması bilmiyorum. Ayrıca günümüzde resmi protokolleri genişletmenin ne gerektirdiğini de bilmiyorum, ancak belki bunu yapmak yeni bir seçenek (yani ters RCTE) tanımlamaktan daha kolaydır.

Saygılarımla,
Nancy

15-Tem-76 Doug Dodds (BBN-RCC)

Nancy,

RCTE-temizleme işlevinin (RCTE açıkken) AO komutuyla gerçekleştirilmesine yönelik önerin iyi bir öneri. TENEX Kullanıcı Telnet’i (NTELNET) tarafında bununla ilgili bir sorun görmüyorum. Şu anda NTELNET, AO’yu (ve bazı diğer komutları) tamamen yok sayıyor; bu, onu genel olarak uygulamak için iyi bir fırsat.

Doug

21-Tem-76 Jon Postel (SRI-ARC)

RCTE-temizleme işlevini ve diğer RCTE özelliklerini görüşmek üzere Ray Tomlinson ile birkaç dakikalık bir toplantı yaptım. Temizleme işlevi için AO komutunun kullanılmasına yönelik Nancy’nin önerisinin mantıklı olduğu konusunda anlaştık. Ayrıca, RCTE kullanılırken bazı diğer seçeneklerin hangi durumda olması gerektiğine ilişkin RCTE belgesinin bir şeyler söylemesi gerektiğini belirledik. Örneğin, RCTE kullanımdayken GO-AHEAD’in bastırılması gerektiğine, RCTE’den çıkıldığında ECHO modunun RCTE’ye girildiği zamanki durumuna geri getirilmesi gerektiğine ve BINARY ile RCTE’nin bir kombinasyon olarak anlamlı olmadığına inanıyoruz; çünkü her baytın bir kesme karakteri olduğu varsayılmak zorunda kalınacaktır. Ayrıca, kesme karakterleri olmadan RCTE kullanmanın uygulanamaz olduğunu belirledik; çünkü bu durumdan çıkmanın bir yolu yoktur.

22-Tem-76 Jon Postel (SRI-ARC)

Yukarıdaki tartışmanın bir sonucu olarak, gözden geçirilmiş bir RCTE belirtim belgesi hazırlayacağım. Bir taslak, yorumlar için ilgili taraflara dağıtılacak ve nihai belge bir RFC olarak yayımlanacaktır.