요약

  • RFC 1312는 TCP와 UDP 위의 실험적(Experimental) 단문 메시지 서비스를 정의했으며, 수신자, 단말, 발신자, 쿠키, 서명 필드를 두었으나 이 필드들의 의미가 항상 하나의 실제 화면이나 사람을 식별하지는 않았습니다.
  • TCP의+확인 응답은 메시지가 어떤 사용자나 단말에 성공적으로 전달되었음을 의미했지만, RFC는 그 결론을 명시적으로 제한했습니다. 서버가 로컬 전달 서비스를 호출했음만 나타낼 수 있다는 것입니다.
  • 이 명세는 확인 응답이 화면 표시나 사용자의 메시지 읽기·처리를 기다리도록 요구하지 않았습니다. 따라서 긍정 응답은 사람의 주의 영수증이 아니었습니다.

분석

메시지는 사람에게 가기 전에 여러 목적지를 가질 수 있었다

RFC 1312는 1992년 4월에, 호스트의 사용자와 단말로 향하는 단문 메시지를 위한 실험적 프로토콜로 등장했습니다. 메시지 형식은 리비전 옥텟으로 시작해 널 종료 필드들인 수신자, 수신자 단말, 메시지, 발신자, 발신자 단말, 쿠키, 서명으로 이어졌습니다. 패킷이 작다는 것이 대상을 단순하게 만들지는 않았습니다.

수신자 필드가 비어 있으면 대상 시스템의 임의 사용자에게 전달될 수 있었습니다. 단말이 비어 있으면 시스템이 ‘올바른’ 단말을 선택하게 되는데, 이는 시스템 의존적 기능입니다. 단말 필드의 별표는 모든 단말을 의미했습니다. 수신자와 단말이 모두 비어 있으면 메시지는 콘솔로 가야 했는데, 이는 이름이 지정된 장치가 아니라 운영자나 관리자가 볼 가능성이 있는 장소입니다. 이들은 유용한 전달 지침입니다. 그러나 특정 식별된 사람, 하나의 보이는 화면, 주의를 기울인 인간에게 도달했음을 보여주는 증거는 아닙니다.

이 구분이 중요한 이유는 프로토콜의 어휘가 일상 언어와 가깝기 때문입니다. “수신자”, “단말”, “전달됨” 같은 말이 서비스 단계의 기록을 사회적 사실처럼 들리게 할 수 있습니다. RFC 1312는 그런 전환을 막을 만한 대안들을 충분히 남겨 둡니다. 호스트가 단말을 선택할 수 있고, 메시지가 임의 사용자를 겨냥할 수 있으며, 콘솔은 개인이 아니라 기능적으로 정의됩니다. 이 필드들은 수신 시스템 내부의 요청과 라우팅 선호를 표현할 뿐입니다. 누가 그 자리에 있었는지, 어떤 인터페이스가 나타났는지, 내용이 누군가의 인식에 들어갔는지는 결정하지 않습니다.

플러스 기호에는 특정한 역할이 있었다

TCP 서비스는 포트 18에서 수신했습니다. 연결이 수립되고 클라이언트가 메시지를 보내면, 서버는 한 문자를 돌려보냈습니다. 긍정의+또는 부정의뒤에 선택적 설명이 붙습니다. 긍정 형식은 메시지가 어떤 사용자나 단말에 성공적으로 전달되었음을 의미했고, 부정 형식은 어느 단말에도 전달되지 않았음을 의미했습니다. 그 자체로 이미 유용한, 경계가 분명한 운영적 구분입니다.

RFC는 그러나 이를 종단 간 의식으로 확장하지 않습니다. 긍정 확인 응답은 Message Send 서버가 로컬 메시지 전달 서비스 호출에 성공했음만 나타낼 수 있습니다. 저자들은 진정한 종단 간 의미를 추론할 수 없을 수도 있다고 말합니다. 그들은 미해결 대안을 구체적으로 제시합니다. 확인 응답은 로컬 서비스로의 인계, 메시지를 표시하는 창 시스템, 또는 팝업을 닫아 읽었음을 확인하는 사용자 중 무엇에도 대응할 수 있다는 것입니다. 프로토콜은 어느 것인지 규정하지 않습니다.

