코덱은 합의됐지만 니블은 그러지 못했다: RFC 2422

요약

• RFC 2422는 바이트 레이아웃을audio/32KADPCM계약의 일부로 만들었다. 먼저 온 코드워드가 하위 니블에 들어가고, 그 짝이 상위 니블에 들어간다.
• 샘플이 홀수 개의 코드워드로 끝나면 RFC는 무음 패딩을 우선하며, 그렇지 못한 경우 마지막 코드워드를 버린다. 이 규칙은 해석을 정하는 것이지, 녹음이 전달되거나 들렸는지 여부를 정하는 것이 아니다.

코덱은 이미 수학적 작업을 마친 상태였다. ITU-T 권고 G.726은 적응형 차분 펄스 부호 변조와 초당 8,000회 샘플링되는 64 kbit/s A법칙 또는 μ법칙 PCM과 32 kbit/s를 포함한 저속 채널 간의 변환을 기술했다. 32 kbit/s 속도에서는 4비트가 각 샘플을 나타낸다. 이는 구현자에게 코드워드가 어떻게 만들어지는지 알려준다. 그러나 그것만으로 파일 판독자에게 8비트 바이트의 어느 절반이 먼저 온 코드워드를 담는지 알려주지는 않는다.

이 구분은 코덱 설명 속에서 사라질 만큼 작지만, 상호 교환을 깨뜨릴 만큼 크다. 두 구현이 4비트 값의 순서에는 동의하면서도 각 쌍을 바이트의 반대쪽 절반에 직렬화할 수 있다. 옥텟은 양쪽 로컬 규약에서 모두 유효한 데이터다. 다른 규약을 사용하는 판독자는 서로 다른 시퀀스를 재구성한다. 결과가 반드시 깨진 파일이거나 실패한 메일 트랜잭션일 필요는 없다. 모호성은 한 겹 아래에 있다. 수신자는 MIME 서브타입만으로 발신자가 어떤 로컬 규약을 의도했는지 알 수 없다.

RFC 1911은 이미 실험적 Voice Profile for Internet Mail을 위한 필수 공통 오디오 형식 가운데Audio/32KADPCM을 배치했다. 이 문서는 제한된 메시징 프로필 안에서 이 부호화의 역할을 정했지만, 이 4비트 순서 문제는 해결하지 않았다. 1998년 9월에 Standards Track으로 발표되어 그 이전 등록을 명시적으로 다듬은RFC 2422가 간극을 좁혔다. 이 문서는 G.726 데이터를 위해audio/32KADPCM을 등록하고, 단일 직렬화 규약을 서브타입의 의미 일부로 만들었다.

매핑은 정확하다. 모든 옥텟에서 첫 번째 코드워드 A는 비트 0~3을 차지하며, 최하위 비트 A0는 옥텟의 최하위 위치에 놓인다. 다음 코드워드 B는 비트 4~7을 차지하며, B3가 옥텟의 최상위 끝에 놓인다. 이후의 각 쌍도 이 배치를 반복한다. 이는 오디오 스트림 전체를 뒤집거나 G.726의 적응형 예측기를 바꾸는 것이 아니다. 한 바이트 안의 두 니블에 대한 순서 규칙이다.

이 정밀함은 또한 책임을 배정한다. RFC 2422는 기존 G.726 코덱이 서로 다른 코드워드 순서를 사용할 수 있다고 적는다. 이 MIME 타입은 하위 엔디안 배치만 허용하므로, 반대 규약을 쓰는 코덱은 이 타입에 데이터를 저장하기 전이나 꺼내온 후 코드워드를 재정렬해야 한다. 공통 이름만으로 그 코덱들이 상호 운용 가능해지지는 않았을 것이다. 표준은 변환 지점을 경계에서 판독 가능하고 검증 가능하게 만들며, 각 구현 쌍에 비공개 협상을 남겨두지 않는다.

불완전한 마지막 쌍은 또 다른 경계를 드러낸다. RFC는 음성 샘플을 무음으로 확장해 부호화된 값이 짝수 개의 코드워드를 갖도록 하는 것을 우선한다. 홀수로 남으면 마지막 코드워드는 버려진다. 이 지시는 조용한 마무리에 대한 미학적 권고가 아니라, 파서에게 남는 반 바이트의 의미를 알려주는 것이다. 이것이 없으면 컨테이너는 바이트 경계에서 끝나고 코덱 시퀀스는 니블 사이에서 끝나며, 판독자는 마지막 절반이 계산되는지에 대한 명시되지 않은 규칙이 필요해진다.

이 서브타입에는 필수 또는 선택 매개변수가 없다. 본문은 오디오 헤더 없이 G.726 이진 오디오를 담으며, MIME 전송 부호화는 이를 이진 또는 일반적으로 Base64로 운반할 수 있다. 이들은 별개의 결정이다. Base64는 본문 옥텟이 메일 시스템을 통과하는 방식을 바꾸지만, 본문이 디코딩된 뒤 어느 니블이 A나 B를 담는지는 바꾸지 않는다. 전송 부호화를 코드워드 순서의 답으로 취급하면 바이트를 둘러싼 봉투와 바이트 자체에 부여된 의미를 혼동하게 된다.

따라서 RFC 2422는 표준 작업에 대해 압축적이지만 결과가 큰 이야기를 전한다. 변환을 정의하는 것만으로 상호 운용 가능한 대상을 정의하기에 충분하지 않을 수 있다. 출력이 경계를 넘는 순간, 순서와 패딩과 책임도 계약의 일부가 된다. 이 문서는 규칙이 얼마나 널리 구현되었는지, 특정 코덱이 틀렸는지, 수신자가 메시지를 들었는지는 보여주지 않는다. 구현이 어디에서 선택을 명시해야 하는지, 그리고 MIME 서브타입이 어디서 그 선택을 로컬 문제로 남겨두는 것을 멈추는지는 보여준다.