IPP>MOD - best effort

[Roger K Debry]

Bob,


I doubt that we will ever convince one aother!  I've seen a couple
of comments from others on  the subject. Jim Walker made a good
point on the persistence of parameters vs. attributes.  Jay seemed to
have moved in favor of your proposal based on getting rid of the
corresponding job attribute.  But, I don't know that we have a good
resolution process in cases like this.  I don't particulalrly want to debate
the issue any longer, I'll go along with whatever consensus we reach
as a group. However, I'm not willing to give in without some group
resolution process being executed.


Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080




---------------------- Forwarded by Roger K Debry/Boulder/IBM on 07/23/97 09:00
AM ---------------------------


        ipp-owner @ pwg.org
        07/22/97 04:36 PM
Please respond to ipp-owner at pwg.org @ internet


To: Roger K Debry/Boulder/IBM
cc: ipp @ pwg.org @ internet
Subject: Re: IPP>MOD - best effort


I think that the sum total of your arguments in favor of keeping
best-effort as a job-template parameter add up to an argument in favor
of the single best-effort parameter.  In each item below, you provide a
workable solution, but each one is increasingly difficult to implement,
especially the one that involves determining the value of best-effort
before processing other attributes.


But the bottom line question is, why do we need all of these
implementation options for best-effort when all implementations have to
deal with the issue of unsupported attributes and each of the two
"best-effort" options is trivial to implement. That is, when a Printer
encounters an unsupported attribute or value, it either rejects the job
(best-effort=false) or ignores the attribute (best-effort=true).


It seems like far more effort to implement, document and test the 3
best-effort job-template attributes (MANDATORY attributes with
values that are OPTIONAL), than to fully support both values of
a best-effort parameter.


[ There is an additional comment about substitution at the end of this
  email. ]


Bob Herriot


> From rdebry at us.ibm.com Tue Jul 22 06:26:08 1997
>
>  Bob, You've clearly simplified things by
> getting rid of the "may-ignore ..." job
> attribute. But, I still believe that a
> "best-effort" job template attribute is better
> than a new parameter. To me, whether or not I want
> the job to print, regardless of attribute errors,
> is itself an attribute of the job. Let's keep
> attributes attributes!
>
>    o there is a job attribute "best-effort" for specifying what the
>      client wants.
>
>     <RKD> This is straightforward and consistent with it being
>     <RKD> a job template attribute. I see no problem here.
>
>    o there is a printer default "best-effort" which says whether
>      the printer defaults it behavior to best-effort or not if a
>      client doesn't specify this attribute.
>
>     <RKD> This is also simple and consistent.
>
>    o there is a printer "best-effort-supported" attribute which is unlike
>      most xxx-supported attributes. It is not a set of possible
>      values, namely "true" and "false" values. Instead, it is either
>      "true" or "false"
>
>     <RKD> As you have written it down here, the rules are
>     <RKD> not consistent with other job template atributes.
>     <RKD> However, it seems that this is an easy fix. If a
>     <RKD> Printer supports both "true" and "false" values,
>     <RKD> then the xxx-supported should in fact be a set of
>     <RKD> values, namely "true" and "false". This matches
>     <RKD> what you have written below. Furthermore, if the
>     <RKD> Printer only supports "false" then xxx-supported
>     <RKD> has only one value, and that is "false". This also
>     <RKD> matches what you have written below. Now I think
>     <RKD> xxx-supported for "best-effort" is consistent with
>     <RKD> other job template attributes.
>
>          * "true" means that a client can specify either the value
>            "true" or "false" or and the printer default "best-effort"
>            can have the value of true or false"
>          * "false" means that a client can specify only the value of
>            "false" and the default "best-effort" can have only the
>            value of "false".
>          NOTE: it is believed that no implementation would support
>          a "best-effort" job attribute of "true" only.
>
>     o this attribute has to be processed before others are processed
>       because it affects the processing of them, but it need not
>       be the first attribute.
>
>     <RKD> It appears that you can fix this problem in two ways.
>     <RKD> Although it may require a little additional code to
>     <RKD> implement, it is surely possible for the Printer to
>     <RKD> handle the best-effort attribute in any place in the
>     <RKD> sequence of received attributes. If everyone thinks
>     <RKD> this is too hard, then you could mandate that if this
>     <RKD> attribute is used it MUST be the first in the list.
>     <RKD> Admittedly, this is a special rule for this attribute,
>     <RKD> but in effect that's all you've done by declaring it
>     <RKD> a parameter.
>
>       o the "best-effort" substitution is somewhat undefined and
>       potentially complex.
>
>     <RKD> Its not clear why you think this is somewhat undefined
>     <RKD> and potentially complex. Why is it different from any
>     <RKD> other attribute?


 RGH:  The model document uses the word "substitution" to (perhaps)
 RGH:  mean that the Printer picks some value that may be other than
 RGH:  the attribute's default value. For example, if a printer
 RGH:  supports letter and B size paper with letter the default size,
 RGH:  and if a client requests A3 paper, then B would be a good
 RGH:  substitution using some undefined logic, and letter would
 RGH:  be the simple substitution using the default.


>
>