요약

  • RFC 1865는 기존 EDI 시스템 간의 전송 경로를 인터넷 메일로 대체하는 방안을 제안했으며, 파트너 시스템으로의 직접 SMTP 전달을 '보장된(assured)' 것으로 기술했다. 이 문서는 쌍방 거래 파트너 협약을 그대로 유지했고, 도착을 상업적 수용과 동일시하지 않았다.
  • RFC 1767는 EDI 객체의 구문과 의미를 보존하면서 MIME 전송 수단을 추가했다. 이후 RFC들은 서명된 MDN, 원본 메시지 상관관계, 반환된 콘텐츠 MIC를 추가했지만, 성공적인 처리와 거래의 유효성은 계속 분리해 두었다.
  • 정직한 수신 사다리는 SMTP 수용, 메일 시스템 전달, 암호학적 수신 확인, EDI 처리, 애플리케이션 승인, 그리고 상업적 결정이다. 각 단계에는 자체적인 근거와 권한이 필요하다.

미완의 거래를 가진 '보장된' 도착

1996년에 공급자가 구매 주문서를 구매자에게 전자적으로 보내는 상황을 상상해 보자. 봉투는 공급자의 EDI 시스템을 떠나 인터넷 메일 경로를 거쳐 구매자가 운영하는 서버에 도달한다. 발신자는 성공적인 SMTP 교환을 보여줄 수 있다. 그렇다면 구매자는 주문을 수용한 것일까?

답은 여전히 '아니다'이다. 전달된 객체는 형식이 잘못되었을 수 있고, 중복되었을 수 있으며, 잘못된 파트너에 매핑되었을 수 있고, EDI 번역기에 의해 거부되었을 수 있고, 애플리케이션 규칙에 따라 보류되었을 수 있고, 상업 협약에 따라 기각되었을 수 있다. 기술적으로 완벽한 객체조차도 구매자가 받아들이지 않을 가격, 수량 또는 납기일을 요구할 수 있다. 전송은 자신의 한 가지 임무를 완료했을 뿐이며, 다음 단계를 수행할 권한을 얻지 못했다.

RFC 1865는 1996년 1월에 Informational로 발표되었으며, 인터넷을 아직 모를 수 있는 EDI 커뮤니티를 위한 FAQ 형식으로 작성되었다. 이 문서의 핵심 전략은 실용적이었다. 비즈니스 애플리케이션과 EDI 번역 시스템은 그대로 두고, 통신 구성 요소만 인터넷 모듈로 교체하는 것이었다. 이 문서는 전용 SMTP 연결을 거래 파트너의 시스템으로 직접 전달하며 전달이 '보장된' 것으로 묘사하면서도, 일반적인 store-and-forward의 무결성은 중계 시스템에 의존한다는 점을 함께 언급했다.

이 주장은 정확한 명사에 속한다. 파트너의시스템이 메일을 수신했다. 이 FAQ는 비즈니스 애플리케이션이 교환을 처리했다고 말하지 않았고, 거래가 유효해졌다고도 말하지 않았다. '보장된'을 상업적 완결로 읽는다면, 문서가 여전히 파트너에게 부여한 질문을 메일 서버가 결정하는 셈이 된다.

EDI는 전자상거래보다 좁은 개념이었다

RFC 1865는 전자식 데이터 교환(EDI)을 표준화된 비즈니스 정보의 애플리케이션 간 통신으로 정의했다. 그리고 이를 인간 통신, 자금 이체, 공유 정보 자원을 포함할 수 있는 더 넓은 범주인 전자상거래와 구분했다.

이 구분은 현대적 지름길을 차단한다. EDI 봉투는 구매 주문서, 송장 또는 출하 통지일 수 있지만, 표준화되어 있다는 사실 자체가 결제, 이행 또는 동의를 초래하지는 않는다. 교환은 비즈니스 프로세스에 대한 입력이다. 그 프로세스에는 메시지 전송을 넘어서는 행위자, 정책, 결과가 존재한다.

