16、在類型定義和信息對象集中使用擴展標記有什么區別?擴展標記是否不可見?
擴展標記就類型定義而言是不可見的,但就簡單表約束和組件關系約束而言并非不可見。
類型本身是可擴展的,與限制它是可擴展的對象集之間是有區別的。在類型是可擴展的情況下,它天生可以采用可擴展約束允許的任何值。例如,
INTEGER(1..8, ...)
可以隨時假設任何有效值。將此與使用簡單表約束進行約束的 INTEGER類型進行對比,在這種類型中,此類類型只能假定在該類型被編碼/解碼時恰好包含在信息對象集中的那些值。隨著程序的運行,這可能會隨著時間的推移而變化,因為可擴展信息對象集中的對象集可能會在運行時發生變化。
在BER、DER和 CER的情況下,這種區別不太重要,其中類型的可擴展性在其編碼方式中不發揮作用,但在PER 中起主要作用。在 PER 中,使用擴展標記“...”定義的類型的值使用1 位前綴進行編碼,當設置為0 時,意味著后面的值在擴展根中,因此以優化的形式編碼。(例如,上面示例中的值 1-8 將被編碼為3 位)。但是,當設置為 1 時,意味著后面的值以更通用的形式編碼。(例如,上例中不在 1-8 范圍內的值占用16 位或更多位)。
17、你能解釋一下類型可擴展性在PER 中是如何工作的嗎?
考慮以下兩個ASN.1 語法定義:
A::= SEQUENCE { --defined in v1
f1BOOLEAN,
f2BOOLEAN,
...,
}
A::= SEQUENCE { --defined in v2
f1BOOLEAN,
f2BOOLEAN,
...,
e1BOOLEAN OPTIONAL,
e2BOOLEAN
}
類型可擴展性背后的目的是允許不理解新字段的V1 應用程序接收具有它無法識別的字段的V2 消息,并將它們視為由V1 應用程序發送,同樣,對于V2 應用程序來說接收缺少字段的 V1 消息。如果 V2 應用程序收到缺少強制擴展添加的消息,它可以安全地假定該消息是由V1 應用程序發起的。
只有在擴展附加位圖中有一個位表示存在/不存在哪些擴展附加值時,才必須對擴展標記之后的強制字段進行編碼。因此,在強制擴展附加 y 之后定義了擴展附加x,并且 x的值存在于編碼中,那么y 的值必須存在。此外,如果強制擴展附加 y 是SEQUENCE 中的最后一個組件,并且在擴展附加位圖中存在一個位,則該位必須設置為1,因為該位的存在表明消息的發起者知道這個擴展添加,因此它的存在是強制性的。只有當消息是從未定義強制擴展添加的早期版本的消息定義中繼時,才可以省略它(在這種情況下,擴展添加位圖中將沒有位)。ITU-T 建議X.680(2008) 25.15 注2 中指出了這一點:
作為擴展添加但不包含在“ExtensionAdditionGroup”中的“ComponentType”如果未標記為OPTIONAL 或DEFAULT,則應始終對其進行編碼,除非抽象值是從使用較早版本抽象語法的發送者中繼的其中未定義“ComponentType”。
換句話說,PER將標記為 OPTIONAL的擴展添加與非 OPTIONAL的擴展添加完全相同。
審核編輯:劉清
-
編碼
+關注
關注
6文章
946瀏覽量
54869 -
CeR
+關注
關注
0文章
4瀏覽量
7278
原文標題:?OSS Nokalva:ASN.1問答時間(4)
文章出處:【微信號:哲想軟件,微信公眾號:哲想軟件】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論