요약

  • 10월 28일 JMAP Object Metadata 초안 05판은 @type과 올바르게 패딩된 base64만 담은 Binary 값을 새로 규정한다. 서버는 정상 값을 입력된 형태 그대로 저장하고 반환하며, 잘못된 형식은 거절한다.
  • 이 값은 깊이 0으로 계산되지만 패치나 질의 경로가 내부 구성요소를 따라갈 수 없고 텍스트 필터도 일치하지 않는다. 04판에는 이 규정이 없었다.

있는지는 보인다. 지문 안쪽은 찾을 수 없다.

초안의 예시는 업체가 소유한 이름공간에 32바이트 지문을 넣는다. 필드의 존재 여부는 질의할 수 있다. 하지만 지문 속 바이트열로 객체를 찾는 텍스트 필터는 작동하지 않는다. base64만 고치는 패치도 거절된다. JSON 모양은 작은 객체지만 프로토콜은 봉인된 한 값으로 다룬다.

이 설계는 형식의 빈틈을 메운다. JSON 문자열은 유니코드 텍스트를 담고, 실제 애플리케이션은 임의의 바이트를 보관해야 할 때가 있다. 새 절은 구성요소를 둘로 한정하고 패딩된 base64를 요구한다. 형식이 어긋나면 invalidProperties, 봉인 안을 관통하려는 패치에는 invalidPatch가 돌아온다. 서버가 맡는 것은 정확한 보관이다. 바이트가 무엇을 뜻하는지는 이름공간의 주인이 결정한다.

업체는 자신이 통제하는 소문자 도메인을 이름공간으로 쓸 수 있다. 그 이름을 IANA에 미리 등록할 필요는 없다. 서버는 해당 객체 유형에서 업체 이름공간을 허용할지 결정한다. 공유 메타데이터의 열람은 원래 객체의 읽기 권한을 따르고, 개인 메타데이터는 인증된 사용자에게 속한다. 이런 권한 구조는 이전 판에도 있었다. 이번에 추가된 것은 그 안의 밀봉된 바이트 형식이다.

깊이 0은 용량 0이 아니다. 깊이 제한은 중첩을 재고, 쿼터와 크기 제한은 저장 공간을 다룬다. 초안은 메타데이터 쿼터 적용을 권장하고 구현별 크기 제한을 허용한다. 넘치면 overQuota다. 일반 문자열 검색도 서버가 비용 때문에 unsupportedFilter로 거절할 수 있다. ‘검색 가능한 메타데이터’라는 구매 문구에는 실제 필터, 필드 유형, 용량 계산법을 붙여 물어야 한다.

IETF 상태 기록에는 아직 작업반 Internet-Draft로 올라와 있다. 구체적인 서버가 값을 쓰고 같은 바이트를 돌려주며 내부 검색과 패치가 어떻게 실패하는지, 용량을 얼마나 차감하는지 보여주는 실행 기록이 필요하다. 봉인 규칙은 정해졌고 실제 서랍은 검증을 기다린다.

출처: 05판; 04판; IETF 상태.