요약

  • RFC 1079의TERMINAL-SPEED옵션은 원격 터미널 특성을 협상된 허가와 명시적 요청을 거친 후에만 사용할 수 있게 했다.
  • 응답은 표시 관련 선택을 안내할 수 있었지만, 네트워크 경로에 대한 사실을 확립하거나 TCP, 라우팅 또는 서비스 정책 변경을 승인하지는 않았다.

의도적으로 작은 역할을 맡은 숫자

초기 터미널 소프트웨어는 회선 속도의 영향이 눈에 띄게 드러나는 물리적 장치들을 수용해야 했다. 한 터미널에 맞는 리듬으로 전체 화면을 전송하는 프로그램은 다른 터미널에서는 사용할 수 없을 만큼 불편하게 느껴질 수 있었다. RFC 1079는 바로 그 실용적인 세계에서 출발한다. 운영체제는 직접 연결된 터미널과 모뎀의 비트 전송률을 보관하는 경우가 많았고, 딜레이 패딩 같은 타이밍에 민감한 표시 처리에 이를 사용했다. 일부 인터페이스는 빠른 터미널과 느린 터미널에 대해 서로 다르게 구성되기도 했다.

이 RFC는 텔넷이 네트워크를 탐지하도록 제안하지 않았다. 대신 비슷한터미널 정보가 텔넷 연결을 통해 제공될 수 있다고 제안했다. 이 선택이 중요한 이유는 같은 숫자라도 실제보다 훨씬 권위 있어 보일 수 있기 때문이다.9600,100은 측정값처럼 보인다. 그러나 RFC 1079에서 그것은 한 피어가 자신의 터미널 송수신 속도에 대해 제공하는 NVT ASCII 진술이다. 프로브도, 샘플링된 처리량 결과도, 중간 라우터의 진술도, TCP 연결이 다음에 무엇을 전달할지에 대한 약속도 아니다.

이 구분은 네트워크 측정의 문제가 아니다. 터미널을 향한 프로그램은 값을 받은 후 보수적인 표시 방식이 바람직하다고 판단할 수 있다. 반면 그 사실들이 중요하다면 다른 계층이 재전송, 흐름 제어, 현재 애플리케이션 상태 또는 사용자의 실제 반응을 관찰해야 한다. 표시 힌트는 모든 질문을 해결한다고 주장하지 않기에 오히려 유용하다.

허가는 값과 분리되어 있었다

RFC 854는 텔넷에 선택적 규약을 위한 일반적인 문법을 제공했다. 네트워크 가상 터미널(NVT)은 공통 폴백으로 남고,WILL,WON'T,DO,DON'T는 피어들이 더 풍부한 기능을 사용할지 합의하거나 거부하도록 한다. RFC 1079는 이 문법을 옵션 32인TERMINAL-SPEED에 적용한다.

기본값이 말해준다:WON'T TERMINAL-SPEED와DON'T TERMINAL-SPEED. 피어들이 그 기본값에서 벗어나지 않는 한 아무것도 교환되지 않는다.WILL은 피어가 이후 서브네고시에이션에서 터미널 속도 정보를 보낼 의사가 있음을 말한다.DO는 피어가 이를 받을 의사가 있음을 말한다. 어느 명령 자체도 보고가 아니다. 둘은 이후 대화를 위한 좁은 가능성을 여는 것뿐이다.

양쪽 명령이 모두 나타난 후에야DO TERMINAL-SPEED를 보낸 쪽이IAC SB TERMINAL-SPEED SEND IAC SE로 요청할 수 있다.WILL TERMINAL-SPEED를 보낸 쪽만이IAC SB TERMINAL-SPEED IS... IAC SE로 응답할 수 있다. 정보는 저절로 도착할 수 없다. 이것은 작지만 결과가 큰 권한 배분이다. 한쪽은 허가하고 요청을 발행하며, 다른 쪽은 요청된 특성을 제공한다. 제3자가 신탁이 되지 않고, 맨 willingness 토큰이 성능 결과가 되지도 않는다.

