요약

  • RFC 8620은 계정에서 한 유형의 모든 데이터에 대해 JMAP 클라이언트에 state 문자열을 제공합니다. 값의 차이는 클라이언트에게 캐시를 버리거나 정확한 변경 사항을 요청하도록 알려줍니다.
  • StateChange 푸시는 어떤 계정/데이터 유형의 state가 변경되었는지 클라이언트에 알려줍니다. 이는 그 자체로 행위자, 객체 수준의 이전/이후 값, 원인, 이벤트 순서, 보존 보장, 메일함 결과를 독립적으로 보존하지 않습니다.

추가 요청을 묻는 알림

Neil Jenkins와 Chris Newman의 RFC 8620은 실용적인 동기화 문제를 해결합니다. 모바일 또는 웹 클라이언트는 자신의 캐시 사본이 낡았는지 확인하기 위해 대형 서버에서 모든 레코드를 계속 내려받을 수 없습니다. 그래서 프로토콜은 계정 내 데이터 유형에 짧은state문자열을 붙입니다. 서버의 데이터가 변경되면 이 문자열도 반드시 변경되어야 하고, 변경되지 않았다면 서버는 보통 같은 문자열을 반환해야 합니다.

이것은 유용한 경계입니다. 이 state는 하나의Foo/get응답에 반환된 객체들이 아니라 계정에서 해당 유형의 모든 데이터에 속합니다. 다른 값을 본 클라이언트가 그 차이의 내용을 추측할 수 있는 권한을 얻는 것은 아닙니다. RFC 8620은 클라이언트에게 해당 유형의 캐시된 객체를 버리거나,Foo/changes를 호출하여 정확한 변경 사항을 검색하라고 지시합니다.

이 프로토콜은 의도적으로 절약적입니다. 작은 토큰 하나로 모든 응답에 대량의 데이터를 실어 보내지 않고도 동기화 작업이 필요한지 판단할 수 있습니다. 그렇다고 이 토큰이 발생한 작업에 대한 설명이 되는 것은 아닙니다. 변경된 값은 이전의 캐시된 표현이 더 이상 최신이 아니라는 말일 뿐입니다. 저자, 동기, 승인, 명령 경로, 메시지 식별자, 필드 차이, 또는 사람·수신자 경계에서의 결과를 알려주지 않습니다.

state는 캐시 경계이지 감사 경계가 아니다

state 문자열을/changes메서드와 나란히 놓으면 구분이 더 명확해집니다. 클라이언트는 이전에 받은 state인sinceState를 제공합니다. 서버는oldState와newState를 반환하고, 생성·갱신·삭제된 식별자들을 열거할 수 있습니다. 이 교환은 캐시를 일치시키기 위해 설계된 것입니다.

이렇게 더 자세한 교환이라 해도 그 자체가 완전한 감사는 아닙니다. 식별자 목록은 누가 갱신을 일으켰는지, 어떤 권한 부여된 요청이 수용되었는지, 어떤 값이 바뀌었는지, 어떤 규칙이 왜 적용되었는지, 동시에 발생한 이벤트가 컴플라이언스 목적상 어떤 순서로 정렬되었는지, 그리고 그 레코드가 얼마나 오래 온전히 남을지에 대한 진술이 아닙니다. 이들은 감사 시스템의 별개 속성입니다. 서비스는 이를 보존하고, 신원 시스템에 결합하고, 변조로부터 보호하며 검토 가능하게 만들 수 있습니다. RFC 8620의 동기화 계약은 그 자체로 그렇게 했다고 주장하지 않습니다.

메일함의 경우 이 유혹이 특히 강합니다. 운영자가 다른Email또는Mailboxstate를 보고 “메일함이 변경되었다”고 쓰는 것입니다. 절제된 버전은 참일 수 있습니다. 서버가 해당 데이터 유형에 대해 다른 state를 보고한다는 것입니다. 더 큰 주장은 관련 계정, 객체, 이전·이후 값, 조치 출처, 권한 부여 맥락, 시간 의미론, 관측 지점을 이름으로 지정하는 증거 사슬이 필요합니다. 그 사슬이 없다면 state 전이는 정보 그 자체가 아니라 정보를 검색하라는 신호입니다.

하나의 푸시에는 여러 변경이 결합될 수 있다

