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

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

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

Robert Herriot robert.herriot at Eng.Sun.COM
Thu Nov 21 22:23:13 EST 1996


> 
> 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
> 
> 
> 
> 
> 



More information about the Ipp mailing list