RFC 1079는 실제 응답이 선행 영 없이, 불필요한 공백 없이, 쉼표로 구분된 십진수 송수신 속도의 NVT ASCII 쌍이어야 한다고 요구한다. 이 엄격한 형식은 상호 운용 가능한 파싱을 지원한다. 그러나 이 문법이 표현된 장비, 중간 경로 또는 표시 동작이 정확하다는 증명으로 바뀌지는 않는다. 형식이 올바른 문자열은 규약에 맞는 교환 문법의 증거이지, 만능 증거 장부가 아니다.

RFC 자체의 조언은 로컬에 머문다

구현 제안은 경계를 더욱 선명하게 만든다. 시스템은 로컬에서 지원하는 터미널 속도의 이산적인 집합만 제공할 수 있다. 다른 값을 받으면 RFC 1079는 안전한 방향으로 가장 가까운 허용된 값을 선택할 것을 제안한다. 패딩에 대해서는 과잉 패딩이 부족한 것보다 낫기 때문에 올림이 더 안전할 수 있다고 말한다.

그것은 제공된 메타데이터에 대한 프로그램의 로컬 대응에 관한 지시다. 회선을 다시 형성하거나, 대역폭을 예약하거나, 모뎀을 재구성하거나, 라우터를 느리게 하거나, 혼잡을 추론하라는 지시가 아니다. 운영상의 선택은 로컬이며 되돌릴 수 있다. 프로그램은 원래 문자열을 보관하고, 자신이 선택한 값을 기록하고, 텔넷 스트림 아래의 네트워크를 통제했다고 주장하지 않으면서 이후 요청에서 표시 동작을 다시 조정할 수 있다.

RFC 1079가 자신의 모델로 명시한 터미널 유형 옵션 RFC 930은 유용한 인접 비교를 제공한다. 이는 허가와 이후의SEND/IS교환 사이의 동일한 분리를 사용하며, 터미널 유형을 전송하는 것이 즉시 처리 변경을 의미하지 않는다고 말한다. 두 옵션의 페이로드는 다르지만 공학적 규율은 공유한다. 상태 정보는 세션에 관여하는 모든 계층에 대한 명령이 되지 않으면서 원격 프로그램에 정보를 줄 수 있다.

그 값이 결정할 수 없는 것

받은1200,1200은 정의된 교환에서 한 텔넷 참여자가 그 ASCII 문자들을 보냈다는 주장을 뒷받침할 수 있다. 그러나 그것은 터미널이 그 속도로 물리적으로 연결되어 있음, 모뎀이 동기화되어 있음, TCP 경로가 같은 용량을 가짐, 패킷이 손실되지 않음, 사용자가 의도한 화면을 보고 있음, 또는 서비스 상호작용이 성공했음을 증명하지 않는다. 사람이나 터미널을 식별하지 않고, 어떤 행위를 승인하지 않으며, 특정 네트워크에서 텔넷의 현재 사용을 확립하지도 않는다.

이 경계들을 계속 보이게 유지하면 익숙한 확대가 막힌다. 로컬 특성이 숫자가 되고, 숫자가 가정된 측정이 되고, 가정된 측정이 전송 또는 운영 정책을 지시할 이유가 된다. RFC 1079는 그 이후 단계들을 제공하지 않는다. 선택적이고 요청된, 파싱 가능한 터미널 메타데이터 항목을 제공할 뿐이다. 더 넓은 주장에는 그에 맞는 관찰, 권한, 증거가 필요하다.

출처와 증거 경계

고정된 출처 집합은 RFC 1079, RFC 854, RFC 930, RFC 1123이다. RFC 1079는 옵션의 동기, 명령, 기본값, 응답 문법, 로컬 구현 제안을 제공한다. RFC 854는 텔넷 NVT와 협상 프레임워크를 제공한다. RFC 930은 역사적 요청/응답 비교를 제공하고, RFC 1123은 RFC 1079를 텔넷 참고문헌들 속에 위치시킨다. 어떤 것도 현재 배포, 특정 구현, 링크 용량, 경로 성능, 신원, 권한 부여, 접근성 또는 애플리케이션 결과를 확립하지 않는다.