이 RFC는 쌍방 거래 파트너 협약도 그대로 유지했다. 기존 협약은 독점 메일박스 이름 대신 인터넷 주소를 사용하도록 조정될 수 있었다. EDI 동의 콘텐츠는,RFC 1767이 명시했듯이, 당사자들 사이에 명시적인 쌍방 협약이 있을 때만 사용 가능했다.

이것이 기술적 서사 안에 있는 제도적 경계이다. 인터넷 프로토콜은 전송의 상호운용성을 만들 수 있었다. 그러나 어떤 사람이 회사를 구속할 권한이 있는지, 무엇이 중복 주문인지, 어떤 승인이 최종적인지, 근거를 얼마나 오래 보존해야 하는지, 분쟁에 어떤 관할법이 적용되는지는 결정할 수 없었다.

MIME은 상업적 의미가 아니라 전송 구성 요소를 교체했다

RFC 1767는 EDI-X12, EDIFACT 및 쌍방 합의된 EDI 동의 객체를 위한 MIME 콘텐츠 타입을 규정했다. 'EDI가 이메일로 이동했다'는 거창한 주장보다 이 RFC의 프로세스 다이어그램이 더 많은 것을 드러낸다. 발신 측에서는 비즈니스 프로그램이 데이터를 생성하고, EDI 번역기가 교환을 만들고, MIME 프로세서가 이를 감싸고, 메일 서브미션과 SMTP가 이를 운반했다. 수신 경로는 MIME 래퍼를 제거하고 EDI 객체를 번역기에 전달한 뒤에야 비즈니스 처리에 도달했다.

이 RFC는 기반이 되는 EDI 구문과 의미를 전혀 변경하지 않았다고 명시했다. 또한 그 자체로는 보안 메커니즘을 제공하지 않았다. MIME 타이핑은 바이트가 어떤 종류의 객체라고 주장하는지, 그리고 이를 인터넷 메일을 통해 어떻게 운반할 수 있는지에 답했다. 그러나 X12 또는 EDIFACT 콘텐츠가 유효한지, 명명된 파트너가 보냈는지, 변경되지 않고 도달했는지, 수신 애플리케이션이 비즈니스 조건을 수용했는지를 증명하지는 않았다.

이것은 인터넷에서 반복되는 패턴이다. 공통 봉투가 연결 장벽을 제거하면, 관찰자들은 그 봉투를 콘텐츠에 대한 판결로 잘못 승격시킨다. RFC 1767은 그렇게 하지 않도록 신중했다. 전송 구성 요소만 교체된 것이다.

SMTP의 수신 확인은 메일 경계에서 멈췄다

SMTP에는 전달처럼 들릴 수 있는 여러 순간이 있다. 릴레이는 메시지에 대한 책임을 수용할 수 있다. 최종 서버는 수신자와 메시지 데이터를 수용할 수 있다. 저장소는 메시지를 사용자 에이전트가 사용할 수 있게 만들 수 있다.RFC 5321은 성공적인 완료를 메일 프로토콜 하에서의 책임 이전으로 다룬다. 이는 구매자의 상업적 응답을 정의하지 않는다.

실패 사례들은 용어가 왜 중요한지를 보여준다. 발신자는 긍정적인 SMTP 응답을 받았는데, EDI 사용자 에이전트가 나중에 구문 실패를 보고할 수 있다. 타임아웃과 재시도 이후 메시지가 두 번 도착할 수 있다. 서버가 메일박스를 식별하지만 올바른 거래 파트너 프로필을 식별하지 않는 주소로 라우팅할 수 있다. 암호학적 검사는 성공하면서도 인증서가 구매 권한이 없는 행위자에 매핑될 수 있다.

