1.1. 목표

CBOR의 목표는 중요도가 대체로 높은 것부터 낮은 것까지 다음과 같다.¶

1. 표현은 인터넷 표준에서 사용되는 대부분의 일반적인 데이터 형식을 모호하지 않게 인코딩할 수 있어야 한다.¶

   • 이진 인코딩을 사용하여 합리적인 기본 데이터 타입과 구조 집합을 표현해야 한다. 여기서 "합리적"이라는 것은 주로 JSON의 능력에 영향을 받으며, 주요 추가 사항은 이진 바이트 문자열이다. 지원되는 구조는 배열과 트리로 제한되며, 루프와 격자형 그래프는 지원되지 않는다.¶
   • 모든 데이터 형식이 고유하게 인코딩되어야 한다는 요구 사항은 없다. 즉, 숫자 "7"이 여러 다른 방식으로 인코딩될 수 있어도 허용된다.¶

2. 인코더 또는 디코더의 코드는 매우 제한적인 메모리, 프로세서 성능, 명령어 집합을 가진 시스템을 지원하기 위해 간결할 수 있어야 한다.¶

   • 인코더와 디코더는 매우 적은 양의 코드로 구현 가능해야 한다 (예: [RFC7228]에 정의된 클래스 1 제약 노드에서).¶
   • 이 형식은 데이터의 현대적인 기계 표현을 사용해야 한다 (예: 이진-십진 변환을 요구하지 않아야 함).¶

3. 데이터는 스키마 설명 없이 디코딩될 수 있어야 한다.¶

   • JSON과 유사하게, 인코딩된 데이터는 일반 디코더를 작성할 수 있도록 자기 설명적이어야 한다.¶

4. 직렬화는 합리적으로 간결해야 하지만, 데이터 간결성은 인코더와 디코더의 코드 간결성에 비해 부차적이다.¶

   • 여기서 "합리적"이라는 것은 크기 면에서 JSON을 상한으로 하고, 구현 복잡성에 의해 제한된다. 이 복잡성은 그 간결성을 달성하기 위해 투입할 수 있는 노력의 양을 제한한다. 일반 압축 기법이나 과도한 비트 조작을 사용하는 것은 복잡성 목표에 위배된다.¶

5. 이 형식은 제약 노드와 대용량 애플리케이션 모두에 적용 가능해야 한다.¶

   • 이는 인코딩과 디코딩 모두에서 CPU 사용이 합리적으로 절약되어야 함을 의미한다. 이는 제약 노드와 매우 많은 양의 데이터를 사용하는 애플리케이션에서의 잠재적 사용 모두에 관련된다.¶

6. 이 형식은 JSON과의 상호 변환을 위해 모든 JSON 데이터 타입을 지원해야 한다.¶

   • 표현된 데이터가 JSON의 능력 범위 내에 있는 한, 합리적인 수준의 변환을 지원해야 한다. 모든 타입의 데이터에 대해 JSON으로 향하는 단방향 매핑을 정의할 수 있어야 한다.¶

7. 이 형식은 확장 가능해야 하며, 확장된 데이터는 이전 디코더가 디코딩할 수 있어야 한다.¶

   • 이 형식은 수십 년 동안 사용되도록 설계되었다.¶
   • 이 형식은 확장을 이해하지 못하는 디코더도 메시지를 디코딩할 수 있도록 폴백을 허용하는 확장성 형태를 지원해야 한다.¶
   • 이 형식은 나중의 IETF 표준에 의해 미래에 확장될 수 있어야 한다.¶

1.2. 용어

이 문서에서 사용되는 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"은 여기에 표시된 것처럼 모두 대문자로 나타날 때에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석되어야 한다.¶

"byte"라는 용어는 이제 관례적인 의미로 "octet"의 동의어로 사용된다. 모든 다중 바이트 값은 네트워크 바이트 순서 (즉, 최상위 바이트가 먼저 오는 방식, "빅 엔디언"이라고도 함)로 인코딩된다.¶

이 명세는 다음 용어를 사용한다.¶

데이터 항목:

단일 CBOR 데이터 조각. 데이터 항목의 구조는 0개, 1개 또는 그 이상의 중첩 데이터 항목을 포함할 수 있다. 이 용어는 표현 형식의 데이터 항목과 디코더가 그것으로부터 도출할 수 있는 추상적 개념 모두에 사용된다. 전자는 "인코딩된 데이터 항목"이라는 용어를 사용하여 구체적으로 지칭할 수 있다.¶

디코더:

올바른 형식의 인코딩된 CBOR 데이터 항목을 디코딩하여 애플리케이션에서 사용할 수 있게 하는 프로세스. 형식적으로 말하면, 디코더는 CBOR의 구문 규칙을 사용하여 입력을 분해하는 파서와, 애플리케이션에 적합한 형태로 데이터를 준비하는 의미 처리기를 포함한다.¶

인코더:

애플리케이션 정보로부터 CBOR 데이터 항목의 (올바른 형식의) 표현 형식을 생성하는 프로세스.¶

데이터 스트림:

더 큰 포함 데이터 항목으로 추가 조립되지 않은 0개 이상의 데이터 항목 시퀀스(한 가지 적용 사례는 [RFC8742] 참조). 데이터 스트림을 구성하는 독립적인 데이터 항목은 때때로 "최상위 데이터 항목"이라고도 한다.¶

올바른 형식:

CBOR의 구문 구조를 따르는 데이터 항목. 올바른 형식의 데이터 항목은 CBOR에 정의된 대로 그 값에 의해 암시되는 초기 바이트와 바이트 문자열 및/또는 데이터 항목을 사용하며, 뒤따르는 불필요한 데이터를 포함하지 않는다. CBOR 디코더는 정의상 올바른 형식의 데이터 항목에서만 내용을 반환한다.¶

유효함:

올바른 형식이며 CBOR 데이터 항목에 적용되는 의미적 제한도 따르는 데이터 항목(섹션 5.3).¶

예상됨:

일반 영어 의미 외에도, "expected"라는 용어는 애플리케이션이 입력 데이터에 대해 갖는 CBOR 유효성 이상의 요구 사항을 설명하는 데 사용된다. 올바른 형식(전혀 처리 가능), 유효함(유효성 검사 일반 디코더가 검사), 예상됨(애플리케이션이 검사)은 수용 가능성 계층의 위계를 이룬다.¶

스트림 디코더:

데이터 스트림을 디코딩하고 시퀀스의 각 데이터 항목을 수신되는 대로 애플리케이션에서 사용할 수 있게 하는 프로세스.¶

Infinity, NaN (숫자가 아님), 음의 0, 비정규수와 같은 부동소수점 값에 대한 용어와 개념은 [IEEE754]에 정의되어 있다.¶

비트 산술이나 데이터 타입이 설명되는 곳에서, 이 문서는 프로그래밍 언어 C [C]에서 익숙한 표기법을 사용한다. 다만 ".."는 주어진 양 끝을 모두 포함하는 범위를 나타내며, 위첨자 표기법은 거듭제곱을 나타낸다. 예를 들어, 2의 64제곱은 다음과 같이 표기한다: 2⁶⁴. 이 명세의 일반 텍스트 버전에서는 위첨자 표기법을 사용할 수 없으므로 대체 표기법으로 렌더링된다. 그 표기법은 이 RFC에 최적화되어 있지 않으며, 불행히도 C의 배타적 OR(부록에서만 사용되고, 부록은 거듭제곱을 사용하지 않음)와 모호하고 일반 텍스트 버전의 독자에게 주의를 요구한다.¶

예제와 의사 코드는 부호 있는 정수가 2의 보수 표현을 사용하고 부호 있는 정수의 오른쪽 시프트가 부호 확장을 수행한다고 가정한다. 이러한 가정은 현재 최종 초안으로 제공되는 2020년 버전 C++의 섹션 6.8.1 (basic.fundamental) 및 7.6.7 (expr.shift)에도 명시되어 있다 [Cplusplus20].¶

16진수에 대한 "0x" 표기와 유사하게, 이진 표기의 숫자는 "0b"가 앞에 붙는다. 밑줄은 오직 가독성을 위해 숫자에 추가될 수 있으므로, 0b00100001 (0x21)은 바이트의 비트에 대한 원하는 해석을 강조하기 위해 0b001_00001로 쓸 수 있다. 이 경우 세 비트와 다섯 비트로 나뉜다. 인코딩된 CBOR 데이터 항목은 때때로 "0x" 또는 "0b" 표기로 주어진다. 이 값들은 먼저 C에서와 같이 숫자로 해석된 다음, 표기에 표현된 모든 선행 0 바이트를 포함하여 네트워크 바이트 순서의 바이트 문자열로 해석된다.¶

단어는 강조를 위해 기울임꼴로 표시될 수 있다. 이 명세의 일반 텍스트 형식에서는 단어를 밑줄 문자로 둘러싸는 방식으로 이를 표시한다. 축어 텍스트(예: 프로그래밍 언어의 이름)는 monospace 글꼴로 표시될 수 있다. 일반 텍스트에서는 텍스트를 큰따옴표로 둘러싸는 방식으로 다소 모호하게 근사한다 (큰따옴표는 또한 일반적인 의미도 유지한다).¶

2.1. 확장된 일반 데이터 모델

이 기본 일반 데이터 모델은 이 문서에서 다음과 같은 여러 단순 값과 태그 번호의 등록을 통해 확장되었다.¶

• false, true, null, 및 undefined (20..23으로 식별되는 단순 값, 섹션 3.3)¶
• 위보다 더 큰 범위와 정밀도를 가진 정수 및 부동소수점 값 (태그 번호 2에서 5, 섹션 3.4)¶
• 시점 또는 RFC 3339에 정의된 날짜/시간 문자열과 같은 애플리케이션 데이터 타입 (태그 번호 1 및 0, 섹션 3.4)¶

확장된 일반 데이터 모델의 추가 요소는 CBOR를 위해 생성된 IANA 레지스트리를 통해 정의될 수 있다(그리고 이미 정의되어 왔다). 그러한 확장을 일반 인코더나 디코더가 알지 못하더라도, 그 확장을 사용하는 데이터 항목은 기본 일반 데이터 모델 내에서, 즉 일반 단순 값 또는 일반 태그로 표현하여 애플리케이션으로 또는 애플리케이션에서 전달될 수 있다.¶

다시 말해, 기본 일반 데이터 모델은 이 문서에 정의된 대로 안정적이며, 확장된 일반 데이터 모델은 새 단순 값 또는 태그 번호의 등록을 통해 확장되지만 결코 축소되지 않는다.¶

