요약

  • UIDPLUS는 성공한 APPEND와 COPY 결과에 목적지 UIDVALIDITY와 새로 할당된 UID를 붙여, 완료된 변경 작업을 연결이 끊긴 클라이언트가 즉시 사용할 수 있는 대응 관계로 바꾸었다.
  • 이 영수증은 의도적으로 로컬에 머물렀다. 권한이나 비영속 저장소는 이를 생략할 수 있었고, COPYUID는 전역 메시지 식별성을 확립하지 않았으며, UID EXPUNGE는 명시된 UID 집합과 이미\Deleted표시된 메시지의 교집합만 제거했다.

참조 없는 성공

IMAP은 두 가지 번호 체계를 구분했다. 순서 번호는 선택된 메일함의 현재 뷰를 기술하며, 다른 메시지가 지워지면 바뀔 수 있었다. UID는 메일함 세대 내에서 안정적으로 유지되도록 설계되었다. 이 구분 덕분에 연결이 끊긴 클라이언트는 상태를 캐시하고 나중에 돌아올 때, 세 번째 메시지가 여전히 세 번째라는 이유만으로 같은 메시지라고 여기지 않을 수 있었다.

그러나 상태를 바꾸는 명령에는 빈틈이 있었다. APPEND는 서버에 목적지 메일함에 새 메시지를 만들어 달라고 요청했고, COPY는 기존 메시지의 목적지 사본을 만들어 달라고 요청했다. 기본 IMAP은 성공을 확인할 수 있었지만, 클라이언트는 여전히 서버가 어떤 목적지 UID를 할당했는지 찾아야 했다. 메일함을 선택하고, 삽입해 둔 마커를 검색하고, 후보를 가져와 비교하는 식이었다. 이 추가 작업은 변경이 실패했다는 증거가 아니었다. 그것은 자신의 산물을 이름 붙이지 않는 성공 결과의 비용이었다.

RFC 2359는 1998년 정확히 이러한 연결 단절 환경을 위해 UIDPLUS를 도입했다. RFC 4315가 2005년에 그 문서를 대체하며 규칙을 다듬고 서버가 결과를 정당하게 생략할 수 있는 경우를 기술했다. 이 확장은 두 번째 트랜잭션 체계를 만들지 않았다. 기존의 태그가 붙은 성공 경계 안에 더 많은 증거를 담았을 뿐이다.

APPENDUID가 하나의 열린 고리를 닫았다

APPEND가 성공하면 APPENDUID가 태그가 붙은OK안에 나타날 수 있었다. 여기에는 두 가지가 담겼다. 목적지 메일함의 UIDVALIDITY와 새 메시지에 할당된 UID다. 클라이언트는 단순히 업로드가 수락되었다는 사실만이 아니라, 나중에 그 결과를 참조할 수 있는 메일함 세대와 로컬 식별자까지 기록할 수 있게 되었다.

세대는 숫자만큼이나 중요했다. UID 3955는 그 자체로는 식별자가 아니다. 관련된 서버, 메일함 이름, UIDVALIDITY 안에서만 의미를 갖는다. 유효성이 바뀌면 옛 짝은 아무 일 없었다는 듯 계속 사용될 수 없다. UIDPLUS가 사용 가능한 참조를 돌려준 이유는 그 참조를 유효하게 만드는 경계까지 돌려주었기 때문이다.

Multiappend는 응답을 단일 UID에서 순서가 있는 집합으로 넓혔다. 반환되는 UID의 순서는 APPEND에 전달된 메시지의 순서를 따른다. 이 집합은 무관한 식별자를 몰래 끼워 넣을 수 없고,*를 무한한 끝점으로 사용할 수도 없다. 이런 제약 덕분에 응답을 검증할 수 있다. 클라이언트는 자신이 보낸 메시지 수와 각 메시지에 해당하는 결과 위치를 알기 때문이다.

COPYUID는 이름이 바뀌어도 대응 관계를 지켰다

COPY는 더 어려운 문제를 제기했다. 같은 내용이 메일함 경계를 넘어 새 이름을 받았기 때문이다. COPYUID는 목적지 UIDVALIDITY, 원본 UID 집합, 목적지 UID 집합을 반환했다. 두 집합의 크기는 같고, 위치가 대응을 정의한다. 첫 원본은 첫 목적지와, 두 번째는 두 번째와 대응되는 식이다.

이는 UID가 메시지와 함께 이동한다는 약속이 아니었다. 특정 명령이 이러한 목적지 할당을 일으켰다는 증거였다. 클라이언트는 메시지 순서나 내용 유사성을 추측하지 않고도 로컬 모델을 갱신할 수 있었다.

메시지 순서 번호는 같은 역할을 안전하게 수행할 수 없었다. COPY가 처리되는 동안 다른 클라이언트가 메시지를 지워 표시 위치가 밀릴 수 있었다. 따라서 RFC 4315는 이 대응 관계를 UID에 근거를 두고 반환된 집합을 관련된 메시지로 한정했다. 영수증은 표시 순서에 의존하지 않기 때문에 번호가 다시 매겨져도 살아남는다.

그러나 그 적용 범위는 여전히 응답을 받은 클라이언트에서 멈췄다. RFC 8474는 나중에 다른 클라이언트가 목적지 메일함을 들여다보고 COPYUID로부터 같은 메일함 간 대응 관계를 유추할 수 없다고 지적했다. 객체 식별자는 더 넓은 식별성 문제를 다루었다. UIDPLUS가 해결한 것은 명령 결과 문제였지, 보편적인 동일성 문제가 아니었다.