따라서 운영 기록은 어떤 경계가 각 수신 확인을 발행했는지를 보존해야 한다. '발송됨', '수용됨', '전달됨'은 행위자 없이는 불완전하다. 발신 릴레이에 의해 수용되었는지, 수신 메일 전송 에이전트에 의해 수용되었는지, EDI 게이트웨이, 번역기, 비즈니스 애플리케이션 또는 권한 있는 상업 프로세스에 의해 수용되었는지가 명시되어야 한다.

서명된 수신 확인이 더 나은 근거를 구축했다

2002년까지RFC 3335는 더 완전한 인터넷 EDI 보안 모델을 기술했다. 메시지는 무결성과 진정성을 위해 서명되고, 프라이버시를 위해 암호화될 수 있었다. 메시지 처리 통지(MDN)는 원본 메시지 식별자, 수신된 콘텐츠에 대해 계산된 메시지 무결성 검사(MIC), 그리고 수신 파트너의 서명을 반환할 수 있었다.

이 구성 요소들은 서로 다른 질문에 답했다. 메시지 식별자는 응답과 이전 발송을 상관관계로 연결했다. 반환된 MIC는 발신자가 수신자가 수신했다고 말한 내용의 다이제스트를 발신자의 기록과 비교할 수 있게 했다. 수신자 서명은 관련 키와 인증서 정책 하에서 응답을 귀속 가능하게 만들었다. 발신자 검증은 암호학적 루프를 완성했다.

RFC 3335는 수신의 부인 방지를 법적 사건으로 위치시키는데, 이는 발신자가 서명된 수신 확인을 검증한 이후에만 해당된다고 규정했다. 이렇게 더 강한 표현조차도 이 프로토콜을 보편적인 법으로 만들지는 못했다. 서명에는 유효한 경로, 적용 가능한 정책, 권한 있는 서명자가 필요하다. 근거는 법적 결론을 지지할 수 있지만, 그 결론을 내리는 제도 자체를 없애지는 못한다.

서명된 MDN은 실패를 보고할 수 있었다

RFC 4130, 즉 AS2 사양은 이 구분을 무시할 수 없게 만들었다. 서명된 수신 확인이 요구되는 경우, 수신자는 콘텐츠 처리가 실패했을 때조차 하나를 반환해야 했다. 실패는 disposition 필드에 담겼다.

이것은 강력한 설계 선택이다. 수신 확인이 성공적인 비즈니스 처리에만 존재한다면, 침묵은 네트워크 손실, 수신자 중단, 서명 실패, 구문 거부, 정책 거부를 하나로 뒤섞어 버린다. 반대로 서명된 부정적 disposition은 수신자가 특정 실패 상태에 도달했다는 근거를 제공한다. 이 수신 확인이 가치 있는 것은 거래가 성공했다고 가장하지 않기 때문이다.

RFC 4130은 또한 합의된 서명 수신 확인이 요구되었지만 반환되지 않은 경우 거래 파트너들이 거래 유효성을 해결해야 하며, 그 거래는 아마도 유효하지 않은 것으로 간주되지 않을 것이라고 말했다. 이 프로토콜은 증거 요건을 지원했지만, 수신의 부인 방지를 정의하지는 않았다. 그것은 여전히 비즈니스 또는 법적 요건으로 남아 있었다.

이 결과는 우연한 모호함이 아니다. 설계된 업무 분담이다. AS2는 수신된 콘텐츠와 그 disposition에 대한 서명되고 상관관계가 연결된 진술을 생산할 수 있다. 재시도, 주문 상태, 책임, 구제 수단에 대해 그 진술이 무엇을 의미하는지는 파트너들이 결정한다.

표시(display)가 곧 이해는 아니었다

RFC 3798의 일반 MDN 사양은 또 하나의 유용한 경고를 추가한다. 수신자는 MDN 요청을 무시할 수 있다. 그리고displayeddisposition은 사람이 콘텐츠를 읽었거나 이해했다는 것을 보장하지 않는다.