이것은 각주에 숨겨진 결함이 아닙니다. 계약 자체의 경계입니다.+를 받은 클라이언트는 서버가 보고하는 단계에 도달했다는 증거를 가집니다. 그러나 선택된 로컬 메커니즘이 창을 보이게 만들었다는 증거, 창이 보이는 상태로 유지되었다는 증거, 의도된 사람이 단말에 있었다는 증거, 누구든 내용을 이해했다는 증거, 응답이나 후속 조치가 이루어졌다는 증거는 갖지 못합니다. 각 진술은 후속 구성 요소, 그리고 와이어 프로토콜이 의도적으로 다루지 않는 인간의 과정으로부터의 증거를 필요로 합니다.

UDP의 침묵과 쿠키는 서로 다른 문제를 풀었다

UDP 서비스는 이 경계를 더욱 선명하게 만들었습니다. 서버는 응답 데이터그램을 보낼 수 있었습니다. 특정 사용자에게 주소된 메시지가 그 사용자에게 성공적으로 전달된 경우에는 긍정 확인 응답을 보내야 했습니다. 임의 사용자 메시지나 전달 실패의 경우에는 응답을 보내지 않았습니다. RFC는 이 비대칭을 브로드캐스트 동작을 위한 절충으로 설명합니다. 모든 서버에 응답을 요구하면 광범위한 전송이 부적절한 응답 트래픽을 낳게 됩니다.

따라서 침묵을 마음대로 실패라고 부를 수 없고, 응답을 보편적 완료로 과대평가할 수도 없습니다. 두 경우는 각자의 조건과 절충을 가집니다. 쿠키도 마찬가지입니다. 발신자의 UDP 포트와 결합된 쿠키는 서버가 중복 메시지를 식별할 만큼 충분히 고유해야 했습니다. 클라이언트는 수신 가능성을 높이기 위해 메시지를 여러 번 보낼 수 있고, 서버는 반복을 폐기할 수 있습니다. 이것은 명시된 범위 안의 중복 처리 보조 장치입니다. 첫 번째 사본이 화면에 도달했다는 증거도, 중복 제거가 올바른 사람을 지목했다는 증거도, 주의의 영수증도 아닙니다.

신원은 발신자 모양의 필드가 공급하지 않았다

프로토콜에는SIGNATURE필드도 있지만, 그 필드가 즉석 신원 확인 결과가 되도록 허용하지 않습니다. 빈 서명은 발신자의 신원을 검증할 수 없습니다. 비어 있지 않은 서명은 어떤 보안 토큰의 대소문자 구분 없는 텍스트 인코딩일 뿐이며, RFC 1312는 그 인코딩이나 해석을 정의하지 않습니다. 보안 절은 또한 표시되는 텍스트의 필터링을 요구하고, 권한 없이 사용자의 단말에 쓰는 것의 위험을 경고합니다.

이 세부 사항들은 같은 증거 규율을 강화합니다. 발신자 문자열, 출발지 주소, 토큰 모양의 필드, 로컬 전달 시도는 서로 다른 계층에 속합니다. 로컬 표시 메커니즘을 호출하는 서비스조차 표시된 텍스트가 안전했으며, 소위 발신자가 검증되었으며, 사용자가 수신에 동의했다는 것을 조용히 주장해서는 안 됩니다. RFC는 좁은 메시지 서비스를 제공할 뿐, 사람에 대한 증명 체계를 제공하지 않습니다.

유용한 결론은 읽음 확인보다 작다

RFC 1312는 1992년의 실험적 명세이며, 오늘날의 알림, 채팅 시스템, 배포에 대한 주장이 아닙니다. 그 역사적 가치는 기록한 정확한 절제에 있습니다. 긍정 응답은 로컬 처리에 대한 정당한 영수증이 될 수 있습니다. 다른 구성 요소가 표시, 상호작용 또는 인간 응답의 증거를 만들어 내지 않는 한, 그것은 거기서 멈춥니다.

이 순서는 수신자뿐 아니라 운영자도 보호합니다. 알림 시스템이 로컬 호출을 확인된 읽음이라고 부르는 것을 막고, 감사 기록이 단말 이름으로부터 동의를 만들어 내는 것을 막으며, 빠진 증거의 지점을 녹색 상태 아이콘으로 채우는 대신 보이게 만듭니다.

출처

RFC 1312는 1992년의 실험적 메시지 서비스를 규정합니다. 실제 수신자, 표시, 읽기, 동의, 신원, 배포 또는 결과를 증명하지 않습니다.