Subject: IPP>MOD PRO Comments on Microsofts IPP document

From: [email-masked] (Robert Herriot)
Date: Fri, 6 Jun 1997 19:59:16 -0700

I have comments about a few parts which differ from the IPP documents.
I hope that we can resolve these differences to keep compatibility.

Section 2.4. You state that you don't support print by reference, but
  your Rationale suggests you would do it the same we have proposed, namely
  with a job attribute which contains the document URI. Am I missing
  something? So, do you plan to support print by reference with a client
  supplied URI?

Section 7.4. I would suggest that you look at the new wording for
  defining the characters allowed for an attribute name.  The document
  should be posted by Monday.  It limits names to the ASCII letters, 
  ASCII digits, ASCII hyphen and ASCII underscore.

Section 8. You define several different representations for attribute
  values: text, binary integers, binary boolean, binary keywords.  But
  you don't include a field for value's type.  This makes is hard for
  a client to know how to interpret and unknown attribute.  I think
  the right solution is to keep the IPP solution where all values are
  text. Alternatively, we could all agree to add a one byte type field 
  just before the value's length field.

Section 8 (Setof): We decided at the San Diego meeting that a set of 
  values would be represented by a sequence of attributes in which
  all but the first attribute name would be of 0 length.  Your description
  omits the statement about 0 length.

---

From: Paul Moore <[email-masked]>
Date: Sun, 8 Jun 1997 17:26:46 -0700

By Reference:
I do not think that all the issues of print by reference have been
thought out yet. You are right that an attribute could be added, but
this is fundamentally different from the existing print operation - I
would make it a separate operation. A print server can ignore any
attribute and still be able to print, this is not the case for a
document URL attribute. I would have "PrintThis" and "PrintThat" as two
distinct operations that a server may or may not implement.

Attribute names: 
Whatever seems correct to the group.(I was merely advising against
calling something 'Job&%Copies#*@')

Type byte:
This was suggested to me already. I am neutral on the subject. I did not
make the change becuase it was not discussed in San Diego. There are a
few question I have on it which I would like to see discussed before
finalising.

SetOf:
I remember the discussion - I was not sure what was agreed. I am neutral
on the topic - whatever the consensus is, I will put in.

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, June 06, 1997 7:59 PM
> To:	Paul Moore; [email-masked]
> Subject:	IPP>MOD PRO Comments on Microsofts IPP document
> 
>

---

From: JK Martin <[email-masked]>
Date: Mon, 9 Jun 1997 14:12:12 -0400 (EDT)

Paul,

Thanks for responding to Bob Herriot's questions.

> thought out yet.

Can you shed some light on those issues not yet thought out?  Are there
other considerations/constraints that have not yet been presented on
this list that we should discuss?

> few question I have on it which I would like to see discussed before

What are the questions you have about typing as it has been proposed?
We should start discussing those questions immediately, given the
current date of this effort.

Whatever you and your colleagues at Microsoft can do to help further
the development of this standard would be greatly appreciated by all
the IPP participants.

	...jay

---

From: [email-masked] (Robert Herriot)
Date: Mon, 9 Jun 1997 12:32:01 -0700

I forgot to mention one other difference in your IPP document.  

In Section 8.2, you state that "a server may ignore those attributes
that it does not support".  The IPP group decided at the San Diego
meeting that a server must reject a job if it contains an attribute
that it does not recognize or if it contains an attribute value that it does
not support.  We wanted to make sure that a client would get what
what was requested with no surprises.

What do you think?

Bob Herriot
 
> From [email-masked] Sun Jun  8 17:28:15 1997
> From: Paul Moore <[email-masked]>
> To: "[email-masked]'" <Robert.Herriot@Eng>, [email-masked]
> Subject: RE: IPP>MOD PRO Comments on Microsofts IPP document
> Date: Sun, 8 Jun 1997 17:26:46 -0700
> X-Priority: 3
> X-Mailer: Internet Mail Service (5.0.1458.30)
> Content-Length: 2688
> X-Lines: 60
> 
> By Reference:

---

From: Paul Moore <[email-masked]>
Date: Mon, 9 Jun 1997 12:55:22 -0700

Main By reference issues:
1. Some servers may not want to do it (memory overhead in prnter for
example)
2. Security - how does the server gain access to the resources. NT can
do it with impersonation but that is not a generic solution.

Type Byte:
1 having a type byte implies that any attribute can have any format - in
the original design an attribute had a defined format. THis made it
simple for a server. What happens if an attribute has a type that the
server does not expect? Or should we define a set of allowed types for
each attribute. 
2. The main discussion seemed to be around allowing structured types
(address). What are these structured types?

> From:	JK Martin [SMTP:[email-masked]]
> Sent:	Monday, June 09, 1997 11:12 AM
> To:	Paul Moore
> Cc:	[email-masked]

---

From: [email-masked] (Robert Herriot)
Date: Mon, 9 Jun 1997 15:31:53 -0700

You said that you are neutral on the subject of a type byte.  Does
that mean that if we have no type byte that you are willing to 
have all values be represented by text?  Currently, some of your
attributes are text and others are binary.  That is a problem if
there is no type byte.

It seems to me that having no type byte and having all values be represented
by text is the simplest solution.

Bob Herriot

---

From: [email-masked] (Robert Herriot)
Date: Mon, 9 Jun 1997 17:11:35 -0700

> From [email-masked] Mon Jun  9 16:49:30 1997
> 
> I don't think having all values as text helps. Somebody said that they
> wanted to support structured types, a string does not do that. Also
> having things as text requires more specifications (are leading
> /trailing spaces allowed on a number for example?)

The IPP text representation doesn't have structured values, but it
does prescribe the representation for various types, such as integer,
date and text.

Issues like leading/trailing spaces are a lot easier to deal with than
having a client try to figure out whether to interpret the octets of an
unknown attribute as text or binary. I believe that we need to deal
with extensibility where a client may need to display attributes that
it doesn't understand.

Bob Herriot 

> > Sent:	Monday, June 09, 1997 3:32 PM
> > To:	[email-masked]; [email-masked]; Paul Moore