이 제약은 자동화된 EDI에서조차 중요하다. 유혹은 가장 진보된 수신 확인을 최종 확인으로 만드는 것이다. SMTP 응답이 전달이 되고, MDN이 처리가 되고, 서명이 권한이 되고, 표시가 이해가 된다. 각 승격마다 남아 있는 행위자 하나가 버려진다.

더 안전한 모델은 여섯 개의 기록을 유지한다:

  1. 발신자가 정확한 교환을 제출했다;
  2. 메일 시스템이 이를 수용하거나 전달했다;
  3. 수신자가 상관관계가 연결되고 가능하면 서명된 disposition과 MIC를 반환했다;
  4. 수신자의 EDI 체계가 이를 구문 분석하고 처리했다;
  5. 비즈니스 애플리케이션이 자체적인 기능 승인 또는 상태를 발행했다;
  6. 권한 있는 상업 프로세스가 거래를 수용, 거부 또는 수정했다.

모든 체계가 여섯 개의 근거를 모두 사용하는 것은 아니며, 명칭도 표준마다 다르다. 불변은 한 계층의 근거가 다음 계층의 권한을 조용히 행사할 수 없다는 것이다.

분산된 전송은 쌍방 거버넌스를 지우지 않았다

RFC 1865는 인터넷을 부가가치 네트워크와 대조하고, 분산 디렉터리 서비스와 협력적 라우팅 및 주소 해석을 기술했다. 신뢰성을 위해 중복 공급자와 메일 서버도 제안했다. EDI 활동 자체는 중앙 인터넷 조율을 요구하지 않았다. 물론 인터넷 연결성을 얻고 운영하는 것은 그랬다.

이것은 의존성의 형태를 바꾸었다. 독점 메일박스 운영자는 더 이상 모든 교환의 중심에 서 있을 필요가 없었다. 그러나 전송을 탈중앙화하는 것이 거래 관계를 허가 불필요하게 만들지는 않았다. 주소, 콘텐츠 규약, 보안 선택, 그리고 수신 확인의 결과는 여전히 당사자들 사이에서 합의되었다.

이 조합은 역사적으로 중요하다. 개방된 전송은 전송 계층에서 대체 가능성을 확장했으며, 협약은 신원, 권한, 책임을 계속 운반했다. 인터넷은 하나의 글로벌 상대방으로서 상거래를 해결하지 않았다. 대신 상대방들에게 감사 가능한 교환을 구축할 수 있는 공유된 기술적 기반을 제공했다.

이 사양들이 정직하게 증명할 수 있는 것

공식 기록은 한정된 결론을 지지한다. RFC 1865는 인터넷 메일을 EDI 전송으로 사용하는 초기 사례를 문서화하고 파트너의 시스템으로의 직접 전달을 기술했다. RFC 1767는 EDI 의미를 변경하거나 보안을 추가하지 않으면서 MIME 캡슐화를 표준화했다. RFC 3335와 RFC 4130은 서명, 상관관계, MIC를 둘러싼 더 강한 근거를 구축하면서 수신 확인과 비즈니스 유효성 사이의 차이를 보존했다. RFC 3798은 표시조차도 이해와 동일시하지 않았다.

이 자료들은 명명된 기업 배치, 수용된 구매 주문서, 이루어진 결제, 서명된 MDN을 집행한 법원을 보여주지 않는다. 이 자료들은 모든 AS2 구현이 올바르게 동작한다거나 하나의 법적 해석이 모든 곳에 적용된다는 것을 입증하지 않는다.

지속되는 교훈은 더 작고 더 유용하다. 인터넷 EDI가 신뢰할 수 있게 된 것은 '보장된'이라 불리는 하나의 수신 확인을 찾았기 때문이 아니라, 발행자, 범위, 결과를 독립적으로 검토할 수 있는 일련의 수신 확인을 보존했기 때문이다. 거래는 상업적 권한을 가진 당사자가 지배하는 합의 하에 그렇다고 말했을 때만 완성된 것이다.

출처