Subject: IPP> REQ - Last minute scenario comments

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 28 Jan 1997 18:11:41 PST

Hi,

here are my comments on the scenario document.

Major scenario concern:

I am still unhappy about the Printer Discovery scenarios, at
least if we assume that they will be realized by directory
or name service functions only. 

They seem to be asking for a lot more detail to be put into
the directory than I had anticipated.  My going in assumption
has been that we want to have a limited number of directory
attributes on which we can do searches to LOCATE Printers, but
not to find out about ALL the detailed capabilities of a Printer.
My feeling is that we should not plan on having more than
10 - 15 directory attributes for a printer, or we are going 
to overload the directory administration with too much detail
that all has to be maintained in addition to the Printing system.
The X.500 standard has defined the attributes for a Device, I
suggest that we build on that and add a limited number of printer
specific attributes - but not dozens of them. 

If we want to get more detailed information about a printer's 
capabilities, I would expect to go and ask for that Printer's 
attribute list, using the IPP. Any variable information, such as 
media loaded, or printer state has nothing to seek in the directory.

As further examples, I would consider information about security 
details and payments to be part of the printer information, but not 
in the directory entry. In the directory I would expect to just 
find out whether the printer has unrestricted access or not - period.

However, we should be able to keep the basic scenario requirements, 
but not assume that everything is happening in one simple interchange.
The realization of the scenarios should be possible through a com-
bination of a directory search and one or several list inquiries
on Printer objects in IPP. (The steps in between may or may not be 
visible to the user).

Editorial concern:

We need to explain more clearly what the bullited lists mean:

Example: In scenario picture 3.0, the response bullits obviously
mean that they are alternative responses, but in the following 
scenarios 3.1 etc. the bullits stand for a sequence of parameters.
BTW, the parameter "tell me the status of the job", I would put at 
the end of the list, as it should reflect the job state after the 
other parameters have been acted on as reflected in the response. 
(This ambiguity occurs in many more scenarios).

More detailed scenario comments:

In scenario 3.8, which was addeded as result of an earlier request 
from me, I would like to have "chunks" as in scenario 3.6, and not
have "Letter-to-Mom" as example, but rather "Long-Run-of-Invoices"
of undeterminable length (when the job starts printing).

I think that scenario 4.0 needs to get refined into more than 
just Getting Status. In effect there are at least the following kind 
of functions described under scenario 4.

1) Getting detailed information about a printer's capabilities (static)

2) Getting information about a printer's status (variable)

3) Getting information about a job's status (variable) and fixed attributes.

In scenario 5, I suggest taking out (Email) in the heading. Maybe we could 
come up with some alternative to email in the more detailed scenarios, such 
as "beeper with display" (wonder if they will have URLs soon?).

We need to make more detailed scenarios for different security environments,
as already planned by the Security subgroup. Until that work is done, I think
we should keep down the number of security feature details in this version
of the scenarios - we probably get them wrong. 

----

Carl-Uno

Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: [email-masked] (Robert Herriot)
Date: Fri, 31 Jan 1997 14:07:54 -0800

Larry, 

I think you are looking at things in a different way. I will try to
explain two issues you raised in greater detail below.

Bob Herriot
--------------------------------

> From [email-masked] Thu Jan 30 22:36:07 1997
> 
> # 2. non-paginated documents  (e.g. text, HTML)
> 
> In this case, "text + formatting" or "html + formatting" is just
> another kind of "PDL".

Yes, "text + formatting" is another kind of PDL, but the formatting part
needs to be specified separately from the text, either via defaults or
via some parameters that a user can specify.  In a PostScript file and
in an application file, such as MS Word, formatting
is alreay embedded in the file. 

So from the client software point of view, the user needs to be allowed
to specify formatting parameters that make no sense in the PostScript
or MS Word case. If all client parameters come from the Printer, then it
is the printer that holds formatting defaults and supported values.

-----------------------------
 
> # o the protocol needs to be able to specify whether an accompanying
> #   attribute has been embedded in the document and is just there to
> #   indicate the needed resources if it is present.
> 
> I think generally that job attributes could to be marked as either
> overriding or subordinate to attributes embedded in the document,
> although "always override" would work.

I was saying something different. In IPP, we have specifically eliminated
attributes that are subordinate to attributes embedded in a document because
we didn't think that they are useful for most people.  Such an attribute
leaves a user not knowing what he will actually get.

The attribute concept that I am dealing with is that an attribute, e.g.
sides when it accompanies the document may have one of two meanings:
the client has requested some feature which:

   1) has not yet been embedded in the document data, but overrides 
      whatever is in the document.

   2) is currently embedded in the document but exists as an external
      attribute to tell the Printer about a needed resource. Some 
      program that produced the PDL has set the attribute in this case.

----------------------------------------
> If you have:
>    client sends PDL + parameters to gateway
>    gateway sends PDL to real printer without parameters
> 
> and the PDL is capable of expressing some attributes ("paper size",
> for example), then why not have the gateway just add the parameters to
> the PDL? I know that it's extra implementation work on the part of
> your gateway, but the alternative is to require the same work to be
> done in all clients that want to set paper size; they will need to
> either "always send paper size in the PDL" or else "negotiate over
> where to set paper size and be prepared to send it in the PDL".
> 
> Is it really so much harder to take envelope parameters and embed them
> in the data stream?

I think that Harry did a good job of explaining the problems of merging
attributes into a PDL.  This why I have the three cases that I
presented and why a Printer must give a user access to a set features
that are dependenton the type of document data.