Subject: IPP> Encoding

From: "steve gebert Dept:ecg SN:579517 Div:ISM Ext" <[email-masked]>
Date: Fri, 20 Jun 97 12:13:43 MDT

I agree with Scott and Jay regarding the use of text-only encoding.

Steve Gebert

---

From: Brian Grimshaw <[email-masked]>
Date: Fri, 20 Jun 97 12:50:10 -0700

I also prefer the proposed text encoding.

I do not see anything new in this post June 17 discussion -- just a 
repeat of previous issues and opinions.  What I've extracted from the 
recent mail is:

   1) Parsing text encoding difficult and error prone.
       - ascii to binary conversion
       - string compares to interpret attribute names

I don't see text encoding as difficult or risky.  Any product I'm 
planning IPP support for already does these things.

   2) Text encoding has no apparent benefit.

I think this is just an opinion that the text encoding benefits offered 
are not compelling to everyone.  In itself, this is not a benefit of 
binary encoding.

   3) Text encoding makes for easier client/server debug.

I agree that this is a --small-- benefit.

   4) Text based encoding leverages tools of HTTP solutions.

I think this is a fairly neutral statement.  It simply justifies the 
position that handling ascii encoding is not difficult nor uncommon.

And from June 17:

   5) No endian issues with text encoding.

I see this as another --small-- benefit.

I would add to the list:

   6) Text encoding of attributes simplifies management of
      extensions -- both vendor extensions and future IPP versions.

This eliminates the maintenance of a mapping of names to numbers.

Unless there is a problem caused by text encoding, which I do not see, I 
prefer it and the associated few benefits.

I am more concerned that the proposed protocol (whether binary or text 
encoded) does not seem to allow representing a set of attributes, or a 
hierarchy of attributes -- without a parser having knowledge of all 
attributes.  While encoding the type in the protocol has been raised as a 
solution to this, I think types do not model sets very well and this 
should be treated as a separate issue.  This could be handled in the 
protocol and, minimally, there should an accommodation for future 
extensions that may allow this without breaking parsers of IPP 1.0.

If I am wrong about this, can someone tell me how to do it with the 
proposed protocol or where in the various documents this is described?

Brian

--------------------
Brian Grimshaw
Apple Computer, Inc.
[email-masked]

---

From: [email-masked] (Robert Herriot)
Date: Fri, 20 Jun 1997 13:12:04 -0700

Sets of n values are represented by a sequence of parameters whose
parameter name is omitted for parameters 2 through n.

In the example in the minutes:

 "0100Print-Job" CRLF
 "job-name 3 foocopies 1 2document-format 22 application/postscript"
 "finishings 5 staple 5 punch" CRLF
 "%!PS

finishings is a set consisting of "staple" and "punch".

I hope this example helps.

Bob Herriot
 
> From [email-masked] Fri Jun 20 12:58:19 1997

---

From: Brian Grimshaw <[email-masked]>
Date: Fri, 20 Jun 97 14:06:27 -0700

Bob,

I think I was unclear in my question.  The proposed protocol allows for 
multiple values to be associated with an attribute (as in your finishings 
example) which is, indeed, a "set".  I am asking for the ability to 
represent a grouping of attributes, as in a much earlier example of two 
addresses, like "job owner address" and "delivery address".  Another 
example may be grouping of communications parameters.

If a server knows these attributes, that's OK -- it then knows to parse 
the opaque value as an ipp-attribute set.  If it doesn't know the 
attribute, then it's unable to parse the "contained" attributes -- 
street, city, zip, etc.

I'm looking for this capability without the explicit encoding of types 
and without requiring the parser to know all the attributes.  I think 
this is much simpler than a complete solution to type encoding and, while 
types COULD be leveraged to solve this problem, they are primarily an 
orthogonal concept.

Brian

---

From: Tom Hastings <[email-masked]>
Date: Fri, 20 Jun 1997 18:28:13 PDT

At 12:50 06/20/97 PDT, Brian Grimshaw wrote:
snip...

>extensions that may allow this without breaking parsers of IPP 1.0.

I'm not exactly sure what you mean by a set.

If you mean a set of values of the same type, then the current
multi-valued encoding works just fine for a set.

In the example in the minutes, there were a set of 2 values for the
"finishing" attribute:

The following is an example of a Print-Job request
 "0100Print-Job" CRLF
 "job-name 3 foocopies 1 2document-format 22 application/postscript"
 "finishings 5 staple 5 punch" CRLF 
 "%!PS" ...

