요약

  • RFC 3454는 매핑, 정규화, 금지, 양방향 규칙 검사라는 순서가 정해진 프레임워크를 정의했지만, 이를 사용하는 모든 프로토콜은 여전히 자체 프로파일, 문자 레퍼토리 및 정책을 명시해야 했습니다.
  • 동일한 준비된 출력은 해당 프로파일과 유니코드 버전 기준의 동등함을 의미했을 뿐입니다. 동일한 철자, 시각적 외양, 사용자 의도, 계정 통제, 권한 부여 또는 인간 신원을 확립하지는 못했습니다.

인터넷은 의미를 주장하기 전에 비교가 필요했습니다

유니코드는 프로토콜이 US-ASCII보다 훨씬 많은 것을 담을 수 있게 했지만, 동시에 단순 비교를 신뢰하기 어렵게 만들었습니다. 사용자가 인식하는 동일한 텍스트가 서로 다른 코드 포인트 열, 호환 문자, 대소문자 변형 또는 보이지 않는 기호를 통해 전달될 수 있었습니다. 2002년 12월에 발표된RFC 3454는 프로토콜이 문자열을 저장하거나 비교하기 전에 준비하기 위한 프레임워크인 stringprep을 정의했습니다.

그 목표는 실용적이었습니다. 같은 문자열이라고 믿고 입력한 두 사람이 문자 단위로 일치하는 출력을 만들 가능성을 높이는 것이었습니다. 표현 방식이 중요했습니다. Stringprep은 명시된 규칙 아래에서 가능성을 높였을 뿐, 언어적 진실을 정의하지는 않았습니다. 언어와 문자 체계를 통틀어 모든 대체 철자를 다룰 수 없음을 명시적으로 밝혔습니다.

일반 텍스트,RFC 편집기 기록,Datatracker 문서,이력,참고 문헌,이후 인용및정오표 검색은 표준 기록을 확립합니다. 그러나 이들은 특정 사용자가 무엇을 입력하려 했는지, 또는 그 결과 생긴 식별자를 어떤 계정이 통제했는지는 보여주지 않습니다.

프로파일이 선택을 하기 전까지 프레임워크는 아무것도 하지 않았습니다

Stringprep은 독립적인 준비 정책이 아니었습니다. 프로토콜은 적용 범위, 허용되는 레퍼토리, 매핑 테이블, 정규화 선택, 금지 출력, 양방향 검사 및 추가 사항을 명시하는 프로파일을 정의해야 했습니다. 서로 다른 프로파일을 쓰는 두 프로토콜은 동일한 입력을 각자 합법적으로 다르게 처리할 수 있었습니다.

이 설계는 지역 프로토콜의 필요를 보존하면서 은밀한 임의 변형을 막았습니다. 프로파일은 일부 문자를 아무것도 없는 것으로 매핑하거나, 한 문자를 다른 문자로 대체하거나, 한 문자를 여러 문자로 확장할 수 있었습니다. 매핑된 출력은 같은 매핑 단계에서 다시 스캔되지 않으므로, 변환 경로 자체가 계약의 일부였습니다.

프로파일이 유니코드 정규화를 선택했다면, RFC 3454는 정규화 형식 KC를 요구했습니다. 기반이 되는 정규화 규율은유니코드 표준 부록 #15에 문서화되어 있습니다. 호환성 정규화는 더 많은 형식을 수렴시켰지만, 수렴이 모든 폰트에서 동일하게 보이거나 모든 언어에서 같은 단어를 의미한다는 주장은 아니었습니다.

순서 자체가 규칙의 실행 가능한 부분이었습니다

네 가지 연산은 순서대로 실행되어야 했습니다. 매핑, 정규화, 금지, 그리고 양방향 제약 검사. 순서를 바꾸면 결과가 달라질 수 있었습니다. 매핑 단계에서 제거된 문자는 나중에 거부될 수 없었고, 정규화는 금지 단계가 검사해야 하는 열을 만들어낼 수 있었습니다.