RFC 8620의StateChange객체는 푸시에 대해서도 같은 설계를 명시적으로 만듭니다. 이 객체는 계정 식별자를 이전 푸시 이후 변경된 데이터 유형 state에 매핑합니다. 클라이언트는 자신의 값과 비교하여 더 이상 최신이 아니라면 변경 사항을 가져옵니다. RFC의 예시는 서버가 단일 StateChange 객체를 보내기 전에 두 계정에 걸친 여러 변경을 하나로 합칠 수 있음을 보여줍니다.

동기화 클라이언트에게 필요한 것은 정확히 이것입니다. 폴링을 피하고, 모든 원격 변경을 별도의 전체 재로딩으로 취급하지 않도록 합니다. 동시에 이 알림을 과대해석하지 말라는 명확한 경고도 제공합니다. 하나의 StateChange는 서버 측 변경이 여러 건 누적되었다는 압축된 표시일 수 있습니다. 반드시 하나의 이벤트, 하나의 요청, 한 명의 사용자, 하나의 메시지, 하나의 메일함 조치, 또는 하나의 순서화된 이벤트 원장이라는 뜻은 아닙니다.

이것은 JMAP의 결함이 아닙니다. 수신자의 임무가 캐시를 일치시키는 것이라면 압축은 기능입니다. 오류는 모니터링 대시보드가 압축된 신호에 감사 라벨을 붙일 때 시작됩니다. 초록색 배달 표시, 변경된 카운터, 새로운 state 값은 유용한 운영 텔레메트리일 수 있습니다. 그러나 그 어떤 것도 관측된 필드가 담고 있지 않은 사실을 조용히 획득해서는 안 됩니다.

심각한 메일함 주장을 위한 증거 스택

서로 다른 질문에는 서로 다른 소유자의 기록이 필요합니다. 클라이언트 동기화 질문은 state 값과 필요시/changes응답으로 답할 수 있습니다. 객체에 대한 질문에는 관련 객체 식별자와 이전/이후 표현이 필요할 수 있습니다. 권한 있는 수정에 대한 질문에는 인증된 주체, 권한 부여 결정, 요청 상관관계, 서버 결정, 내구성 있는 시간/순서 기록이 필요할 수 있습니다. 하위 전달이나 읽는 이의 경험에 대한 질문에는 그 이후 경계에서의 증거가 필요합니다.

질문유용한 JMAP 증거추가로 필요한 증거
이 캐시는 최신인가?일치하는state문자열좁은 캐시 질문에는 불필요
클라이언트가 일치시켜야 할 레코드는 무엇인가?/changes식별자와 반환된 state차이가 중요하다면 객체 내용
메일함 수정은 누가 했는가?StateChange만으로는 확인 불가인증된 주체, 요청 및 권한 부여 기록
어떤 값이, 어떤 순서로 바뀌었는가?state 문자열만으로는 완전히 확인 불가이전/이후 값, 이벤트 시간/순서, 내구성 감사 통제
수신자나 사용자가 어떤 결과를 경험했는가?일반 동기화 state로는 확인 불가전달, 메일함, 수신자 또는 사용자 경계에서의 관측

이 표는 RFC 8620에 새로운 요구를 부과하지 않습니다. 주장을 그것을 뒷받침할 수 있는 시스템에 계속 붙어 있게 할 뿐입니다. 이것이 running-code 규율입니다. 프로토콜 신호는 그가 수행하는 일에 대해서만 인정받아야 하고, 결과를 수반하는 주장은 실제로 그것을 관측하는 운영 증거에 계속 묶여 있어야 합니다.

Neil Jenkins의 경계가 있는 기여

공개 RFC 기록은 Neil Jenkins와 Chris Newman을 RFC 8620의 저자로 기재합니다. 이 사양은 집합적 IETF Standards Track 문서이며, 두 사람 중 누구가 특정 메일 서비스를 운영하거나 특정 고객 결과를 소유한다는 주장이 아닙니다. 여기서 관련 있는 기여는 아키텍처적입니다. 클라이언트는 캐시된 계정 데이터가 변경되었음을 저렴하게 감지하고, 표준 메서드를 사용해 자신의 뷰를 일치시킬 수 있습니다.

이 아키텍처가 가치 있는 이유는 자신 이상을 가장하지 않기 때문입니다. 캐시 토큰은 조사를 촉발하면서도 조사를 제한하지 않습니다. StateChange는 클라이언트를 깨우면서도 메일함 이야기를 결정하지 않습니다. 좋은 운영은 이 절제를 지킵니다. 동기화 증거는 동기화를 위해 보존하고, 감사 증거는 감사를 위해 보존합니다.

출처