IPP Mail Archive: RE: IPP>MOD PRO Comments on Microsofts IPP document

RE: IPP>MOD PRO Comments on Microsofts IPP document

Paul Moore (paulmo@microsoft.com)
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: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM]
> Sent: Friday, June 06, 1997 7:59 PM
> To: Paul Moore; ipp@pwg.org
> Subject: IPP>MOD PRO Comments on Microsofts IPP document
>
>
> 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.