If you mean a set of attributes then that is another matter.  One way
to handle a set of attributes is to have a new data type that is
a single attribute (name and value).  When such an attribute has
multiple attributes as values, use the multi-valued mechanism of IPP,
one value for each attribute.  In this approach, each (sub-)attribute can
only be single-valued.

An example of an "address" attribute whose value consists of attributes:
"name", "apartment-number", "street", "city", "state", "zip", "country"
would be in ABNF:

  "address 15 name 8 John Doe 17 street 8 123 Main 9 city 2 LA 10 state 2 CA"

A second approach is to define the new data type as a set of attributes. 
In the above example, the value of the "address" is single valued. 
But it could be multi-values, providing multiple addesses. 

  "address 52 name 8 John Doestreet 8 123 Maincity 2 LA state 2 CA"

With either scheme in order to group a set of attributes, you need to 
define an attribute with the new data type.  But since Printer MUST
reject any attribute that they don't understand, a client can only
successfully submit a new attribute with a new data type to a Printer
that supports the new data type.

Is this what you mean by a set?  If so, I think we can have sets
in the future with the current encoding and extensibility rules.

Tom

---

From: [email-masked] (Robert Herriot)
Date: Fri, 20 Jun 1997 18:57:26 -0700

I think what you and Brian are trying to define is a set of values where
each value has a name associated with it.  

As long these names are fixed, this is just a new data type with implicit
names associated with each member of the set.

Since we have said that a client either has this information hardwired
(version 1) or can get typing information from a server ( a later version),
there is no need for the parameter representation to store the names
of individual members.  This problem is much like the compiling of
a C struct.

If you are looking for an attribute to contain a list of attributes
where the name is unknown in advance and where each is single valued,
then there could be a datatype which is a set of 2-tuple where each
2-tuple is a name and a value.  We talked about this solution for a set
of integer ranges.  The hard case is for attributes that are
multivalued.

The point of all this is that our current protocol representation for
sets gives use a 95% solution and that is simple and good enough for now.

Bob Herriot

> From [email-masked] Fri Jun 20 18:39:13 1997
>

---

From: Tom Hastings <[email-masked]>
Date: Tue, 24 Jun 1997 22:50:40 PDT

Bob,

I think that we are in agreement that there are at least three ways
that the current encoding could be used to represent an attribute
whose value(s) are attributes.  None of these approaches would require
any change to the current encoding scheme.  Such attributes could
be regestered after V1.0 is a proposed standard, even though the new
attribute has a new data type that is not in V1.0.  The key is that
we have agreed to a general mechanism using a *length* to represent
an attribute value.  The contents of the value are opaque to any recipient
that doesn't recognize and support the attribute as indentified by the
attribute-name.  Any recipient (Printer receiving a request or client 
receiving a response) that doesn't understand that new attribute at least 
knows how to skip over the value (or values if the attribute has multiple 
values) in order to examine the next attribute.  [BTW - we need some
conformance requirement that requires recipients (Printers and clients)
to skip over attributes they don't understand, rather than erroring out.]

This mail message shows the importance of keeping the length mechanism
in our encoding approach in order to achieve future extensibility
with no impact on V1.0.

The three ways are (each with a new data type):

1. A multi-valued data type with each value representing an attribute and a
value

2. A multi-valued data type with each value representing a set of attributes

3. A multi-valued data type with each pair of values representing
the attribute name and the attribute value (your suggestion).

The example encodings of each of the three methods is as follows
for the case of an "address" attribute whose value consists of OPTIONAL 
attributes: "name", "apartment-number", "street", "city", "state", "zip", 
"country":

Method 1:  the new data type that is a *single* attribute (name and value).  
When such an attribute has multiple attributes as values, use the multi-valued 
mechanism of IPP, one value for each attribute.  In this approach, each 
(sub-)attribute can only be single-valued.

Method 2:  the new data type is a *set* of attributes. 
In the above example, the value of the "address" is single valued. 
But it could be multi-values, providing multiple addesses. 

Method 3:  the new data type is pairs of attribute-name attribuet-value
The attribute-value must be single-valued (same restriction as method 1).

  "address 4 name 8 John Doe 6 street 8 123 Main 4 city 2 LA 5 state 2 CA"

Method 3 is perhaps the easiest to parse.

Tom