First, we have had much debate about whether parameter-names should be
integers or text. Most of us still prefer the text solution. Some of
the reasons I have heard expressed are that text names seem to offer a
better path for extension and text names make debugging easier. I hope
that this issue is closed and doesn't get re-opened again.
Note, we re-introduced the notion of enums into the model so that we
could distinguish between those names that should be encoded as text
and those that should be encoded as integers. We chose to keep
attribute/ parameter names as keywords.
Second, we are overloading the length field by using negative lengths.
They have a similar function to your flag byte. We could have a flag byte
just before each name-length field, but I not sure what we would gain.
The following is the correspondence between the special IPP lengths and
IPDS flags:
IPP length IPDS flag
> 0 no flags
0 0b00000001 - this is a repeating parameter
Roger, is this for 2 through n as in IPP or 1 through n?
-1 0b00000010 - this is the last parameter
-2 no such concept in IPDS
Note, for IPP, -1 follows the last parameter, but for IPDS it is within
the last parameter. (Did I understand this correctly Roger?)
I actually think that the code for generating and parsing IPP is simpler
because the special ending marks (the negative numbers) occur after
a parameter rather than within a parameter, so the parameter logic
does not have to deal with end-of-parameter logic.
If we were to add the concept of a flag-byte, then I think that it should
precede the 2-byte name-length field and we would support the following
values:
o normal -- name-value pair follows
o another value -- value follows without a name because it is
part of a multi-valued parameter
o parameters end -- data follows
o parameter-group ends -- another parameter group follows
These four cases are the same as those described in the IPP/IPDS table
above and correspond to the name-lengths of >0, 0, -1 and -2.
Although we may want to do some minor tweaking, I think that we should
stay with something very close to what we agreed to in Nashua. I think
that we are at a point of uneasy equilibrium in group. Everyone or
nearly everyone is reasonably happy with our solution. Many have
certain parts they don't like, but are willing to live with those
parts. If we change too much of this agreement, we may again find many
who don't like enough of the solution to back it, and we'll be back to
square one.
I will fix the language in the protocol document so that the overloading
concept is clearer.
Bob Herriot
> From rdebry@VNET.IBM.COM Tue Jul 8 08:27:22 1997
>
> 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!
>
>