📄 rfc971.txt
字号:
destination host to avoid passing around data that does not conform to the local word boundaries. Another advantage is that it provides flexibility for future expansion. Since the overall length is a part of the type definition, it allows a host to deal with or ignore data of types that it does not necessarily understand. Since the interpretation of the data is not dependent on its position, message fields (or parameters) can be reordered, or optionally omitted. The disadvantages of this approach are as follows. Assuming that no field could be omitted, the external representation of the message may be longer than it would have been if an implicit representation had been used. In addition, extra time may be consumed by the conversion between external format and local format, since the external format almost certainly will not match the local format for any of the participants.DeSchon [Page 5]RFC 971 January 1986A Survey of Data Representation Standards4. Data Representation Standards Scorecard The following table is a comparison of the data elements defined for the various standards being discussed. It is provided in order to give a general idea of the types defined for each standard, but it should be noted that the grouping of these types does not indicate one type corresponds exactly to any other. Where it is applicable, the identifier code appears in parantheses following the name of the data element. Under "NUMBER", "S" stands for signed, "U" stands for unsigned, "V" stands for variable, and the number represents the number of bits. For example, "Integer S16" means a "signed 16-bit integer". Type CCITT MMM NBS XEROX Sun ----------------------------------------------------------------------- END | End-of- | ENDLIST | End-of- | -- | -- | Contents | (11) | Constructor| | | (0) | | (1) | | | | | | | PAD | Null (5) | NOP (0) | No-Op (0) | -- | -- | | PAD (1) | Padding | | | | | (33) | | | | | | | RECORD | Set (17) | PROPLIST | Set (11) | -- | -- | | (14) | | | | Sequence | LIST (9) | Sequence | Sequence | Structure | (16) | | (10) | | | | | | Record | | | | Message | | | | | (77) | | | -- | -- | -- | Array | Fixed Array | | | | | Counted Array | "Choice" | -- | -- | Choice |Discriminated- | "Any" | | | | Union | | | | | | "Tagged" | "name" | Field (76) | -- | -- | | |Unique-ID(9)| | | -- | SHARE-TAG | -- | -- | -- | | (12) | | | | | SHARE-REF | | | | | (13) | | | | | | | | | -- | -- | Compressed | -- | -- | | | (70) | | | -- | ENCRYPT | Encrypted | -- | -- | | (14) | (71) | |DeSchon [Page 6]RFC 971 January 1986A Survey of Data Representation Standards Type CCITT MMM NBS XEROX Sun ----------------------------------------------------------------------- BOOLEAN| Boolean(1)| BOOLEAN(2)| Boolean(8) | Boolean | Boolean | | | | | NUMBER | Integer(2)| EPI (5) | Integer(32)| Integer | Integer | SV | SV | SV | S16 | S32 | | INDEX (3) | | Cardinal | Unsigned Int | | U16 | | U16 | U32 | | INTEGER(4)| |Unspecified|Enumeration | | S32 | | 16 | 32 | | | | Long Int |Hyper Integer | | | | S32 | S64 | | | | Long Card |Uns Hyper Int | | | | U32 | U64 | | | | | Double Prec | | | | | 64 | -- | FLOAT (15)| -- | -- | Float Pt | | 64 | | | 32 | | | | | BIT- | Bit String| BITSTR(6) | Bit-String | -- | -- STRING| (3) | | (67) | | | Octet- | -- | -- | -- | Opaque | String(4)| | | | | | | | | STRING | IA5 (22) | TEXT (8) | ASCII- | String | Counted- | | | String (2)| | Byte String | | NAME (7) | | | | Numeric | | | | | (18) | | | | | Printable | | | | | (19) | | | | | T.61 (20) | | | | | Videotex | | | | | (21) | | | |DeSchon [Page 7]RFC 971 January 1986A Survey of Data Representation Standards Type CCITT MMM NBS XEROX Sun ----------------------------------------------------------------------- OTHER | UTC Time | -- | Date (40) | -- | -- | (23) | | | | | Gen Time | | | | | (24) | | | | | -- | -- | Property- | -- | -- | | | List (36)| | | -- | -- |Property(69)| -- | -- | | | | | | -- | -- | -- | Procedure | -- | | | | | | -- | -- | Vendor- | -- | -- | | | Defined | | | | | (127) | | | | | Extension | | | | | (126) | |5. Conclusions Of the standards discussed in this survey, the CCITT approach (X.409) has already gained wide acceptance. For a system that will include a number of dissimilar hosts, as might be the case for an Internet application, a standard that employs explicit representation, such as the CCITT X.409, would probably work well. Using the CCITT X.409 standard it is possible to construct most of the data elements that are specified for the other standards, with the possible exception of the "floating point" type. However, some of the flexibility that has been built into this standard, such as the "private-use class" may lead to ambiguity and a lack of coordination between implementors at different sites. If a standard such as the CCITT were to be used in an Internet experiment a fully defined (but large) subset would probably have to be selected.DeSchon [Page 8]RFC 971 January 1986A Survey of Data Representation Standards6. References [1] "Message Handling Systems: Presentation Transfer Syntax and Notation", Recommendation X.409, Document AP VIII-66-E, International Telegraph and Telephone Consultative Committee (CCITT), Malaga-Torremolinos, June, 1984. [2] J. Garcia-Luna, A. Poggio, and D. Elliot, "Research into Multimedia Message System Architecture", SRI International, February, 1984. [3] "Specification for Message Format for Computer Based Message Systems", FIPS Pub 98 (also published as RFC 841), National Bureau of Standards, January, 1983. [4] J. Postel, "Internet Multimedia Mail Transfer Protocol", USC Information Sciences Institute, MMM-11 (RFC-759 revised), March, 1982. [5] J. Postel, "Internet Multimedia Mail Document Format", USC Information Sciences Institute, MMM-12 (RFC-767 revised), March, 1982. [6] "Extended Data Representation Reference Manual", SUN Microsystems, September, 1984. [7] "Courier: The Remote Procedure Call Protocol", XSIS-038112, XEROX Corporation, December, 1981.DeSchon [Page 9]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -