IPP Mail Archive: Re: Some Comments on ipp92.doc - the issues we didn't get to

Re: Some Comments on ipp92.doc - the issues we didn't get to

Robert Herriot (robert.herriot@Eng.Sun.COM)
Thu, 21 Nov 1996 19:23:13 -0800

>
> Most of these comments are on the ISSUES listed in the document that
> we didn't get time to address.
>
> 1. 6.1 Attribute syntaxes
>
> Need to add explanation of the notation in side the parens:
>
> "#" in front of a data syntax means zero or more values
> "1#" in front of a data syntax means one or more values
>

* means zero or more items, # means 0 or more items in a list, each separated by a comma ",".
The syntax is defined in rfc 822 and rfc 1945. We should just lift it all, word
for word.

>
> 2. 6.1 Attribute syntaxes
>
> Get rid of the TBDs
>
>
> 3. 6.2.4.2 printer-assigned (name)
>
> ISSUE: Get rid of it. Not needed for our model.
>
> But maybe change it to local-output-device-name-used.
> As the text indicates, this will help a user find the output if
> the user has to do it himself/herself.

If xxx-used have a special meaning, I suggest not calling it local-output-device-name-used.
>
>
> 4. 6.2.6.1 notification-events
>
> ISSUE:
> Need to add a notification-address URL which allows the user or
> the client to specify mail:// or http://

Is 'mail://' defined in some rfc?

>
> We have an 6.3.2 operation-notification-address that the client software sets
> automatically. But if the end-user needs to be able to choose between
> mail and http, we may need to add a notification method or a notification-
> address that the user can supply.
>
>
> 5. 6.2.7.4 job-retention-period
>
> ISSUE:
> Ok to delete for version 1.0. It will come back when we do ResubmitJob operation
> but that is when we need it, not now. Same for 6.4.31
> maximum-job-retention-period. But keep the retained state (even though
> not user affected in version 1.0), since its hard for client when the
> servers add states.
>

I am not sure I agree with the deletion of this feature.

>
> 6. 6.2.8.2 number-up
>
> ISSUE:
> A simpler way to allow end-users to turn of embellishments, is to have
> a distinguised value that turns it off. ISO DPA has "0", but a more
> user friendly value would be "none". Then any other value, like "1",
> or "2", or "4" is free to have any embellishments on it.

I am trying to avoid arbitrary distinguished values that only IPP gurus know about.
The question is whether a user would expect that number-up = 1 gives normal printing
with essentially no number-up.

>
>
> 7. 6.2.12.1 document-format
>
> ISSUE:
> Yes, make version optional. The problem is that if a driver says
> PostScript level 2, but doesn't use any level 2 features, then a
> level 1 printer is probably going to reject when it could have printed
> the document. This is a tough problem.
>
>
> 8. 6.3.2 operation-notification-address
>
> ISSUE:
> Keep, it cannot be inferred from the operation-user-name and operation-host-name
> in call cases.
>
>
> 9. Additional job attributes:
>
> add number of intervening jobs, so that you can see your position in
> the queue, even if the site policy is not to let you see any other jobs.
>
This attribute is a 'maybe'.
>
> 10. Additional printer attributes:
>
> a. add number of jobs waiting to be printed or being printed
>
> b. add scheduling algorithm with values: first-come-first-served and
> shortest-job-first

We haven't addressed the issue of schedulers yet.
>
>
> 11. Explain that the term Printer and the Printer object need not be
> restricted to printing, but can be used to represent other kinds of
> output processing.
>
> Tom
>
>
>
>
>