Subject: IPP>PRO proposed tweak to protocol

From: [email-masked] (Robert Herriot)
Date: Wed, 9 Jul 1997 19:32:08 -0700

In today's meeting we decided to propose one last small tweak to the
IPP protocol.  We decided that I would send out this proposal for all
of you to read and comment on.

I think that it is an improvement. I hope that you will agree.

We are proposing the addition of a one byte tag in front of each
parameter.  With this change, we eliminate the need for the special
negative lengths for both names and values.  We also add the ability to
specify the type of parameter/attribute values so that a value can
be decoded and stored independently of the parameter/attribute name.  Both
of these seem like positive changes.

The tag serves the following functions:
   o it marks the beginning of:
         o the parameter section
         o any attribute section
         o the data section
   o it specifies that a parameter/attribute value is a special 
        'out-of-band' value, e.g. unsupported
   o it specifies the type of a parameter/attribute value, e.g. integer.

The rules for encoding and decoding remain nearly the same.  The cost
of the 1 extra byte per parameter/attribute is minimal.

This change is explained in detail below by including what the syntax section
would look like if this proposal were approved.

Please email comments to [email-masked] by Friday 7/9 afternoon.  

Thanks.

Bob Herriot

The new text for the protocol document follows:

---------------------------------------------------------------

 1. Encoding of  the Operation Layer

 The operation layer SHALL contain a single operation request or
 operation response.

 The encoding is defined using both a diagram and Augmented Backus-Naur
 Form (ABNF), as specified by draft-ietf-drums-abnf-02.txt [29] except
 that `strings of literals' SHALL be case sensitive. For example `A'
 means upper-case  `A' and not lower case `a'.   In addition, two-byte
 binary signed integer fields are represented as `%x' values which show
 their range of values.

 All binary integers in this encoding SHALL be transmitted in big-endian
 format (also known as 'network order' and 'most significant byte first')

 1.1 Syntax of Encoding

 The encoding consists of:

   .  version
   .  operation (for a request) or status (for a response)
   .  parameter-tag
   .  parameter-sequence
   .  attribute-tag
   .  attribute-sequence
   .  data-tag
   .  data (absent for some operations)

 The parameter-sequence consists of  a sequence of one or more
 parameters. The attributes-sequence consists of  a sequence of one or
 more attributes. Each parameter or attribute consists of:

   .  value-tag: a one byte value that specifies the type of the value,
         e.g. integer.
   .  name-length: a two byte binary integer which is the length of the
         following `name'
   .  name
   .  value-length: a two byte binary integer which is the length of the
         following `value'
   .  value

 A   name-length of 0 has a special meaning.

 The parameter-tag and parameter-sequence may be omitted if the operation
 has no parameters. The attribute-tag and attribute-sequence may be
 omitted if the operation has no attributes or it may be replicated for
 an operation that contains attributes for multiple objects. The data-tag
 is present even when the data is omitted.

 A  name-length of 0 has a special meaning and denotes an additional
 value for the preceding parameter or attribute. The following name is
 empty. That is, the  `value-length' starts in the next octet. A sequence
 

 of parameters or attribures where all but the first have a name-length
 of 0 is called a compound-parameter or compound-attribute, respectively.

 From the standpoint of a parsing loop, the encoding consists of:

   .  version
   .  operation (for a request) or status (for a response)
   .  zero or more:
      . tag
      . empty, parameter, or attribute
   .  data-tag
   .  data (which is optional)

 The value of the tag determines whether the bytes following the tag are:

   .  parameters
   .  attributes
   .  data
   .  a single parameter where the tag specifies the type of the value.

 The syntax for the operation layer below shows the structure created by
 the 3 special `name-length' values described above.
 

   ipp-message = ipp-request / ipp-response
   ipp-request = version operation parameter-sequence attribute-sequence
            DATA-TAG [ data ]
   ipp-response = version status parameter-sequence attribute-sequence
            DATA-TAG[ data ]
   version = major-version minor-version
   major-version = SIGNED-BYTE  ; initially %d1
   minor-version = SIGNED-BYTE  ; initially %d0
   operation = SIGNED-SHORT  ; mapping from model defined below
   status = SIGNED-SHORT     ; mapping from model defined below
   parameter-sequence = [PARAMETER-TAG  *compound-parameter]
   attribute-sequence = *(ATTRIBUTE-TAG  *compound-attribute)

   compound-parameter = parameter *(more-values)
   parameter = TYPE-TAG name-length name value-length value
   compound-attribute = attribute *(more-values)
   attribute = TYPE-TAG name-length name value-length value
   more-values = TYPE-TAG ZERO-NAME-LENGTH value-length value
   name-length = SIGNED-SHORT    ; number of octets of `name'
   name = LALPHA *( LALPHA / DIGIT / "-" / "_" )
   value-length = SIGNED-SHORT  ; number of octets of `value'
   value = OCTET-STRING
   data = OCTET-STRING

   ZERO-NAME-LENGTH = %x00 %x00            ; name-length of 0
   SIGNED-BYTE = %x0..%x7F
   SIGNED-SHORT = %x0.. %x7FFF
   DIGIT = "0".."9"
   LALPHA = "a".."z"
   BYTE = %x0..%xFF
   OCTET-STRING = *BYTE
   TYPE-TAG = %x10..%xFF
   PARAMETER-TAG =  %x01  ; TYPE-TAG of 1
   ATTRIBUTE-TAG =  %x02  ; TYPE-TAG of 2
   DATA-TAG = %x03        ; TYPE-TAG of 3

 The following table specifies the allocation of values for the tag byte:

 Tag Range   Meaning
 (Hex)

 00-0F       tags  that  identify portions  of  the
             encoding, e.g. DATA-TAG
 01-1F       a  parameter/attribute with  a special
             `out-of-band'     value    that     is
             independent  of   its  ordinary  type,
             e.g.  "unsupported". The  value-length
             SHOULD be 0, and the value empty.
 02-3F       signed  binary integer  in  big endian
             order
 04-7F       character string
 80-FF       reserved

 The following table specifies actual values for the tag byte:

 Tag   Value Meaning
 (Hex)

 00          reserved
 01          start of parameters
 02          start of attributes
 03          start of data
 04-0F       reserved
 10          unsupported
 11          default
 12-1F       reserved
 20          unspecified-integer
 21          integer
 22          boolean
 23          seconds
 24          milliseconds
 25          enum   ISSUE,   should  there   be   a
             separate type for each enum
 26-3F       reserved
 40          unspecified-string
 41          text
 42          name
 43          filename
 44          keyword
 45          uri
 46          uriScheme
 47          dateTime
 48-7F       reserved

ISSUE: should we have unspecified-integer and  unspecified-string for
an implementation that doesn't want to be more specific about an
integer or string.

 1.2 Diagram of Encoding

 The following is a diagram of the encoding of  a request and response
 operation.

   ----------------------------------------------
   |    major version       |    minor version  |    2 bytes
   ----------------------------------------------
   |  operation (request) or status (response)  |    2 bytes
   -----------------------------------------------------------
   |                     0x01                   |    1 byte  |
   ----------------------------------------------            |- optional
   |                parameter-sequence          |    k bytes |
   -----------------------------------------------------------
   |                     0x02                   |    1 byte  |
   ----------------------------------------------            |- 0 or more
   |               attribute-sequence           |    n bytes |
   -----------------------------------------------------------
   |                     0x03                   |    1 byte
   ----------------------------------------------
   |                     data                   |    q bytes - optional
   ----------------------------------------------

 The following is a diagram of the parameter-sequence which is 0 or more
 compound-parameters.

   ----------------------------------------------
   |               compound-parameter           |    r bytes - 0 or more
   ----------------------------------------------

 The following is a diagram of the attribute-sequence which is 0 or more
 compound-attributes.

   ----------------------------------------------
   |               compound-attribute           |    s bytes - 0 or more
   ----------------------------------------------
 The following is a diagram of a compound-parameter and a a compound-
 attribute. The optional fields are present only when a compound-
 parameter or compound-attribute has more than one value.

   ----------------------------------------------
   |                   value-tag                |    1 byte
   ----------------------------------------------
   |                  name-length               |    2 bytes
   ----------------------------------------------
   |                     name                   |    u bytes
   ----------------------------------------------
   |                  value-length              |    2 bytes
   ----------------------------------------------
   |                     value                  |    v bytes
   -----------------------------------------------------------
   |                   value-tag                |    1 bytes |
   ----------------------------------------------            |
   |                    0x0000                  |    2 bytes |
   ----------------------------------------------            |- 0 or more
   |                  value-length              |    2 bytes |
   ----------------------------------------------            |
   |                     value                  |    w bytes |
   -----------------------------------------------------------

