Subject: IPP>MOD - coding mechanism for parameters

From: "deBry, Roger K." <[email-masked]>
Date: Tue, 8 Jul 97 09:09:29 MDT

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!

---

From: [email-masked] (Robert Herriot)
Date: Tue, 8 Jul 1997 13:49:40 -0700

I agree that the IPDS triplets and the proposed IPP encoding have some
similarities, but they also have some differences that have led to
the encoding we have selected.

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 [email-masked] Tue Jul  8 08:27:22 1997
>

---

From: JK Martin <[email-masked]>
Date: Tue, 8 Jul 1997 20:08:14 -0400 (EDT)

Bob Herriot has made an excellent observation that should really

> who don't like enough of the solution to back it, and we'll be back to

For those who were able to attend the Nashua meetings, you know exactly
what Bob is talking about here.

For those unable to attend those meetings--but have been actively
participating on the IPP list all along--then you would quickly
understand how easy it would be for IPP to "be back to square one"
if we start rocking the boat at this point.

The meetings in Nashua produced the first real agreement between
IPP and SWP camps.  Anything that might jeopardize that agreement
should be absolutely compelling, and not just a "tweak", IMHO.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------