1200 OCTET STRING encoding
- Created
- 06 Jan 2014
- Status
- In Force (green)Closed: the solution is part of the standard. No further comments are taken. Show the workflow
- Part
- Part 6 (2009-12; Edition 2)
- Links
- None
- Page
- 99
- Clause
- 9.5.4.1
- Paragraph
- Table 45-OCTET STRING
- Category
- No impact on this part
Issue
Coding of OCTET STRING in <Val> elements is difficult to use as XML base64Binary. A much more human-readable form would be XML hexBinary.
In hexBinary, an 8-octet zero string would be "0000000000000000" which is much easier to read than "AAAAAAAAAAA="
Proposal
Change Table 45 row OCTET STRING from "base64Binary" to "hexBinary"
| Discussion | Created |
|---|---|
| In Force (green) Not accepted, reason in comment below. | 27 Feb 14 |
| Discussion (red) I disagree with the proposal. Base64 is a standard XML encoding for octett strings. Octett strings per nature are machine readable and not human readable, thus a more efficient coding is preferable. Further, allowing now a second format would introduce a lot of interoperability problems with Edition 1. | 23 Jan 14 |
|
Discussion (red)
I disagree with the proposal.
As Chris mentioned, Octet String are use for identifier: orIdent, orignatorID and addr. The value shall not be limited to hexadecimal values [0-9a-fA-F], but shall allow asci characters. base64Binary is the format to use. According to w3C: The lexical forms of base64Binary values are limited to the 65 characters of the Base64 Alphabet defined in [RFC 2045], i.e., a-z, A-Z, 0-9, the plus sign (+), the forward slash (/) and the equal sign (=), together with the characters defined in [XML 1.0 (Second Edition)] as white space. No other characters are allowed. |
20 Jan 14 |
|
Discussion (red)
Currently OCTET STRING is only used in 7-3 and 7-2 in the following places:
- Originator.orIdent (which is an ST or an MX) - SEC.addr [ST] - CST.originatorID [SR] None of these should be in an SCL file as their value should come from the process. Thus any change here does not affect compatibility in practice. Now I do not have a clear opinion on which should be used. Note: there only two real differences between the two: - The radix. Base64 is base-64, surprise, and hex is base-16. - The encoding: base-64 encodes 3 source bytes into 4 base-64 characters (http://en.wikipedia.org/wiki/Base64#Examples); hex encodes 1 byte into 2 hex characters. So base64 is more compact than hex. Hope this helps others to decide... |
13 Jan 14 |