금지 단계는 준비된 문자열 또는 오류 중 하나만 반환하며 둘 다 반환하지 않았습니다. 제어 문자, 사적 사용 코드 포인트, 비문자(noncharacter), 서러게이트, 태깅 문자 및 기타 클래스는 프로파일이 제외할 수 있었습니다. 양방향(bidi) 규칙은 오른쪽에서 왼쪽 문자를 포함하는 문자열을 제약하여, 문자열의 가장자리와 방향성 클래스가 불안정한 프로토콜 식별자를 만들지 않도록 했습니다. 이 검사들은 구문과 표시 위험을 통제했습니다. 입력한 사람을 인증하지는 않았습니다.

유니코드 기술 보고서 #36과 같은 보안 지침은 이후 시각적 혼동 위험을 더 명시적으로 다루었습니다. 완벽한 정규화조차 모든 유사 문자를 동등하게 만들 수 없으며, 두 코드 포인트 열을 동등하게 만드는 것은 한 사람이 두 이름을 모두 소유함을 증명하지 못합니다.

버전 번호는 근거 안에 자리했습니다

RFC 3454는 자신의 테이블을 유니코드 3.2에 고정하고, 이 문서가 이후 유니코드 버전에 자동으로 적용되지 않는다고 경고했습니다. 이 고정은 구현을 재현 가능하게 만들었지만, 동시에 “문자열이 유효했다”는 판정은 프로파일과 테이블 버전 없이는 불완전하다는 뜻이기도 했습니다.

미할당 코드 포인트는 호환성 문제를 드러냈습니다. 저장된 문자열에는 이들을 포함할 수 없었습니다. 이후 유니코드 버전이 처리를 바꾸는 속성을 부여할 수 있기 때문입니다. 조회는 이들을 더 관대하게 다룰 수 있어, 새 클라이언트가 오래된 저장소를 검색할 수 있었습니다. 따라서 동일한 입력이 생성 시에는 거부되고 조회 시에는 허용될 수 있었습니다. 연산 유형이 결과의 일부였습니다.

이 비대칭성은 상호 운용성을 보호했지만, 단일하고 시대를 초월한 참·거짓 값을 배제했습니다. 최종 출력만 남기는 로그는 입력이 저장 식별자였는지 조회였는지, 어떤 테이블이 쓰였는지, 어떤 변환이 일어났는지 잃게 됩니다.

Nameprep은 유용성과 범위를 함께 보여주었습니다

RFC 3491은 Nameprep을 원조 IDNA 체계의 stringprep 프로파일로 만들었고,RFC 3490은 이를 도메인 이름 워크플로에 배치했습니다. 이후RFC 4690검토는 어려움을 기록했고,RFC 5890의 IDNA2008 어휘는 stringprep에서 벗어났습니다.

이 전환이 비교가 불필요하다는 판정은 아니었습니다. 고정된 유니코드 버전과 상속된 프로파일 선택에 묶인 프레임워크는 진화가 어려웠음을 보여준 것입니다.RFC 6885는 PRECIS 문제를 기술했고,RFC 7564는 RFC 3454를 폐기(obsolete)했으며,RFC 8264는 이후 그 최초의 PRECIS 프레임워크를 대체했습니다. 표준의 연속 교체는 계속된 수리의 증거이며, 모든 오래된 저장 식별자가 한꺼번에 의미가 바뀌었다는 뜻은 아닙니다.

동등함에는 그 범위가 명시된 영수증이 필요했습니다

Lu Heng의현실 계층 규율은 기록의 경계를 정확하게 만듭니다. 원본 입력, 선택된 프로파일, 유니코드 테이블, 매핑 결과, 정규화 결과, 금지 또는 양방향 판정, 최종 비교, 계정 결합, 권한 부여는 서로 다른 영수증입니다. 단일 불리언 “일치”는 이를 대체할 수 없습니다.

운영 코드 우선주의는 주장이 실제 실행된 연산을 따르도록 요구합니다. 코드는 두 출력이 일치했음을 보여줄 수 있지만, 그 소유자를 임명할 수는 없습니다.최소 초기 사양관점은 왜 범용 프레임워크가 신원과 권한 부여를 사용 프로토콜에 맡겼는지 설명합니다. 이는 후대의 편집적 해석이며, 저자들의 사적 의도에 대한 진술이 아닙니다.

RFC 3454의 지속되는 교훈은 정규화가 약하다는 것이 아닙니다. 정규화는 명명된 경계 안에서만 강하다는 것입니다. 비교를 결정론적으로 만들 수는 있지만, 비교를 신원으로 바꿀 수는 없습니다.

출처