---

From: JK Martin <[email-masked]>
Date: Thu, 10 Jul 1997 14:50:30 -0400 (EDT)

I agree with David completely.

Based on the content of Bob's submission, I just don't see the value
in making this kind of change, particularly at this point in time.

Perhaps Bob (or another proponent) can better illustrate the supposed
advantages to this proposal?

No matter what, we really need to (publicly) hear what Microsoft and
Hewlett-Packard have to say on this matter.

	...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   --
----------------------------------------------------------------------

----- Begin Included Message -----

>From [email-masked] Thu Jul 10 14:32 EDT 1997
Date: Thu, 10 Jul 1997 11:16:47 PST
From: [email-masked]
To: [email-masked]
Subject: Re: IPP>PRO proposed tweak to protocol

> I think that it is an improvement. I hope that you will agree.

Please.  I can't see where this change amounts to a hill of beans, one
way or the other.  I've decoded enough line encodings, with and without
type tags, to be confident that, in the big picture, this doesn't
matter.  What's driving me crazy is to see "the protocol encoding
discussion that wouldn't die."  And each time we get a slightly
different quorum, it takes off in a different direction.  It's chewed up
endless e-mail messages on the mailing list, it took a half day of the
IPP meetings in Nashua, and I'm sure that's only a small sampling.

Let me take another tack -- maybe this will be useful for future
discussion.  We've all been watching the Pathfinder mission (haven't
we?), and we've gotten it drilled into us about how this is NASA's new
way of doing space exploration -- "faster, better, cheaper" or something
thereabouts.  My impression is that, basically, they've tried to be
smarter about what's important, and where they spend their hours and
dollars -- stock components wherever possible; if a solution is good
enough to do the job, move on to the next thing; which investment of
effort is likely to have to greatest benefit.  They're not wasting time
debating what shape of nuts to use -- four sided, six sided; hey,
they're some advantages to seven sided, you know.

Haarrumph!

::  David Kellerman         Northlake Software      503-228-3383
::  [email-masked] Portland, Oregon        fax 503-228-5662

----- End Included Message -----

---

From: [email-masked] (Robert Herriot)
Date: Thu, 10 Jul 1997 14:00:09 -0700

I tried to indicate the advantages to the tag byte yesterday.  I will
try to give more information now. The advantage of the change is
admittedly small, but nonetheless positive.

There were two motivating factors: value-typing and elimination of
negative lengths. Value-typing was the catalyst for the change and
elimination negative lengths was a fortunate outcome.

Value Typing:

We have discussed typing at length. We have said that in version 1,
implementations would hardcode typing along with localization. But some
people have argued persuasively that an implementation may want to
process values, at least into integer or character string internal
representations before looking up an attribute to determine its type.
This argues for typing of at least integer and character string without
futher subdivision into booleans and enums for integers for keynames
and dateTimes for character strings.  It was also observed there is a
long history of typing fields being useful and that PDF and TIFF have
typing fields.  Some people strongly believe that we will eventually
need a typing field, so we should put it in now to avoid a major
revision of the protocol, even if it distinguishes only integer and
character string. These people believe that it is important for a 
decoder to be able to fully parse an encoding down to its constituent
values without knowing the semantics.  There is some merit to that view.

Negative Lengths:

Negative lengths are a reasonable solution to the problem and we certainly could 
continue to live with them.  They work. But they need a careful explanation because
negative lengths are unexpected and because the specification of representation of
negative integers assumes 2's complement integer which may not yet be universal.

Neither of these problems argues for eliminating negative lengths per se, but the
solution with tags does seem slightly better.

Summary

At this point, I think we should ask whether there are strong arguments against
this change from a technical view? 

For people who are concerned about constant change, I see this as the last change
before we get experience from implementations which will hopefully verify that we
have made good decisions. 

Bob Herriot

---

From: JK Martin <[email-masked]>
Date: Thu, 10 Jul 1997 18:35:41 -0400 (EDT)

One of the problems I (and others) have had with much of the IPP
verbage on the list is the lack of clear examples to back up the
various proposals.  This appears to be true for this new "tweak"
proposal as well.

One of the things I really liked about the SWP drafts is that the
authors took the time to literally spell out real-world examples
of the various encodings.

Bob, can you post a couple of encoding examples, where each example
is shown using the current agreed upon encoding *and* your new
"tweaked" form?  Your effort would be greatly appreciated by those
of us who are currently inundated by work on other, related printer
standards efforts.

	...jay

---

From: JK Martin <[email-masked]>
Date: Fri, 11 Jul 1997 12:42:15 -0400 (EDT)

> I want to hear back, on the DL, as quickly as possible where people now
> stand, so that we can indeed put this particular part of our specification
> to bed and move on.  I would like your responses back no later than Monday,
> July 13.

I take it you mean "Monday, July 14" as the deadline.

In any case, I don't think the proper consensus can be reached until we
hear from the sponsors of the SWP proposal (Microsoft and HP).  Hopefully
they are monitoring this discussion and will post their "votes" by this
Monday.

After reviewing Bob Herriot's set of example encodings (nice job, Bob),
I feel I understand the impact of the proposed "tweak", yet I still don't
come away with a strong feeling that such a change is really needed.

I realize that some folks (such as Steve Zilles and Roger deBry) have
been lobbying for a Tag-Length-Value (TLV) approach for a while now,
but the group had previously said NO to this approach (right?).  Yet,
the topic is once again being brought up for consideration.

If the desire is to have a TLV mechanism, then why are we reinventing
what has already been accomplished via ASN.1/BER?  (This is precisely
what several people had previously asked back when this topic was
discussed on the DL...and the net consensus was "Don't Do It".)

Personally (FWIW), I could live with this proposal if I had to.  But
as I keep saying, what really matters is whether the authors of SWP
are willing to accept it.

If accepting this proposal causes the SWP camp to revert to the position
prior to the Nashua meetings (ie, two conformance levels, where Microsoft
doesn't implement some of the absolutely key features for IPP), then this
proposal is totally unacceptable.

The greater good of IPP rests with pervasive deployment of a reasonable
set of standard features.  Anything that gets in the way of this simple
goal--such as insisting on this "tweak" proposal--should be discarded
out of hand, IMHO.

Let's see what Microsoft and HP have to say about this proposal.

	...jay

---

From: "Sylvan Butler" <[email-masked]>
Date: Fri, 11 Jul 1997 14:04:34 -0700

>come away with a strong feeling that such a change is really needed.

I would concur.  Bob asked for "strong arguments against" it and I 
really don't have any.  I don't think it is that hard to implement.  
It just adds some additional error conditions that need to be clearly 
documented, implemented, and tested.  Just one more straw for the 
camel's back...

(Did anyone else have that game years ago???  A camel who was split 
in the middle with an elastic band connecting front with back half.  
You add "straws" to the basket on his back, whoever adds "the straw 
that breaks the camel's back" loses...  They sit out the remainder.)

>been lobbying for a Tag-Length-Value (TLV) approach for a while now,

AKA "triplets"  That was actually far more "binary" than our current 
approach.  It could, for example, eliminate attribute names (the 
'tag' becomes the name).

>but the group had previously said NO to this approach (right?).  Yet,

I thought so.

>what has already been accomplished via ASN.1/BER?  (This is precisely

ASN.1/BER is a very complex encoding mechanism for TLV.  I don't 
believe that a TLV or triplet approach necesitates ASN.1/BER or even 
that that would be the best choice.

>set of standard features.  Anything that gets in the way of this simple

I agree.  For my part, it is an unfortunate reality that schedule is 
becoming a driving force.  :(

[re. the HP and MS stand]

For the summary of MY position re. 'types' aka 'tags', see my first 
paragraph above.

sdb

 | Sylvan Butler | [email-masked] | AreaCode 208 Phone/TelNet 396-2282 |