1200   OCTET STRING encoding

Created: 06 Jan 2014

Status: In Force (green)

Part: Part 6 (2009-12; Edition 2)

Links:

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 Status
Not accepted, reason in comment below. 27 Feb 14 In Force (green)
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 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 21.10.16.1