UID EXPUNGE는 파괴 대상을 좁혔다

이 확장의 명령은 삭제에도 같은 정밀함을 적용했다. 일반 EXPUNGE는 선택된 메일함에서\Deleted표시가 붙은 모든 메시지를 영구 제거했다. 공유 메일함에서는 다른 클라이언트가 재접속하는 클라이언트가 전혀 제거하려 하지 않았던 메시지에 그 표시를 붙였을 수도 있다.

UID EXPUNGE는 UID 집합을 받아 두 조건을 모두 만족하는 메시지만 제거한다. UID가 그 집합에 속하고, 이미\Deleted표시되어 있어야 한다. 집합에 있지만 표시가 없는 UID는 살아남고, 표시되었지만 집합 밖인 메시지도 살아남는다. 이 명령은 교집합이지, 넓은 청소도 표시 단계의 대체도 아니다.

UIDPLUS가 없을 때 문서화된 대안은 번거로웠다. 살아야 할 메시지에서 임시로\Deleted를 지우고, EXPUNGE를 실행한 뒤, 표시를 복원하는 것이다. 이 대안은 적절한 조건에서 원하는 결과를 재현할 수 있었지만, 공유 상태를 조작할 수 있는 창을 넓혔다. UID EXPUNGE는 의도된 되돌릴 수 없는 범위를 한 명령에 명시적으로 만들었다.

영수증은 너무 많은 것을 드러낼 수 있었다

더 많은 증거가 항상 더 안전한 것은 아니었다. 사용자가 메일함을 선택하거나 살펴볼 권한 없이 메시지를 그 메일함에 넣을 수만 있을 수도 있다. 그 메일함의 UIDVALIDITY와 새로 할당된 UID를 반환하면, 권한 모델이 원래 불투명하게 유지하던 저장소 정보가 드러난다. 그래서 RFC 4315는 그런 경우 서버가 APPENDUID나 COPYUID를 보내지 말아야 한다고 규정했다.

UIDNOTSTICKY 목적지의 경우에도 응답은 생략될 수 있다. 이런 저장소는 세션 사이에 UID가 유지된다고 약속하지 않는다. 비영속 네임스페이스에서 내구성이 있어 보이는 참조를 반환하면 잘못된 추론을 부르게 되므로, 프로토콜은 그 저장소를 표시하고 침묵을 허용한다. 명세는 그런 속성을 가진 새 저장소를 만드는 것을 권하지 않지만, 레거시 제약이 존재하지 않는 것처럼 행동하지도 않는다.

영수증의 부재는 부정적인 명령 결과가 아니다. 클라이언트는 필요한 접근 권한이 있다면 메시지 안에 넣어 둔 고유한 마커를 활용해 목적지를 선택하고 검색하는 방식으로 되돌아갈 수 있다. 이 구분이 핵심이다. 변경 성공, 살펴볼 권한, 식별자의 영속성은 서로 다른 세 가지 사실이다.

MOVE는 응답 순서를 보이게 만들었다

이후의 MOVE 확장은 목적지 생성과 원본 제거를 결합했다. UIDPLUS 서버는 UID MOVE에 대해 COPYUID를 보고할 수 있었지만, 이제 타이밍이 중요해졌다. 서버가 EXPUNGE 응답을 먼저 보내면, 클라이언트가 목적지 대응 관계를 알기 전에 원본 쪽 순서 번호가 밀려난다. RFC 6851은 그런 제거보다 먼저 태그 없는OK로 COPYUID를 보내도록 권고했고, IMAP4rev2는 그 순서를 통합된 동작의 일부로 만들었다.

교훈은 응답이 일찍 도착한다고 더 참이 된다는 것이 아니다. 그것을 해석하는 데 필요한 상태가 아직 응집되어 있을 때 쓸 수 있게 된다는 것이다. 대응 관계, 삭제 통지, 최종 성공은 각각 개별적으로는 모두 정확하면서도, 프로토콜이 순서를 잘못 정하면 불필요한 모호함을 만들 수 있다.

영수증에는 관할이 있었다

UIDPLUS는 경계가 있는 증거의 역사다. APPENDUID는 한 번의 append에 따라 어떤 새 로컬 참조가 생겼는지 답했고, COPYUID는 하나의 원본 집합이 하나의 목적지 집합에 어떻게 대응하는지 답했으며, UID EXPUNGE는 한 클라이언트가 어떤 표시된 메시지를 제거하려 하는지 답했다. 권한, 메일함 세대, 응답 순서가 각 답이 유효한 범위를 정했다.

이 절제 때문에 확장이 오래 살아남았다. UIDPLUS는 로컬 숫자를 보편적 식별자로, 성공적인 응답을 트랜잭션 증명으로 승격시키지 않았다. 더 작은 주장을 정확히 필요한 만큼만 했다. 서버가 이 변경을 수행했으며, 이 메일함 세대 안에서 만들어진 목적지 참조가 이것이라는 주장이다.

출처와 한계

원래 확장은RFC 2359이며,RFC 4315가 이를 대체했다. 기본 프로토콜 맥락은RFC 3501에 있고, MOVE 상호작용은RFC 6851에, 다른 클라이언트 간 객체 식별자가 필요했던 한계는RFC 8474가 설명하며, 통합된 IMAP4rev2 동작은RFC 9051에 있다. IANA의IMAP capabilities 레지스트리는 UIDPLUS를 기록하고 있다. 이 출처들은 배포 젦유율을 측정하지 않으며, UID 대응 관계를 전달, 인증 또는 전역 식별성의 증거로 바꾸지 않는다.