일반 인코더와 디코더가 false, true, 및 null (undefined는 의도적으로 제외됨)을 해당 프로그래밍 환경에 적합한 형태로 표현할 수 있으리라는 강한 기대가 있지만, 태그로 생성된 데이터 모델 확장의 구현은 실제로 선택 사항이며 구현 품질의 문제이다.¶

2.2. 특정 데이터 모델

CBOR 기반 프로토콜의 특정 데이터 모델은 일반적으로 확장된 일반 데이터 모델의 하위 집합을 취하고, 이 하위 집합 및 그 구성 요소 내의 데이터 항목에 애플리케이션 의미를 부여한다. 그러한 특정 데이터 모델을 문서화하고 데이터 항목의 타입을 명시할 때는, CBOR 표현의 측면("주요 타입 1", "주요 타입 4")을 참조하기보다는 일반 데이터 모델 이름("음의 정수", "배열")으로 타입을 식별하는 것이 바람직하다.¶

특정 데이터 모델은 또한 맵 키 및 인코더 자유도를 위해 (서로 다른 타입의 값을 포함하여) 값의 동등성을 지정할 수 있다. 예를 들어, 일반 데이터 모델에서는 유효한 맵이 0과 0.0을 모두 키로 가질 수 있으며, 인코더는 MUST NOT 0.0을 정수 (주요 타입 0, 섹션 3.1)로 인코딩해서는 안 된다. 그러나 특정 데이터 모델이 정수 값을 갖는 부동소수점 표현과 정수 표현이 동등하다고 선언한다면, 단일 맵에서 0과 0.0을 모두 맵 키로 사용하는 것은 서로 다른 주요 타입으로 인코딩되었더라도 중복으로 간주되어 유효하지 않게 된다. 또한 인코더는 인코딩 바이트를 절약하기 위해 정수 값을 갖는 부동소수점을 정수로, 또는 그 반대로 인코딩할 수 있다.¶

3.1. 주요 타입

다음은 주요 타입과 그 타입에 관련된 추가 정보 및 기타 바이트를 나열한다.¶

주요 타입 0:

0..2⁶⁴-1 범위의 부호 없는 정수(양 끝 포함). 인코딩된 항목의 값은 인수 자체이다. 예를 들어, 정수 10은 한 바이트 0b000_01010(주요 타입 0, 추가 정보 10)으로 나타낸다. 정수 500은 0b000_11001 (주요 타입 0, 추가 정보 25)에 이어 두 바이트 0x01f4가 오며, 이는 십진수 500이다.¶

주요 타입 1:

-2⁶⁴..-1 범위의 음의 정수(양 끝 포함). 항목의 값은 -1에서 인수를 뺀 값이다. 예를 들어, 정수 -500은 0b001_11001(주요 타입 1, 추가 정보 25)에 이어 두 바이트 0x01f3이 오며, 이는 십진수 499이다.¶

주요 타입 2:

바이트 문자열. 문자열의 바이트 수는 인수와 같다. 예를 들어 길이가 5인 바이트 문자열은 초기 바이트 0b010_00101 (주요 타입 2, 길이에 대한 추가 정보 5)을 가진 뒤, 5바이트의 이진 내용이 이어진다. 길이가 500인 바이트 문자열은 0b010_11001(주요 타입 2, 두 바이트 길이를 나타내는 추가 정보 25)의 3개 초기 바이트와 길이 500을 나타내는 두 바이트 0x01f4, 그리고 500바이트의 이진 내용이 이어진다.¶

주요 타입 3:

UTF-8 [RFC3629]로 인코딩된 텍스트 문자열 (섹션 2). 문자열의 바이트 수는 인수와 같다. 잘못된 UTF-8 시퀀스를 포함하는 문자열은 올바른 형식이지만 유효하지 않다(섹션 1.2). 이 타입은 사람이 읽을 수 있는 텍스트를 해석하거나 표시해야 하는 시스템을 위해 제공되며, 구조화되지 않은 바이트와 지정된 문자 집합(Unicode) 및 인코딩(UTF-8)을 가진 텍스트를 구분할 수 있게 한다. JSON과 같은 형식과 달리, 이 타입의 Unicode 문자는 결코 이스케이프되지 않는다. 따라서 줄바꿈 문자(U+000A)는 문자열에서 항상 바이트 0x0a로 표현되며, 결코 바이트 0x5c6e (문자 "\" 및 "n")나 0x5c7530303061(문자 "\", "u", "0", "0", "0", 및 "a")로 표현되지 않는다.¶

주요 타입 4:

데이터 항목의 배열. 다른 형식에서 배열은 리스트, 시퀀스 또는 튜플이라고도 한다("CBOR sequence"는 약간 다른 것이지만 [RFC8742] 참조). 인수는 배열 안의 데이터 항목 수이다. 배열의 항목들이 모두 같은 타입일 필요는 없다. 예를 들어, 임의 타입의 항목 10개를 포함하는 배열은 초기 바이트 0b100_01010(주요 타입 4, 길이에 대한 추가 정보 10)을 가진 뒤 10개의 나머지 항목이 이어진다.¶

주요 타입 5:

데이터 항목 쌍의 맵. 맵은 테이블, 딕셔너리, 해시 또는 (JSON의) 객체라고도 한다. 맵은 데이터 항목의 쌍으로 구성되며, 각 쌍은 바로 뒤에 값이 오는 키로 이루어진다. 인수는 맵의 데이터 항목 쌍 수이다. 예를 들어, 9쌍을 포함하는 맵은 초기 바이트 0b101_01001(주요 타입 5, 쌍 수에 대한 추가 정보 9)을 가진 뒤 18개의 나머지 항목이 이어진다. 첫 번째 항목은 첫 번째 키, 두 번째 항목은 첫 번째 값, 세 번째 항목은 두 번째 키이며, 이런 식으로 계속된다. 맵의 항목은 쌍으로 오기 때문에 전체 수는 항상 짝수이다. 홀수 개의 항목을 포함하는 맵(마지막 키 데이터 항목 뒤에 값 데이터가 없음)은 올바른 형식이 아니다. 중복 키를 가진 맵은 올바른 형식일 수 있지만 유효하지 않으며, 따라서 불확정 디코딩을 야기한다. 섹션 5.6도 참조한다.¶

주요 타입 6:

태그 번호가 인수인(0..2⁶⁴-1 범위의 정수) 태그가 지정된 데이터 항목("태그")이며, 헤드 뒤에 오는 단일 인코딩된 데이터 항목을 포함된 데이터 항목(태그 내용)으로 가진다. 섹션 3.4를 참조한다.¶

주요 타입 7:

부동소수점 수와 단순 값, 그리고 "break" 정지 코드. 섹션 3.3을 참조한다.¶

이 여덟 가지 주요 타입은 데이터 항목의 초기 바이트에 대해 가능한 256개 값 중 어떤 값이 사용되는지를 보여 주는 간단한 표(표 7)로 이어진다.¶

주요 타입 6과 7에서는 가능한 값 중 다수가 향후 명세를 위해 예약되어 있다. 이 값들에 대한 자세한 정보는 섹션 9를 참조한다.¶

표 1은 당분간 섹션 3.2를 무시하고 CBOR가 정의한 주요 타입을 요약한다. 이 표의 숫자 N은 인수를 나타낸다.¶

3.2. 일부 주요 타입에 대한 부정 길이

네 가지 CBOR 항목(배열, 맵, 바이트 문자열 및 텍스트 문자열)은 추가 정보 값 31을 사용하여 부정 길이로 인코딩될 수 있다. 이는 배열이나 맵 내부의 항목 수 또는 문자열의 총 길이를 알기 전에 항목의 인코딩을 시작해야 할 때 유용하다. (데이터 항목이 모두 알려지기 전에 전송을 시작할 수 있는 능력은 종종 그 데이터 항목 내의 "스트리밍"이라고 한다.)¶

부정 길이 배열과 맵은 부정 길이 문자열(바이트 문자열과 텍스트 문자열)과는 다르게 처리된다.¶

83        -- Array of length 3
   01     -- 1
   82     -- Array of length 2
      02  -- 2
      03  -- 3
   82     -- Array of length 2
      04  -- 4
      05  -- 5

0x9f018202039f0405ffff
9F        -- Start indefinite-length array
   01     -- 1
   82     -- Array of length 2
      02  -- 2
      03  -- 3
   9F     -- Start indefinite-length array
      04  -- 4
      05  -- 5
      FF  -- "break" (inner array)
   FF     -- "break" (outer array)

0x9f01820203820405ff
9F        -- Start indefinite-length array
   01     -- 1
   82     -- Array of length 2
      02  -- 2
      03  -- 3
   82     -- Array of length 2
      04  -- 4
      05  -- 5
   FF     -- "break"

0x83018202039f0405ff
83        -- Array of length 3
   01     -- 1
   82     -- Array of length 2
      02  -- 2
      03  -- 3
   9F     -- Start indefinite-length array
      04  -- 4
      05  -- 5
      FF  -- "break"

0x83019f0203ff820405
83        -- Array of length 3
   01     -- 1
   9F     -- Start indefinite-length array
      02  -- 2
      03  -- 3
      FF  -- "break"
   82     -- Array of length 2
      04  -- 4
      05  -- 5

0xbf6346756ef563416d7421ff
BF           -- Start indefinite-length map
   63        -- First key, UTF-8 string length 3
      46756e --   "Fun"
   F5        -- First value, true
   63        -- Second key, UTF-8 string length 3
      416d74 --   "Amt"
   21        -- Second value, -2
   FF        -- "break"

0b010_11111 0b010_00100 0xaabbccdd 0b010_00011 0xeeff99 0b111_11111
5F              -- Start indefinite-length byte string
   44           -- Byte string of length 4
      aabbccdd  -- Bytes content
   43           -- Byte string of length 3
      eeff99    -- Bytes content
   FF           -- "break"

3.3. 부동소수점 수 및 내용이 없는 값

주요 타입 7은 두 종류의 데이터, 즉 부동소수점 수와 내용을 필요로 하지 않는 "단순 값"을 위한 것이다. 초기 바이트의 5비트 추가 정보 값 각각은 표 3에 정의된 대로 별도의 의미를 가진다. 정수에 대한 주요 타입과 마찬가지로, 이 주요 타입의 항목은 내용 데이터를 담지 않는다. 모든 정보는 초기 바이트(헤드)에 있다.¶

다른 모든 주요 타입과 마찬가지로, 5비트 값 24는 단일 바이트 확장을 의미한다. 즉, 단순 값을 표현하기 위해 추가 바이트가 뒤따른다. (혼동을 최소화하기 위해 32에서 255까지의 값만 사용된다.) 이는 초기 바이트의 구조를 유지한다. 다른 주요 타입과 마찬가지로, 그 길이는 항상 첫 번째 바이트의 추가 정보에 의존한다. 표 4는 단순 값에 할당되고 사용할 수 있는 숫자 값을 나열한다.¶

인코더는 0xf8(주요 타입 7, 추가 정보 24)로 시작하고 0x20(십진수 32)보다 작은 바이트가 이어지는 2바이트 시퀀스를 내보내서는 MUST NOT 안 된다. 그러한 시퀀스는 올바른 형식이 아니다. (이는 인코더가 false, true, null, 또는 undefined를 2바이트 시퀀스로 인코딩할 수 없으며 이들의 1바이트 변형만 올바른 형식임을 의미한다. 더 일반적으로 말하면, 각 단순 값은 단 하나의 표현 변형만 가진다.)¶

5비트 값 25, 26, 27은 16비트, 32비트, 64비트 IEEE 754 이진 부동소수점 값 [IEEE754]을 위한 것이다. 이러한 부동소수점 값은 적절한 크기의 추가 바이트에 인코딩된다. (16비트 부동소수점 수에 대한 일부 정보는 부록 D를 참조한다.)¶

3.4. 항목 태그 지정

CBOR에서 데이터 항목은 태그 번호로 고유하게 식별되는 추가 의미를 부여하기 위해 태그로 둘러싸일 수 있다. 태그는 주요 타입 6이며, 그 인수(섹션 3)는 태그 번호를 나타내고, 단일 포함 데이터 항목인 태그 내용을 포함한다. (태그가 내용에 추가 구조를 요구하는 경우, 이 구조는 포함된 데이터 항목으로 제공된다.) 여기서는 태그 번호와 태그 내용 모두로 구성된 전체 데이터 항목을 태그라는 용어로 부른다. 태그 내용은 태그가 지정되는 데이터 항목이다.¶

예를 들어, 길이 12의 바이트 문자열이 부호 없는 큰 수(섹션 3.4.3)임을 나타내기 위해 번호 2의 태그로 표시된다고 가정한다. 인코딩된 데이터 항목은 바이트 0b110_00010(주요 타입 6, 태그 번호에 대한 추가 정보 2)으로 시작하고, 이어서 인코딩된 태그 내용, 즉 0b010_01100(주요 타입 2, 길이에 대한 추가 정보 12)과 큰 수의 12바이트가 뒤따른다.¶

확장된 일반 데이터 모델에서, 태그 번호의 정의는 그 태그 번호와 함께 전달되는 추가 의미를 설명한다. 이러한 의미는 일부 태그가 지정된 데이터 항목과 기본 일반 데이터 모델로 표현될 수 있는 다른 데이터 항목 사이의 동등성을 포함할 수 있다. 예를 들어, 태그 내용이 단일 바이트 0x01을 가진 바이트 문자열인 큰 수 0xc24101은 정수 1과 동등하며, 이는 0x01, 0x1801 또는 0x190001로도 인코딩될 수 있다. 태그 정의는 일반 인코더에 권장되는 선호 직렬화(섹션 4.1)를 지정할 수 있다. 이는 태그를 사용하는 표현보다 기본 일반 데이터 모델 표현을 선호할 수 있다.¶

태그 정의는 일반적으로 그러한 태그에 대해 어떤 중첩 데이터 항목이 유효한지를 정의한다. 태그 정의는 이 문서에 정의된 태그처럼 내용을 매우 특정한 구문 구조로 제한할 수도 있고, 더 의미적으로 내용을 정의할 수도 있다. 후자의 예는 태그 40 및 1040이 배열을 표현하는 여러 방식을 허용하는 방법이다 [RFC8746].¶

관례상 많은 태그는 null 또는 undefined 값을 태그 내용으로 받아들이지 않는다. 대신 기대되는 것은 null 또는 undefined 값을 전체 태그 대신 사용할 수 있다는 것이다. 섹션 3.4.2는 애플리케이션 프로토콜에서 그리고 플랫폼 타입으로 매핑할 때 이 관례를 처리하는 것에 대한 특정 태그의 추가 고려 사항을 제공한다.¶

디코더가 모든 태그 번호의 태그를 이해할 필요는 없으며, 특정 CBOR 데이터 항목을 생성하는 구현과 그 스트림을 디코딩하는 구현이 데이터 흐름의 각 항목의 의미를 알고 있는 애플리케이션에서는 태그의 가치가 거의 없을 수도 있다. 이 명세에서 태그의 주된 목적은 날짜와 같은 공통 데이터 타입을 정의하는 것이다. 부차적인 목적은 CBOR 데이터 항목을 다른 형식으로 변환해야 할 것으로 예상될 때 항목의 내용에 대한 힌트를 필요로 하는 경우 변환 힌트를 제공하는 것이다. 태그의 의미를 이해하는 것은 디코더에게 선택 사항이다. 디코더는 태그의 추가 의미를 해석하지 않고도 태그 번호와 태그 내용을 모두 애플리케이션에 단순히 제시할 수 있다.¶

태그는 자신이 둘러싸는 데이터 항목에 의미를 적용한다. 태그는 중첩될 수 있다. 태그 A가 태그 B를 둘러싸고, 태그 B가 데이터 항목 C를 둘러싸면, 태그 A는 태그 B를 데이터 항목 C에 적용한 결과에 적용된다.¶

IANA는 섹션 9.2에 설명된 대로 태그 번호 레지스트리를 유지한다. 표 5는 [RFC7049]에 정의된 태그 번호 중 이 섹션의 나머지 부분에서 정의를 제공하는 목록을 제공한다. (태그 번호 35도 [RFC7049]에 정의되어 있었다. 이 태그 번호에 대한 논의는 섹션 3.4.5.3에 나온다.) [RFC7049]가 출판된 이후 많은 다른 태그 번호도 정의되었다는 점에 유의한다. 전체 목록은 섹션 9.2에 설명된 레지스트리를 참조한다.¶

개념적으로, 태그는 (역)직렬화 시간이 아니라 일반 데이터 모델에서 해석된다. 소수의 태그(현재로서는 태그 번호 25와 태그 번호 29 [IANA.cbor-tags])는 (역)직렬화 시간에 처리를 필요로 할 수 있는 의미로 등록되어 있다. 즉, 디코더는 데이터 항목이 CBOR 데이터 항목으로 인코딩되는 정확한 순서를 인식해야 하며, 인코더는 그 순서를 제어해야 한다. 이는 이러한 태그가 임의의 일반 CBOR 인코더/디코더 위에서 구현될 수 없음을 의미한다(그러한 인코더/디코더는 맵의 항목에 대한 직렬화 순서를 데이터 모델 수준에서 반영하지 않을 수 있으며 그 반대도 마찬가지이다). 따라서 이들의 구현은 일반적으로 일반 인코더/디코더에 통합되어야 한다. 이러한 속성을 가진 새 태그를 정의하는 것은 NOT RECOMMENDED이다.¶

IANA는 태그 번호 65535, 4294967295 및 18446744073709551615(16비트, 32비트, 64비트에서 이진수 모든 비트가 1)를 할당했다. 이들은 특정 태그의 존재 또는 태그 부재를 나타내기 위한 단일 정수 데이터 구조를 원하는 구현자를 위한 편의로 사용될 수 있다. 그 할당은 [CBOR-TAGS]의 섹션 10에 설명되어 있다. 이러한 태그는 실제 CBOR 데이터 항목에 나타나도록 의도되지 않았다. 구현은 그러한 발생을 오류로 표시할 MAY 수 있다.¶

프로토콜은 태그 번호 0 및 1을 사용하여 시점을 나타내는 데이터 항목으로, 태그 번호 2 및 3을 사용하여 임의 크기의 정수로, 그리고 태그 번호 4 및 5를 사용하여 임의 크기와 정밀도의 부동소수점 값으로 일반 데이터 모델(섹션 2)을 확장할 수 있다.¶

C2                        -- Tag 2
   49                     -- Byte string of length 9
      010000000000000000  -- Bytes content

C4             -- Tag 4
   82          -- Array of length 2
      21       -- -2
      19 6ab3  -- 27315

C5             -- Tag 5
   82          -- Array of length 2
      20       -- -1
      03       -- 3

4.1. 선호 직렬화

데이터 모델 수준의 일부 값에 대해 CBOR는 여러 직렬화를 제공한다. 많은 애플리케이션에서는 인코더가 항상 선호 직렬화(선호 인코딩)를 선택하는 것이 바람직하다. 그러나 현재 명세는 이 선호를 강제하는 부담을 인코더나 디코더 어느 쪽에도 지우지 않는다.¶

일부 제약 디코더는 비선호 직렬화를 디코딩하는 능력이 제한될 수 있다. 예를 들어, 어떤 애플리케이션에서 1_000_000_000(십억) 미만의 정수만 예상된다면, 디코더는 정수의 64비트 인수를 디코딩하는 데 필요한 코드를 생략할 수 있다. 항상 선호 직렬화("선호 인코더")를 사용하는 인코더는 이 애플리케이션에서 발생할 수 있는 숫자에 대해 이 디코더와 상호 운용된다. 일반적으로 말해, 선호 인코더는 예컨대 항상 64비트 정수를 사용하는 인코더보다 더 보편적으로 상호 운용 가능하며 또한 낭비도 적다.¶

마찬가지로, 제약 인코더는 지원하는 표현 변형의 다양성이 제한되어 선호 직렬화를 내보내지 않을 수 있다("변형 인코더"). 예를 들어, 제약 인코더는 더 짧은 표현을 사용할 수 있더라도 자신이 인코딩하는 정수에 대해 항상 32비트 변형을 사용하도록 설계될 수 있다(64비트 변형으로만 표현할 수 있는 정수가 애플리케이션에 필요하지 않다고 가정). 선호 직렬화만 수신한다고 가정하지 않는 디코더 ("변형 허용 디코더")는 따라서 더 보편적으로 상호 운용 가능하다고 할 수 있다(다만 선호 직렬화를 수신하는 경우에 최적화할 수도 있다). CBOR 디코더의 완전한 구현은 정의상 변형 허용적이다. 이 구분은 CBOR 디코더의 제약 구현이 변형 인코더를 만나는 경우에만 관련된다.¶

선호 직렬화는 항상 인수(섹션 3)를 표현하는 가장 짧은 형식을 사용한다. 또한 인코딩되는 값을 보존하는 가장 짧은 부동소수점 인코딩을 사용한다.¶

부동소수점 값에 대한 선호 직렬화는 그 값을 보존하는 가장 짧은 부동소수점 인코딩이다. 예를 들어 숫자 5.5는 0xf94580, 숫자 5555.5는 0xfa45ad9c00이다. NaN 값의 경우, 더 짧은 가수를 오른쪽으로 0으로 채웠을 때 원래 NaN 값이 재구성된다면 더 짧은 인코딩이 선호된다 (많은 애플리케이션에서는 단일 NaN 인코딩 0xf97e00이면 충분하다).¶

항목의 직렬화가 시작되는 시점에 길이를 알고 있다면 항상 정길이 인코딩이 선호된다.¶

4.2. 결정적으로 인코딩된 CBOR

일부 프로토콜은 인코더가 특정한 결정적 형식의 CBOR만 내보내기를 원할 수 있다. 그러한 프로토콜은 또한 디코더가 입력이 그 결정적 형식인지 확인하게 할 수도 있다. 그러한 프로토콜은 "결정적 형식"이 무엇을 의미하는지, 그리고 인코더와 디코더가 무엇을 해야 하는지를 자유롭게 정의할 수 있다. 이 섹션은 그러한 결정적 형식의 기반이 될 수 있는 제한 집합을 정의한다.¶

5.1. 스트리밍 애플리케이션에서의 CBOR

스트리밍 애플리케이션에서 데이터 스트림은 CBOR 데이터 항목들의 시퀀스를 연속으로 이어 붙인 것으로 구성될 수 있다. 이러한 환경에서는 이전 데이터 항목의 끝 이후에 데이터가 발견되면 디코더가 즉시 새 데이터 항목의 디코딩을 시작한다.¶

데이터 항목을 구성하는 모든 바이트가 디코더에 즉시 제공되지는 않을 수 있다. 일부 디코더는 완전한 데이터 항목을 애플리케이션에 제시할 수 있을 때까지 추가 데이터를 버퍼링한다. 다른 디코더는 최상위 데이터 항목에 대한 부분 정보를 애플리케이션에 제시할 수 있다. 예를 들어 이미 디코딩할 수 있는 중첩 데이터 항목이나, 아직 완전히 도착하지 않은 바이트 문자열의 일부도 제시할 수 있다. 그러한 애플리케이션은 또한 애플리케이션에 제시되는 점진적 데이터에 대해 원하는 보호를 제공할 수 있는, 일치하는 스트리밍 보안 메커니즘을 가져야 MUST 한다.¶

일부 애플리케이션과 프로토콜은 부정 길이 인코딩을 사용하고 싶어 하지 않을 수 있음에 유의한다. 부정 길이 인코딩을 사용하면 인코더가 개수를 세기 위해 모든 데이터를 마샬링할 필요가 없지만, 디코더는 항목의 끝을 기다리는 동안 증가하는 양의 메모리를 할당해야 한다. 이는 일부 애플리케이션에는 괜찮을 수 있지만 다른 애플리케이션에는 그렇지 않을 수 있다.¶

5.2. 일반 인코더 및 디코더

일반 CBOR 디코더는 모든 올바른 형식의 인코딩된 CBOR 데이터 항목을 디코딩하고 그 데이터 항목을 애플리케이션에 제시할 수 있다. 부록 C를 참조한다. (진단 표기법(섹션 8)은 올바른 형식의 CBOR 값을 사람에게 제시하는 데 사용될 수 있다.)¶

일반 CBOR 인코더는 인코더가 알지 못하는 단순 값과 태그를 포함하여, 애플리케이션이 올바른 형식의 어떤 값이든 CBOR 데이터 항목으로 인코딩하도록 지정할 수 있는 애플리케이션 인터페이스를 제공한다.¶

CBOR가 이러한 경우를 최소화하려고 시도하더라도, 모든 올바른 형식의 CBOR 데이터가 유효한 것은 아니다. 예를 들어, 인코딩된 텍스트 문자열 0x62c0ae는 유효한 UTF-8을 포함하지 않는다 ([RFC3629]가 항상 가장 짧은 형식을 사용하도록 요구하기 때문). 따라서 이는 유효한 CBOR 항목이 아니다. 또한 특정 태그는 의미적 제약을 만들 수 있으며, 예를 들어 큰 수 태그가 다른 태그를 둘러싸거나, 태그 번호 0의 인스턴스가 바이트 문자열을 포함하거나 [RFC3339]의 date-time 생성 규칙과 일치하지 않는 내용을 가진 텍스트 문자열을 포함하는 경우 이러한 제약이 위반될 수 있다. 일반 인코더와 디코더가 유효하지 않은 데이터 처리를 가능하게 하기 위해 애플리케이션 인터페이스에 부자연스러운 선택을 해야 한다는 요구 사항은 없다. 일반 인코더와 디코더는 인코더/디코더가 작성된 시점에 특정 코드포인트가 등록되어 있지 않더라도 단순 값과 태그를 전달할 것으로 기대된다 (섹션 5.4).¶

5.3. 항목의 유효성

올바른 형식이지만 유효하지 않은 CBOR 데이터 항목(섹션 1.2)은 그 안에 인코딩된 데이터를 CBOR 데이터 모델에서 해석하는 데 문제를 제기한다. CBOR 기반 프로토콜은 여러 계층으로 지정될 수 있으며, 이때 하위 계층은 자신들이 전달하는 일부 CBOR 데이터의 의미를 처리하지 않는다. 이러한 계층은 처리하지 않는 데이터의 유효성 오류를 알아차릴 수 없으며, 그 데이터를 있는 그대로 전달해야 MUST 한다. 유효하지 않은 CBOR 항목의 의미를 처리하는 첫 번째 계층은 두 가지 선택지 중 하나를 선택해야 MUST 한다.¶

1. 문제가 있는 항목을 오류 표시자로 바꾸고 다음 항목으로 계속한다. 또는¶
2. 오류를 내고 처리를 완전히 중지한다.¶

CBOR 기반 프로토콜은 자신들의 디코더가 마주칠 수 있는 각 종류의 유효하지 않은 항목에 대해 이러한 옵션 중 어느 것을 취하는지 지정해야 MUST 한다.¶

이러한 문제는 CBOR의 기본 유효성 수준이나 태그(태그 유효성)의 맥락에서 발생할 수 있다.¶

5.4. 유효성 및 발전

유효성 검사를 수행하는 디코더는 유효성 오류가 있는 데이터 항목을 신뢰성 있게 감지하기 위해 노력을 들인다. 예를 들어, 그러한 디코더는 이전 하위 섹션에 나열된 유효성 오류 중 어느 것이든 포함하는 CBOR 데이터 항목에 대해 오류를 보고하고 데이터를 반환하지 않는 API를 가져야 한다.¶

"Concise Binary Object Representation (CBOR) Tags" 레지스트리(섹션 9.2)에 정의된 태그 집합과 "Concise Binary Object Representation (CBOR) Simple Values" 레지스트리(섹션 9.1)에 정의된 단순 값 집합은 일반 디코더가 이해하는 집합을 넘어 언제든지 증가할 수 있다. 유효성 검사 디코더는 자신이 인식하지 못하는 그러한 경우를 만나면 다음 두 가지 중 하나를 수행할 수 있다.¶

• 오류를 보고하고 데이터를 반환하지 않을 수 있다. 이 경우를 오류로 처리하면 고착화를 유발할 수 있으므로 권장되지 않는다는 점에 유의한다. 이 오류는 그 자체로는 유효성 오류가 아니다. 이러한 종류의 오류는 이것이 알려진 경우였다면 유효성 검사를 수행했을 디코더가 제기할 가능성이 더 높다.¶
• 알 수 없는 항목(타입, 값, 그리고 태그의 경우 디코딩된 태그가 지정된 데이터 항목)을 디코더를 호출한 애플리케이션에 내보내고, 그 후 디코더가 해당 태그 번호 또는 단순 값을 인식하지 못했다는 표시를 애플리케이션에 제공할 수 있다.¶

후자의 접근 방식은 유효성 검사를 지원하지 않는 디코더에도 적합하며, 새로 등록된 태그와 단순 값에 대해 호출 애플리케이션과 동시에 인코더를 업데이트해야 할 필요 없이 전방 호환성을 제공한다. (이를 위해 디코더의 API는 호출 애플리케이션이 프로그램에 적합한 방식으로 처리할 수 있도록 알 수 없는 항목을 표시하는 능력이 필요하다.)¶

유효성 검사에 필요한 처리 중 일부는 상당한 비용을 가질 수 있으므로(특히 맵의 중복 감지), 유효성 검사 지원은 모든 CBOR 디코더에 부과되는 요구 사항이 아니다.¶

일부 인코더는 애플리케이션이 유효한 CBOR가 인코더에서 나오도록 입력 데이터를 제공한다고 가정한다. 일반 인코더는 또한 애플리케이션이 실제로 API에 부합하는 데이터를 제공하는지 여부와 무관하게 자신의 출력을 유효한 CBOR로 신뢰성 있게 제한하는 유효성 검사 모드를 제공하고자 할 수 있다.¶

5.5. 숫자

CBOR 기반 프로토콜은 서로 다른 언어 환경이 표현 가능한 숫자의 범위와 정밀도에 서로 다른 제한을 부과한다는 점을 고려해야 한다. 예를 들어, 기본 JavaScript 숫자 시스템은 모든 숫자를 부동소수점 값으로 취급하므로, 53개를 초과하는 유효 비트를 가진 정수를 디코딩할 때 정밀도가 조용히 손실될 수 있다. 또 다른 예는 CBOR가 정수 표현의 부호 비트를 주요 타입에 보관하므로, 특정 길이의 부호 있는 숫자에 대해 동일한 길이의 일반적인 플랫폼 부호 있는 정수 표현보다 한 비트가 더 많다는 것이다 (예: 1+8바이트 정수의 경우 -2⁶⁴..2⁶⁴-1, 8바이트 int64_t의 경우 -2⁶³..2⁶³-1). 숫자를 사용하는 프로토콜은 디코더와 수신 애플리케이션에서 비사소한 숫자를 어떻게 처리할지에 대한 기대를 정의해야 한다.¶

부동소수점 수를 포함하는 CBOR 기반 프로토콜은 세 가지 형식(반정밀도, 단정밀도, 배정밀도) 중 어느 것이 지원되어야 하는지를 제한할 수 있다. 정수 전용 애플리케이션의 경우, 프로토콜은 부동소수점 값의 사용을 완전히 배제하고자 할 수 있다.¶

간결성을 위해 설계된 CBOR 기반 프로토콜은 애플리케이션에 필요한 것보다 긴 특정 정수 인코딩을 배제하여, 예를 들어 64비트 정수를 구현할 필요를 줄이고자 할 수 있다. 인코더가 주어진 값을 표현할 수 있는 가장 간결한 정수 표현을 사용할 것이라는 기대가 있다. 그러나 결정적 인코딩을 요구하지 않는 간결한 애플리케이션은 주어진 크기의 정수를 디코딩할 수 있는 한, 필요한 것보다 긴 인코딩(예: "0"을 0b000_11001 뒤에 두 바이트 0x00이 오는 방식으로 인코딩)을 사용하는 값을 받아들여야 한다. 유사한 고려 사항은 부동소수점 값에도 적용된다. 선호 직렬화와 필요한 것보다 긴 직렬화를 모두 디코딩하는 것이 권장된다.¶

특정 숫자를 정수로 표현할지, 또는 십진 분수나 큰 부동소수점 수로 표현할지 선택지를 제공하는 제약 애플리케이션용 CBOR 기반 프로토콜(예: 지수가 작고 음이 아닌 경우)은 정수 표현이 직접 사용된다는 구현 품질 기대를 표현하고자 할 수 있다.¶

5.6. 맵의 키 지정

인코딩 및 디코딩 애플리케이션은 맵에서 어떤 타입의 키가 사용될 것인지에 대해 합의해야 한다. JSON 기반 애플리케이션과 상호 운용해야 하는 애플리케이션에서는 키를 텍스트 문자열로만 제한함으로써 변환이 단순해진다. 그렇지 않으면 다른 CBOR 타입에서 텍스트 문자열로의 지정된 매핑이 있어야 하며, 이는 종종 구현 오류로 이어진다. 키가 본질적으로 숫자인 애플리케이션에서, 그리고 키의 숫자 순서가 애플리케이션에 중요하다면, 키에 숫자를 직접 사용하는 것이 유용하다.¶

여러 타입의 키가 사용될 경우, 사용될 특정 프로그래밍 환경에서 이러한 타입들이 어떻게 표현될지를 고려해야 한다. 예를 들어, JavaScript Maps [ECMA262]에서는 정수 1인 키를 부동소수점 1.0인 키와 구별할 수 없다. 이는 정수 키가 사용된다면 프로토콜이 같은 맵에서 값이 우연히 정수인 부동소수점 키의 사용을 피해야 함을 의미한다.¶

CBOR 데이터 항목 안에 중첩된 데이터 항목을 디코딩하는 즉시 전달하는 디코더("스트리밍 디코더")는 종종 맵에서 키의 고유성을 확인하는 데 필요한 상태를 유지하지 않는다. 마찬가지로, 포함하는 데이터 항목이 완전히 사용 가능해지기 전에 데이터 항목의 인코딩을 시작할 수 있는 인코더("스트리밍 인코더")는 데이터 소스가 고유성을 유지한다고 믿음으로써 자신의 오버헤드를 크게 줄이고자 할 수 있다.¶

CBOR 기반 프로토콜은 수신 애플리케이션이 맵에서 여러 동일한 키를 보았을 때 무엇을 해야 하는지 정의해야 MUST 한다. 프로토콜의 결과 규칙은 CBOR 데이터 모델을 존중해야 MUST 한다. 즉, 동일한 키를 가진 항목에 대한 특정 처리를 규정할 수 없으며, 다만 맵에 동일한 키가 있으면 잘못된 형식의 맵을 나타내고 디코더가 오류로 중지해야 한다는 규칙을 둘 수는 있다. 중복 키를 가진 항목을 보이는 맵을 처리할 때, 일반 디코더는 다음 중 하나를 수행할 수 있다.¶

• 중복 키가 있는 맵을 받아들이지 않는다 (즉, 맵에 대한 유효성을 강제한다. 섹션 5.4도 참조). 이러한 일반 디코더는 보편적으로 유용하다. 애플리케이션은 여전히 애플리케이션 규칙에 따라 자체 중복 검사를 수행해야 할 수 있다(예를 들어, 특정 맵의 맵 키 위치에서 애플리케이션이 정수와 부동소수점 값을 동등하게 취급하는 경우).¶
• 중복 키가 있는 항목을 포함하여 모든 맵 항목을 애플리케이션에 전달한다. 이는 애플리케이션 규칙이 일반 데이터 모델 규칙과 동일하더라도, 애플리케이션이 중복 키를 처리(검사)해야 함을 요구한다.¶
• 중복 키가 있는 항목 중 일부를 잃는다. 예를 들어 같은 키를 가진 항목들 중 마지막(또는 첫 번째) 항목만 전달한다. 그러한 일반 디코더를 사용하면 애플리케이션은 특정 키에 대해 실행마다, 그리고 일반 디코더마다 서로 다른 결과를 얻을 수 있으며, 어떤 값이 반환되는지는 일반 디코더 구현과 맵 안의 실제 키 순서에 기반한다. 특히, 애플리케이션은 반드시 모든 항목을 보는 것은 아니므로 자체적으로 키 고유성을 검증할 수 없으며, 키 고유성을 검증해야 한다면 그러한 일반 디코더를 사용할 수 없을 수 있다. 이러한 일반 디코더는 데이터 소스와 전송이 항상 유효한 맵을 제공하는 상황에서만 사용할 수 있다. 데이터 소스와 전송이 공격받을 수 있다면 이는 불가능하다.¶

일반 디코더는 이 세 접근 방식 중 어느 것을 구현하는지 문서화해야 한다.¶

맵에 대한 CBOR 데이터 모델은 맵 표현에서 키/값 쌍의 순서에 의미를 부여하는 것을 허용하지 않는다. 따라서 CBOR 기반 프로토콜은 맵에서 키/값 쌍의 순서를 바꾸는 것이 의미를 바꾼다고 지정해서는 MUST NOT 안 된다. 다만 예를 들어 결정적 인코딩(섹션 4.2)의 요구 사항을 충족하지 않는 순서를 허용하지 않는다고 지정하는 것은 예외이다. (맵 순서가 타이밍, 캐시 사용 및 기타 잠재적 부채널에 미치는 2차 효과는 의미의 일부로 간주되지 않지만, 프로토콜이 결정적 인코딩 형식을 요구할 충분한 이유가 될 수는 있다.)¶

제약 장치용 애플리케이션은 자주 사용되는 키가 적은 수로 있는 맵을 가진 경우, 작은 정수를 키로 사용하는 것을 고려해야 한다. 예를 들어 24개 이하의 키 집합은 부호 없는 정수로 한 바이트에 인코딩될 수 있으며, 음의 정수도 사용한다면 최대 48개까지 가능하다. 덜 자주 발생하는 키는 더 긴 인코딩을 가진 정수를 사용할 수 있다.¶

5.7. 정의되지 않은 값

일부 CBOR 기반 프로토콜에서는 undefined의 단순 값(섹션 3.3)이 인코더에 의해 인코딩 문제가 있는 데이터 항목의 대체물로 사용될 수 있다. 이는 포함하는 나머지 데이터 항목들이 해를 끼치지 않고 인코딩될 수 있도록 하기 위한 것이다.¶

6.1. CBOR에서 JSON으로 변환

CBOR의 대부분 타입은 JSON에 직접적인 대응물이 있다. 그러나 일부는 그렇지 않으며, CBOR-to-JSON 변환기를 구현하는 사람은 그런 경우 무엇을 할지 고려해야 한다. 다음 비규범적 조언은 이들을 JSON null과 같은 단일 대체 값으로 변환하는 방식으로 다룬다.¶

• 정수(주요 타입 0 또는 1)는 JSON 숫자가 된다.¶
• 제안된 인코딩을 지정하는 태그에 포함되어 있지 않은 바이트 문자열(주요 타입 2)은 패딩 없는 base64url로 인코딩되어 JSON 문자열이 된다.¶
• UTF-8 문자열(주요 타입 3)은 JSON 문자열이 된다. JSON은 특정 문자([RFC8259], 섹션 7)를 이스케이프해야 한다는 점에 유의한다: 따옴표(U+0022), 역 솔리더스(U+005C), 그리고 "C0 제어 문자"(U+0000부터 U+001F까지). 다른 모든 문자는 JSON UTF-8 문자열에 변경 없이 복사된다.¶
• 배열(주요 타입 4)은 JSON 배열이 된다.¶
• 맵(주요 타입 5)은 JSON 객체가 된다. 이는 모든 키가 UTF-8 문자열인 경우에만 직접 가능하다. 변환기는 다른 키도 UTF-8 문자열로 변환할 수 있다(예: 정수를 그 십진수 표현을 포함하는 문자열로 변환). 그러나 그렇게 하면 키 충돌의 위험이 생긴다. 또한 아래에서 제안한 것처럼 UTF-8 문자열의 태그를 무시하면, 태그가 다르더라도 문자열이 같을 때 키 충돌이 발생한다는 점에 유의한다.¶
• False(주요 타입 7, 추가 정보 20)는 JSON false가 된다.¶
• True(주요 타입 7, 추가 정보 21)는 JSON true가 된다.¶
• Null(주요 타입 7, 추가 정보 22)은 JSON null이 된다.¶
• 부동소수점 값(주요 타입 7, 추가 정보 25부터 27까지)은 유한한 경우 JSON 숫자가 된다 (즉, JSON 숫자로 표현될 수 있다). 값이 비유한값(NaN, 또는 양의 Infinity나 음의 Infinity)이면 대체 값으로 표현된다.¶
• 다른 모든 단순 값(주요 타입 7, 아직 논의되지 않은 임의의 추가 정보 값)은 대체 값으로 표현된다.¶
• 큰 수(주요 타입 6, 태그 번호 2 또는 3)는 그 바이트 문자열을 패딩 없는 base64url로 인코딩하여 JSON 문자열이 되는 방식으로 표현된다. 태그 번호 3(음의 큰 수)의 경우, base 인코딩된 값 앞에 "~"(ASCII 물결표)가 삽입된다. (숫자 대신 이진 블롭으로 변환하는 것은 JSON 디코더에서 발생할 가능성이 높은 숫자 오버플로를 방지하기 위한 것이다.)¶
• 인코딩 힌트가 있는 바이트 문자열(주요 타입 6, 태그 번호 21부터 23까지)은 힌트가 설명하는 대로 인코딩되어 JSON 문자열이 된다.¶
• 다른 모든 태그(주요 타입 6, 임의의 다른 태그 번호)의 경우, 태그 내용은 JSON 값으로 표현되며 태그 번호는 무시된다.¶
• 부정 길이 항목은 변환 전에 정길이로 만들어진다.¶

CBOR-to-JSON 변환기는 상호 운용성을 극대화하고 JSON 출력이 예측 가능한 결과로 처리될 수 있다는 신뢰를 높이기 위해 JSON 프로필 I-JSON [RFC7493]을 따르고자 할 수 있다. 예를 들어, 이는 안정적으로 표현될 수 있는 정수 범위뿐 아니라, 오래된 JSON 구현이 지원할 수 있는 최상위 항목에도 영향을 미친다.¶

6.2. JSON에서 CBOR로 변환

모든 JSON 값은 일단 디코딩되면 하나 이상의 CBOR 값으로 직접 매핑된다. 어떤 종류의 CBOR 생성에서와 마찬가지로, 숫자 표현과 관련하여 결정을 내려야 한다. 제안되는 변환에서는 다음과 같다.¶

• 소수 부분이 없는 JSON 숫자(정수 숫자)는 가장 짧은 형식을 선택하여 정수(주요 타입 0 및 1, 가능한 경우 주요 타입 6, 태그 번호 2 및 3)로 표현된다. 구현이 정의한 임계값보다 긴 정수는 대신 부동소수점 값으로 표현될 수 있다. 정수로 표현되는 기본 범위는 -2⁵³+1..2⁵³-1이다(JSON을 디코딩하는 데 자주 사용되는 binary64 표현에서 정확한 정수 범위를 완전히 활용함 [RFC7493]). CBOR 기반 프로토콜 또는 일반 변환기 구현은 -2³²..2³²-1 또는 -2⁶⁴..2⁶⁴-1(각각 uint32_t 또는 uint64_t로 CBOR에서 사용할 수 있는 정수 범위를 완전히 사용함), 또는 심지어 -2³¹..2³¹-1 또는 -2⁶³..2⁶³-1(2의 보수 부호 있는 정수에서 널리 쓰이는 범위를 사용함)을 선택할 수 있다. (JSON이 JavaScript 구현에서 생성되었다면, 그 정밀도는 이미 최대 53비트로 제한된다.)¶
• 소수 부분이 있는 숫자는 부동소수점 값으로 표현되며, IEEE 754 binary64가 제공하는 정밀도를 기반으로 십진수-이진수 변환을 수행한다. JSON 숫자의 수학적 값은 [IEEE754]의 섹션 4.3.1에 있는 roundTiesToEven 절차를 사용하여 binary64로 변환된다. 그런 다음 CBOR로 인코딩할 때, 선호 직렬화는 이 변환 결과를 정확히 표현하는 가장 짧은 부동소수점 표현을 사용한다. 예를 들어, 1.5는 16비트 부동소수점 값으로 표현된다(다만 모든 구현이 최소 형식을 효율적으로 찾을 수 있는 것은 아니다). 기본 binary64 정밀도를 사용하는 대신, 표현되는 값의 정밀도에 영향을 주는 구현 정의 변환 정밀도 제한이 있을 수 있다. 십진 표현은 프로토콜에서 지정한 경우에만 CBOR 쪽에서 사용해야 한다.¶

CBOR는 일반적으로 JSON보다 더 간결한 인코딩을 제공하도록 설계되었다. 떠올릴 수 있는 한 가지 구현 전략은 단일 버퍼 안에서 JSON-to-CBOR 인코딩을 제자리에서 수행하는 것이다. 이 전략은 병적인 여러 경우를 신중하게 고려해야 한다. 예를 들어, 이스케이프가 없거나 매우 적고 255바이트보다 길거나 훨씬 긴 일부 문자열은 CBOR에서 UTF-8 문자열로 인코딩될 때 확장될 수 있다. 마찬가지로, 일부 이진 부동소수점 표현은 JSON의 짧은 십진 표현(1.1, 1e9)에서 확장을 일으킬 수 있다. 이를 올바르게 처리하기는 어려울 수 있으며, 그 결과 발생하는 취약점은 공격자에 의해 악용될 수 있다.¶

7.1. 확장 지점

프로토콜 설계에서 발전의 기회는 종종 확장 지점의 형태로 포함된다. 예를 들어, 처음부터 완전히 할당되지 않은 코드포인트 공간이 있을 수 있으며, 프로토콜은 처음 할당된 것보다 더 많은 코드포인트를 사용하기 시작하는 구현을 용인하고 수용하도록 설계된다.¶

필요한 범위를 예측하기 어려울 수 있으므로 코드포인트 공간의 크기를 정하는 것은 어려울 수 있다. 프로토콜 설계는 의도된 프로토콜 수명 동안 천천히 채워질 수 있을 만큼 코드포인트 공간을 충분히 크게 만들도록 시도해야 한다.¶

CBOR에는 세 가지 주요 확장 지점이 있다.¶

"simple" 공간(주요 타입 7의 값):

24개의 효율적인 값(그리고 224개의 약간 덜 효율적인 값) 중 소수만 할당되어 있다. 알 수 없는 단순 데이터 항목을 수신하는 구현은 그 값의 구조가 실제로 단순하다면 이를 그대로 쉽게 처리할 수 있을 수 있다. 섹션 9.1의 IANA 레지스트리가 이 코드포인트 공간의 확장성을 다루는 적절한 방법이다.¶

"tag" 공간(주요 타입 6의 값):

전체 코드포인트 공간은 풍부하며, 아주 작은 부분만 할당되어 있다. 그러나 이 코드포인트들이 모두 똑같이 효율적인 것은 아니다. 처음 24개는 단일("1+0") 바이트만 소비하며, 그 절반은 이미 할당되어 있다. 다음 232개 값은 두("1+1") 바이트만 소비하며, 거의 4분의 1이 이미 할당되어 있다. 이러한 하위 공간은 몇십 년 더 지속되도록 어느 정도 관리가 필요하다. 알 수 없는 태그 번호를 수신하는 구현은 포함된 태그 내용만 처리하거나, 바람직하게는 태그 내용을 감싸는 알 수 없는 태그 번호로 태그를 처리하도록 선택할 수 있다. 섹션 9.2의 IANA 레지스트리가 이 코드포인트 공간의 확장성을 다루는 적절한 방법이다.¶

"additional information" 공간:

알 수 없는 추가 정보 값을 수신한 구현은 디코딩을 계속할 방법이 없으므로, 이 공간에 코드포인트를 할당하는 것은 단순히 확장 지점을 사용하는 것보다 훨씬 큰 단계이다. 또한 남아 있는 코드포인트도 매우 적다. 섹션 7.2도 참조한다.¶

7.2. 추가 정보 공간 관리

인간의 마음은 때때로 어떤 것을 깔끔하게 만들기 위해 작게 인식되는 빈틈을 채우는 데 끌린다. 추가 정보 값의 코드포인트 공간에 남아 있는 빈틈은, 단지 거기에 있다는 이유만으로 새로운 아이디어를 끌어들이는 요인이 될 것으로 예상한다.¶

현재 명세는 추가 정보 코드포인트 공간을 IANA 레지스트리로 관리하지 않는다. 대신, 이 공간에서의 할당은 이 명세를 갱신하는 방법으로만 수행될 수 있다.¶

n >= 24인 추가 정보 값의 경우, 추가 데이터의 크기는 일반적으로 2^n-24바이트이다. 따라서 추가 정보 값 28과 29는 프로토콜에 추가해야 할 필요가 생길 경우 128비트 및 256비트 수량의 후보로 보아야 한다. 그러면 추가 정보 값 30은 일반 할당에 사용할 수 있는 유일한 추가 정보 값이 되며, 현재 명세의 갱신을 통해 이를 할당하기 전에 매우 좋은 이유가 있어야 한다.¶

8.1. 인코딩 표시자

때때로 진단 표기법에서 여러 대체 표현 중 실제로 어떤 것이 사용되었는지를 나타내는 것이 유용하다. 예를 들어, 진단 디코더가 >1.5<로 쓴 데이터 항목은 반정밀도, 단정밀도 또는 배정밀도 부동소수점으로 인코딩되었을 수 있다.¶

인코딩 표시자의 관례는 밑줄로 시작하고 뒤따르는 모든 영숫자 또는 밑줄 문자가 인코딩 표시자라는 것이며, 이 정보에 관심이 없는 사람은 이를 무시할 수 있다. 예: _ 또는 _3. 인코딩 표시자는 항상 선택 사항이다.¶

맵의 여는 중괄호나 배열의 여는 대괄호 뒤에 단일 밑줄을 써서 데이터 항목이 부정 길이 형식으로 표현되었음을 나타낼 수 있다. 예를 들어, [_ 1, 2]는 데이터 항목 [1, 2]를 표현하는 데 부정 길이 표현이 사용되었다는 표시자를 포함한다.¶

밑줄 뒤에 십진 숫자 n이 오면 앞선 항목(또는 배열과 맵의 경우 앞선 대괄호나 중괄호로 시작하는 항목)이 24+n의 추가 정보 값으로 인코딩되었음을 나타낸다. 예를 들어, 1.5_1은 반정밀도 부동소수점 수이고, 1.5_3은 배정밀도로 인코딩된다. 이 인코딩 표시자는 부록 A에는 표시되지 않는다. (따라서 인코딩 표시자 "_"는 사용되지 않는 전체 형식 "_7"의 축약이라는 점에 유의한다.)¶

부정 길이의 바이트 및 텍스트 문자열의 자세한 청크 구조는 (_ h'0123', h'4567') 및 (_ "foo", "bar") 형식으로 표기할 수 있다. 그러나 내부에 청크가 없는 부정 길이 문자열의 경우, (_ )는 바이트 문자열(0x5fff)을 의미하는지 텍스트 문자열 (0x7fff)을 의미하는지 모호하므로 사용되지 않는다. 대신 기본 형식 ''_ 및 ""_를 사용할 수 있으며, 청크가 없는 경우에만 예약된다. 이는 청크 구조를 보존하기 위해 (_ ''), (_ "") 등으로 표기해야 하는, 빈 청크만 있는(허용되지만 실제로는 유용하지 않은) 인코딩의 짧은 형식이 아니다.¶

9.1. CBOR 단순 값 레지스트리

IANA는 [IANA.cbor-simple-values]에 "Concise Binary Object Representation (CBOR) Simple Values" 레지스트리를 만들었다. 초기 값은 표 4에 나와 있다.¶

0부터 19까지 범위의 새 항목은 Standards Action [RFC8126]으로 할당된다. 하위 번호를 연속 블록(있는 경우)을 위해 예약하기 위해, IANA가 숫자 16부터 값을 할당하는 것이 제안된다.¶

32부터 255까지 범위의 새 항목은 Specification Required로 할당된다.¶

9.2. CBOR 태그 레지스트리

IANA는 [IANA.cbor-tags]에 "Concise Binary Object Representation (CBOR) Tags" 레지스트리를 만들었다. [RFC7049]에 정의되어 있던 태그들은 섹션 3.4에서 자세히 설명되며, 그 이후 다른 태그들도 이미 정의되었다.¶

0부터 23까지("1+0") 범위의 새 항목은 Standards Action으로 할당된다. 24부터 255까지("1+1") 및 256부터 32767까지("1+2"의 하위 절반) 범위의 새 항목은 Specification Required로 할당된다. 32768부터 18446744073709551615까지 ("1+2"의 상위 절반, "1+4" 및 "1+8") 범위의 새 항목은 First Come First Served로 할당된다. 등록 요청 템플릿은 다음과 같다.¶

• 데이터 항목¶
• 의미(짧은 형식)¶

또한 First Come First Served 요청에는 다음이 포함되어야 한다.¶

• 연락 담당자¶
• 의미 설명(URL) -- 이 설명은 선택 사항이다. URL은 Internet-Draft나 웹 페이지 같은 것을 가리킬 수 있다.¶

First Come First Served 범위를 사용하고 32비트로 표현할 수 없는 태그 번호 (즉, 4294967295보다 큰 번호)를 제안하는 신청자는, 이것이 64비트 숫자를 지원하지 않는 구현과의 상호 운용성을 줄일 수 있음을 인식해야 한다.¶

9.3. 미디어 타입 레지스트리

단일 인코딩된 CBOR 데이터 항목에 대한 인터넷 미디어 타입 [RFC6838] ("MIME 타입")은 "Media Types" 레지스트리 [IANA.media-types]에 정의된 "application/cbor"이다:¶

타입 이름:

application¶

하위 타입 이름:

cbor¶

필수 매개변수:

n/a¶

선택 매개변수:

n/a¶

인코딩 고려 사항:

이진¶

보안 고려 사항:

RFC 8949의 섹션 10 참조.¶

상호 운용성 고려 사항:

n/a¶

공개된 명세:

RFC 8949¶

이 미디어 타입을 사용하는 애플리케이션:

다수¶

추가 정보:

매직 넘버:

n/a¶

파일 확장자:

.cbor¶

Macintosh 파일 타입 코드:

n/a¶

추가 정보를 위한 연락 담당자 및 이메일 주소:

IETF CBOR Working Group (cbor@ietf.org) 또는 IETF Applications and Real-Time Area (art@ietf.org)¶

의도된 사용:

COMMON¶

사용 제한:

없음¶

저자:

IETF CBOR Working Group (cbor@ietf.org)¶

변경 관리 주체:

The IESG (iesg@ietf.org)¶

9.4. CoAP Content-Format 레지스트리

CBOR용 CoAP Content-Format은 "Constrained RESTful Environments (CoRE) Parameters" 레지스트리 [IANA.core-parameters] 내의 "CoAP Content-Formats" 하위 레지스트리에 등록되었다:¶

미디어 타입:

application/cbor¶

인코딩:

-¶

ID:

60¶

참조:

RFC 8949¶

9.5. 구조화 구문 접미사 레지스트리

단일 인코딩된 CBOR 데이터 항목을 기반으로 하는 미디어 타입에 대한 구조화 구문 접미사 [RFC6838]는 +cbor이며, IANA는 이를 "Structured Syntax Suffixes" 레지스트리 [IANA.structured-suffix]에 등록했다:¶

이름:

간결한 이진 객체 표현 (CBOR)¶

+접미사:

+cbor¶

참조:

RFC 8949¶

인코딩 고려 사항:

CBOR는 이진 형식이다.¶

상호 운용성 고려 사항:

n/a¶

프래그먼트 식별자 고려 사항:

+cbor에 대해 지정된 프래그먼트 식별자의 구문과 의미는 "application/cbor"에 대해 지정된 것과 같아야 SHOULD 한다. (RFC 8949 출판 시점에는 "application/cbor"에 대해 정의된 프래그먼트 식별 구문이 없다.)¶

특정 "xxx/yyy+cbor"에 대한 프래그먼트 식별자의 구문과 의미는 다음과 같이 처리되어야 SHOULD 한다:¶

• +cbor에 정의된 경우로, 프래그먼트 식별자가 +cbor 규칙에 따라 해소되면, +cbor에 지정된 대로 처리한다.¶
• +cbor에 정의된 경우로, 프래그먼트 식별자가 +cbor 규칙에 따라 해소되지 않으면, "xxx/yyy+cbor"에 지정된 대로 처리한다.¶
• +cbor에 정의되지 않은 경우에는 "xxx/yyy+cbor"에 지정된 대로 처리한다.¶

보안 고려 사항:

RFC 8949의 섹션 10 참조.¶

연락처:

IETF CBOR Working Group (cbor@ietf.org) 또는 IETF Applications and Real-Time Area (art@ietf.org)¶

저자/변경 관리 주체:

IETF¶

E.1. ASN.1 DER, BER 및 PER

[ASN.1]은 많은 직렬화를 가진다. IETF에서는 DER 및 BER이 가장 일반적이다. 직렬화된 출력은 많은 항목에 대해 특별히 간결하지 않으며, 숫자 항목을 디코딩하는 데 필요한 코드는 제약 장치에서 복잡할 수 있다.¶

IETF 프로토콜 중 Packed Encoding Rules(PER)의 여러 변형 중 하나를 채택한 것은 거의 없다(있더라도). 여기에는 여러 이유가 있을 수 있지만, 흔히 언급되는 이유 중 하나는 PER이 데이터 항목의 표면 구조를 구문 분석하는 데에도 스키마를 사용하여 상당한 도구 지원을 요구한다는 것이다. 사용 중인 ASN.1 스키마 언어에는 서로 다른 버전도 있어, 이는 채택을 저해하기도 했다.¶

E.2. MessagePack

[MessagePack]은 CBOR와 여러 속성에서 유사한, 간결하고 널리 구현된 카운트 기반 이진 직렬화 형식이지만, 다소 덜 규칙적이다. 데이터 모델은 JSON 데이터를 표현하는 데 사용할 수 있지만, MessagePack은 많은 원격 프로시저 호출(RPC) 애플리케이션과 데이터의 장기 저장에도 사용되어 왔다.¶

MessagePack은 2011년경 처음 공개된 이후 본질적으로 안정적이었으며, 아직 전환을 겪지 않았다. MessagePack의 발전은 기존 저장 데이터와의 완전한 하위 호환성을 유지해야 한다는 명령에 의해 저해되며, 확장에 사용할 수 있는 바이트코드는 거의 남아 있지 않다. 인코딩에서 이진 문자열과 텍스트 문자열을 분리하라는 MessagePack 사용자 커뮤니티의 수년간 반복된 요청은 최근 MessagePack의 "raw" 데이터를 이진 데이터와 텍스트 데이터에 대한 용도 사이에서 모호하게 남겨 두는 확장 제안으로 이어졌다. MessagePack의 확장 메커니즘은 여전히 불명확하다.¶

E.3. BSON

[BSON]은 MongoDB 데이터베이스에서 JSON 유사 맵(JSON 객체)을 저장하기 위해 개발된 데이터 형식이다. 주요한 구별 특징은 제자리 업데이트 기능이며, 이는 간결한 표현을 방해한다. BSON은 맵 키를 제외하고는 카운트 기반 표현을 사용하며, 맵 키는 널 바이트로 종료된다. BSON은 전송선상에서 JSON 유사 객체를 표현하는 데 사용할 수 있지만, 그 명세는 데이터베이스 애플리케이션의 요구 사항이 지배하며 다소 바로크식이 되었다. BSON 확장이 어떻게 구현될지의 상태는 여전히 불명확하다.¶

E.4. MSDTP: RFC 713

Message Services Data Transmission(MSDTP)은 간결한 메시지 형식의 매우 이른 예이며, 1976년에 작성된 [RFC0713]에 설명되어 있다. 이는 역사적 가치 때문에 여기에 포함되었으며, 널리 사용된 적이 있어서가 아니다.¶

E.5. 전송선상의 간결성

인코더와 디코더의 코드 간결성이라는 CBOR의 설계 목표가 전송선상의 간결성이라는 목표보다 더 높은 우선순위이지만, 많은 사람은 전송 크기에 주목한다. 표 8은 단순한 중첩 배열 [1, [2, 3]]에 대한 몇 가지 인코딩 예를 보여 준다. 인코딩에서 어떤 형태의 부정 길이 인코딩을 지원하는 경우, [_ 1, [2, 3]](외부 배열의 부정 길이)도 표시되어 있다.¶

F.1. 올바른 형식이 아닌 CBOR 데이터 항목의 예

이 하위 섹션은 올바른 형식이 아닌 CBOR 데이터 항목에 대한 몇 가지 예를 보여 준다. 각 예는 바이트 시퀀스이며, 각 바이트는 16진수로 표시된다. 목록의 여러 예는 쉼표로 구분된다.¶

올바른 형식 오류 종류 1(데이터가 너무 많음)의 예는 올바른 형식으로 인코딩된 CBOR 데이터 항목에 데이터를 추가하여 쉽게 만들 수 있다.¶

마찬가지로, 올바른 형식 오류 종류 2(데이터가 너무 적음)의 예는 올바른 형식으로 인코딩된 CBOR 데이터 항목을 잘라서 만들 수 있다. 테스트 모음에서는 완료되기 위해 많은 양의 추가가 필요한 불완전한 데이터 항목으로 구체적으로 테스트하는 것이 유익할 수 있다 (예를 들어 매우 큰 크기의 문자열 인코딩을 시작하는 방식).¶

입력의 조기 종료는 헤드에서 또는 포함된 데이터 안에서 발생할 수 있다. 그 데이터는 단순 문자열이거나, 카운트되거나 "break" 정지 코드로 끝났어야 하는 포함 데이터 항목일 수 있다.¶

헤드에서 입력 종료:

18, 19, 1a, 1b, 19 01, 1a 01 02, 1b 01 02 03 04 05 06 07, 38, 58, 78, 98, 9a 01 ff 00, b8, d8, f8, f9 00, fa 00 00, fb 00 00 00¶

데이터가 짧은 정길이 문자열:

41, 61, 5a ff ff ff ff 00, 5b ff ff ff ff ff ff ff ff 01 02 03, 7a ff ff ff ff 00, 7b 7f ff ff ff ff ff ff ff 01 02 03¶

충분한 항목으로 닫히지 않은 정길이 맵 및 배열:

81, 81 81 81 81 81 81 81 81 81, 82 00, a1, a2 01 02, a1 00, a2 00 00 00¶

태그 번호 뒤에 태그 내용이 오지 않음:

c0¶

"break" 정지 코드로 닫히지 않은 부정 길이 문자열:

5f 41 00, 7f 61 00¶

"break" 정지 코드로 닫히지 않은 부정 길이 맵 및 배열:

9f, 9f 01 02, bf, bf 01 02 01 02, 81 9f, 9f 80 00, 9f 9f 9f 9f 9f ff ff ff ff, 9f 81 9f 81 9f 9f ff ff ff¶

올바른 형식 오류 종류 3(구문 오류)의 다섯 하위 종류에 대한 몇 가지 예는 아래에 표시되어 있다.¶

하위 종류 1:

예약된 추가 정보 값:

1c, 1d, 1e, 3c, 3d, 3e, 5c, 5d, 5e, 7c, 7d, 7e, 9c, 9d, 9e, bc, bd, be, dc, dd, de, fc, fd, fe,¶

하위 종류 2:

단순 값의 예약된 2바이트 인코딩:

f8 00, f8 01, f8 18, f8 1f¶

하위 종류 3:

올바른 타입이 아닌 부정 길이 문자열 청크:

5f 00 ff, 5f 21 ff, 5f 61 00 ff, 5f 80 ff, 5f a0 ff, 5f c0 00 ff, 5f e0 ff, 7f 41 00 ff¶

정길이가 아닌 부정 길이 문자열 청크:

5f 5f 41 00 ff ff, 7f 7f 61 00 ff ff¶

하위 종류 4:

부정 길이 항목 밖에서 단독으로 발생하는 Break:

ff¶

정길이 배열, 맵 또는 태그 안에서 발생하는 Break:

81 ff, 82 00 ff, a1 ff, a1 ff 00, a1 00 ff, a2 00 00 ff, 9f 81 ff, 9f 82 9f 81 9f 9f ff ff ff ff¶

항목 수가 홀수가 되게 하는 부정 길이 맵 안의 Break (값 위치의 break):

bf 00 ff, bf 00 00 00 ff¶

하위 종류 5:

추가 정보 31을 가진 주요 타입 0, 1, 6:

1f, 3f, df¶

G.1. 정오표 처리 및 사무적 변경 사항

RFC 7049의 검증된 두 정오표, [Err3764] 및 [Err3770]는 본문에 있는 두 인코딩 예와 관련되어 있었고, 이는 수정되었다 (섹션 3.4.3: "29" -> "49", 섹션 5.5: "0b000_11101" -> "0b000_11001"). 또한 RFC 7049에는 단순 값에 대해 수치 값 24를 사용하는 예 [Err5917]가 포함되어 있었는데, 이는 올바른 형식이 아니므로 이 예는 제거되었다. 정오표 보고서 5763 [Err5763]은 태그 정의 문구의 오류를 지적했으며, 이는 섹션 3.4를 다시 작성하는 과정에서 해결되었다. 정오표 보고서 5434 [Err5434]는 부록 E의 Universal Binary JSON (UBJSON) 예가 정오표 보고서 제출 당시의 최신 UBJSON 버전을 더 이상 준수하지 않는다고 지적했다. 2013년 이후 UBJSON 명세가 완전히 변경된 것으로 밝혀졌으므로 이 예는 제거되었다. 다른 정오표 보고서 [Err4409] [Err4963] [Err4964]는 정규 인코딩의 맵 키 정렬 규칙이 부담스럽다고 불평했으며, 이는 정규 인코딩 제안을 재검토하고 결정적 인코딩 제안 (아래 설명)으로 대체하는 결과를 낳았다. 정오표 보고서 4294의 편집상 제안 [Err4294]도 구현되었다(섹션 3.2.2의 마지막 예에 있는 주석에 "Second value"를 추가하여 대칭성을 개선).¶

그 밖의 사무적 변경 사항에는 다음이 포함된다.¶

• 새 xml2rfc 기능 [RFC7991]의 사용;¶
• 사용된 표기법에 대한 더 많은 설명;¶
• 참고 문헌의 갱신, 예를 들어 RFC 4627에서 [RFC8259]로, CNN-TERMS에서 [RFC7228]로, 그리고 [ECMA262]의 5.1판에서 제11판으로의 갱신; [IEEE754]에 대한 참조 추가 및 필요한 정의의 가져오기; [C] 및 [Cplusplus20]에 대한 참조 추가; 그리고 부록 E의 논의를 더 자세히 보여 주는 [RFC8618]에 대한 참조 추가;¶
• 진단 표기법에 대한 논의(섹션 8)에서, [RFC8610]에 정의된 "Extended Diagnostic Notation"(EDN)이 이제 언급되고, NaN 페이로드 표현의 공백이 이제 강조되며, 청크가 없는 부정 길이 문자열을 표현하는 설명이 추가되었다 (섹션 8.1);¶
• 이 부록의 추가.¶

G.2. IANA 고려 사항의 변경 사항

IANA 고려 사항은 일반적으로 갱신되었다(예: 이제 명세의 저자로 CBOR Working Group을 가리키는 등의 사무적 변경). 각각의 IANA 레지스트리에 대한 참조가 정보 참고 문헌에 추가되었다.¶

"Concise Binary Object Representation (CBOR) Tags" 레지스트리 [IANA.cbor-tags]에서, 256부터 32767까지의 공간("1+2"의 하위 절반)에 있는 태그는 더 이상 First Come First Served로 할당되지 않는다. 이 범위는 이제 Specification Required이다.¶

G.3. 제안 및 기타 정보 구성 요소의 변경 사항

문서를 개정하면서, 정오표 보고서 처리 외에도, 작업 그룹은 다양한 애플리케이션 집합에서 CBOR를 사용한 거의 7년간의 경험을 활용했다. 이는 설명을 위한 표 추가를 포함한 여러 편집상 변경으로 이어졌지만, 또한 일부 측면을 강조하고 다른 측면을 덜 강조하는 결과도 낳았다.¶

중요한 추가 사항은 CBOR 데이터 모델과 CBOR 처리에 관여하는 그 작은 변형들을 논의하는 섹션 2이다. 이러한 변형(기본 일반, 확장 일반, 특정)에 대한 용어 도입은 문서의 다른 곳에서 더 간결한 언어를 가능하게 하고, 구현에 대한 기대와 형식의 확장성 기능을 명확히 하는 데도 도움이 된다.¶

JSON 생태계에서 파생된 형식으로서, RFC 7049는 당시 JavaScript에서 물려받은 JSON 숫자 시스템의 영향을 받았다. JSON은 정수와 부동소수점 값을 구별하여 제공하지 않는다 (그리고 후자는 형식에서 십진수이다). CBOR는 숫자의 이진 표현을 제공하며, 이는 정수와 부동소수점 값 사이에서 서로 다르다. 구현 및 사용 경험은 이 두 숫자 영역 사이의 분리를 문서에서 더 명확히 해야 함을 시사했다. 정수가 부동소수점 값을 매끄럽게 대신할 수 있음을 암시하는 문구는 제거되었다. 또한 JSON을 CBOR로 변환할 때 이러한 타입을 처리하기 위한 제안 (I-JSON [RFC7493] 기반)이 추가되었고, 특정 반올림 메커니즘의 사용이 권장되었다.¶

데이터 모델의 단일 값에 대해, CBOR는 종종 여러 인코딩 선택지를 제공한다. 새 섹션(섹션 4)은 "선호 직렬화"(섹션 4.1)라는 용어를 도입하고 다양한 종류의 데이터 항목에 대해 이를 정의한다. 이 용어를 바탕으로, 그 섹션은 CBOR 기반 프로토콜이 RFC 7049의 "canonical" 및 "canonicalization"이라는 용어를 피하면서 "결정적 인코딩"(섹션 4.2)을 정의할 수 있는 방법을 논의한다. "Core Deterministic Encoding Requirements"(섹션 4.2.1)의 제안은 그러한 프로토콜 정의 인코딩 요구 사항에 대한 일반 지원을 가능하게 한다. 이 문서는 RFC 7049에서 제안한 맵 정렬을 인코딩된 키의 단순한 사전식 정렬로 단순화하여 결정적 인코딩 구현을 더욱 쉽게 한다. 이전 제안의 설명은 이제 "길이 우선 맵 키 정렬"(섹션 4.2.3)이라고 불리는 대안으로 유지된다.¶

올바른 형식 및 유효한 데이터에 대한 용어가 다듬어지고 더 엄격하게 사용되었으며, 예 밖에서는 "syntax error", "decoding error", "strict mode"와 같은 덜 잘 정의된 대체 용어를 피했다. 또한 CBOR 수준의 유효성을 넘어 애플리케이션이 입력 데이터에 대해 갖는 세 번째 요구 수준이 이제 명시적으로 언급된다. 올바른 형식(전혀 처리 가능), 유효함 (유효성 검사 일반 디코더가 검사), 예상 입력 (애플리케이션이 검사)은 수용 가능성 계층의 위계로 다루어진다.¶

올바른 형식이 아닌 단순 값의 처리는 본문과 의사 코드에서 명확해졌다. 부록 F가 추가되어 올바른 형식 오류를 논의하고 그 예를 제공한다. 의사 코드는 더 이식 가능하도록 갱신되었으며, 몇 가지 이식성 고려 사항도 추가되었다.¶

유효성에 대한 논의는 두 영역에서 더 명확해졌다. 맵 유효성(중복 키 처리)이 명확해졌고, 특정 구현 선택의 적용 범위가 설명되었다. 또한 태그, 태그 번호 및 태그 내용에 대한 용어를 간소화하면서, 태그 유효성에 대한 논의가 추가되었고, 태그 내용에 대한 제한이 일반적으로 그리고 태그 1에 대해 구체적으로 명확해졌다.¶

직렬화 순서에 의존하는 의미를 가진 태그를 정의하는 것에 대한 구현 참고(및 향후 태그 정의를 위한 참고)가 섹션 3.4에 추가되었다.¶

태그 35는 이 문서에서 정의되지 않는다. RFC 7049의 정의에 기반한 등록은 그대로 유지된다.¶

"인수"와 "헤드"에 대한 용어가 섹션 3에 도입되어, 이후 논의를 단순화했다.¶

보안 고려 사항(섹션 10)은 대부분 다시 작성되고 크게 확장되었다. 문서의 여러 다른 곳에서도 디코더가 올바른 형식 오류를 단순히 용인할 수 없음을 이제 더 명시적으로 밝힌다.¶