My normal mail system is down this morning, so I'm sending this from (groan)
PROFS on the mainframe. I have read through Bob's new document. I apologize
for not being in on the discussions in Nashua. It looks like a great deal
of progress was made. However, looking at Bob's document and Sylvan's recent
email on this subject, I would like to make a proposal.
As you recall, I mentioned the notion of "triplets" that we use in IPDS. We
also have used the notion of reserved code points for implementation specific
function outside of the standard. Based on these ideas, I'd suggest the
following scheme:
parameter = length ID flag-byte parameter-value
- length is a two byte field, defines the length of the triplet
- ID is a 6 byte field, defined as follows:
- 0x000000 through 0x00FFFF are standard defined parameters
- 0x010000 through 0x0FFFFF are reserved for implementation
specific extensions
- 0x100000 through 0xFFFFFF are reserved for installation
specific extensions
- flag-byte
- 0b00000001 - this is a repeating parameter
- 0b00000010 - this is the last parameter
- parameter-value is as defined in Bob's document
This encoding scheme has been used in IPDS for over ten years and we have
not run into any implementation or extension issues. It provides simple fixed
length parameter identifiers to trigger processing on the server side, it does
not depend upon delimiters (I guess you could claim that the flag-bytes are
sort of delimiters, but the parsing rules are simpler since every parameter
has a flag byte. The flags I've shown provde the same function as Bob's
x'FF' and x'FE'. Actually, in IPDS we encapsulate repeating parameters or
parameter groups in another triplet outside of the group, but It does require
a little more processing to keep track of outer lengths.
I know that it is always hard to back away from an agreement that has been
hammered out over much sweat and tears, but I do think this approach is
significantly easier to understand and to implement (I had to read Bob's
document several times to understand his use of unusual "length" fields.
Such overloading of length fields makes the encoding difficult
to understand).
I'd appreciate some debate on this issue. I know everyone wants to close on
this issue and move on, but let's be sure we have the best possible solution!