Subject: IPP>MOD - best effort

From: Roger K Debry <[email-masked]>
Date: Mon, 21 Jul 1997 09:54:56 -0400

>There should be an OPTIONAL job attribute may-ignore-attributes which
>is set by the parameter may- ignore-attributes. This attribute is
>MANDATORY if Create-Job is supported because Send-Document and Send-URI
>use the value set by Create-Job. Otherwise, I wouldn't expect it to be
>implemented.  It would be useful in a future resubmit-job operation

Now let me see, if I understand .... we don't like the concept of best-effort
as an attribute, so
we rename it, make it a parameter, then add an optional job attribute with the
same name,
and then have the parameter set the attribute, except sometimes the attribute
(or is it the
parameter) is mandatory.  Did I get it right??????

Excuse me, but I think we just added a ton of confusion and didn't change
things one bit!

---

From: JK Martin <[email-masked]>
Date: Mon, 21 Jul 1997 10:48:01 -0400 (EDT)

I completely agree with Roger.  I just don't see the added value
here...but I certainly see the additional complexity and resulting
confusion.

There is nothing wrong (semantically) with "best-effort".  Let's
leave it alone, but make the obvious clarifications in the Model
document with regard to Job templates, etc.

	...jay

----- Begin Included Message -----

>From [email-masked] Mon Jul 21 10:01 EDT 1997
From: Roger K Debry <[email-masked]>
To: <[email-masked]>
Subject: IPP>MOD - best effort
Date: Mon, 21 Jul 1997 09:54:56 -0400

>implemented.  It would be useful in a future resubmit-job operation

Now let me see, if I understand .... we don't like the concept of
best-effort as an attribute, so we rename it, make it a parameter, then
add an optional job attribute with the same name, and then have the
parameter set the attribute, except sometimes the attribute (or is it
the parameter) is mandatory.  Did I get it right??????

----- End Included Message -----

---

From: [email-masked] (Robert Herriot)
Date: Mon, 21 Jul 1997 14:03:35 -0700

There is plenty wrong with best-effort. Perhaps you didn't read the
fine print in the current model document.  It is currently 
defined as a job template attribute which means:

   o there is a job attribute "best-effort" for specifying what the 
     client wants.
   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.
   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"
         * "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.
    o the "best-effort" substitution is somewhat undefined and 
      potentially complex.

Compare the above with what I proposed:

    o I replace 3 job-template attributes by a single parameter
     "may-ignored-attributes" which is either true, false or omitted
      (false is default).  All printers support both values because 
      it is easier to support "best-effort" as "ignore the attribute".

    o I make it easy to process the "may-ignore-attributes" value before 
      any attributes are processed because the information is
      in the parameter section which precedes any attributes.

Now I suggest that we forget about "may-ignore-attributes" job
attribute, that I proposed.  It really isn't necessary and deflects
from the discussion. The single parameter is sufficient.

Do you still believe that the "3 job-template attributes" proposal is 
simpler than the "single parameter" proposal?

Bob Herriot

> From [email-masked] Mon Jul 21 07:58:51 1997
>

---

From: JK Martin <[email-masked]>
Date: Mon, 21 Jul 1997 18:50:20 -0400 (EDT)

Sorry, but what I meant to say was that there was no obviously
good reason to rename "best-effort" to "may-ignore-attributes".
(I guess you've since withdrawn such renaming...thanks.)

I do, however, like moving "best-effort" to a parameter where
applicable.

	...jay

----- Begin Included Message -----

>From [email-masked] Mon Jul 21 17:03 EDT 1997
Date: Mon, 21 Jul 1997 14:03:35 -0700
From: [email-masked] (Robert Herriot)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: IPP>MOD - best effort

Bob Herriot

----- End Included Message -----

---

From: [email-masked] (Robert Herriot)
Date: Mon, 21 Jul 1997 16:13:20 -0700

The semantics are more important to me than the name.  If the
group prefers "best-effort" to "may-ignore-attributes", that's
OK with me.

But what do you mean by "where applicable" below. I had in 
mind that "best-effort" would be a parameter and nothing else.
It is behavior that occurs during receipt of a printer and
has no existence past that point.

Bob Herriot

> From [email-masked] Mon Jul 21 15:51:00 1997
>

---

From: Roger K Debry <[email-masked]>
Date: Tue, 22 Jul 1997 09:26:53 -0400

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!

    <RKD> This is straightforward and consistent with it being
    <RKD> a job template attribute. I see no problem here.

    <RKD> This is also simple and consistent.

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

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

    <RKD> Its not clear why you think this is somewhat undefined
    <RKD> and potentially complex. Why is it different from any
    <RKD> other attribute?

---

From: Chris Tabor <[email-masked]>
Date: Tue, 22 Jul 1997 07:31:40 -0700

> is itself an attribute of the job. Let's keep

Or is it a parameter that controls the selection of job attributes?

>     <RKD> a job template attribute. I see no problem here.
<<<Snip>>>

--C
----------------------------------------------------------------------
Chris Tabor                 (602) 862-5806                  Go Suns!!!
[email-masked]        Fax (602) 862-4290 Std Disclaimer - The ideas, 
opinions, recommendations and views expressed in this message are my own and in 
no way represent those of my employer or Internet provider.

---

From: JK Martin <[email-masked]>
Date: Tue, 22 Jul 1997 14:31:50 -0400 (EDT)

Looks like we've been talking past each other, Bob.

By "where applicable", I mean that the "best-effort" should be a
an optional parameter for messages involving job submission.

I believe we're saying the same thing.

	...jay

----- Begin Included Message -----

>From [email-masked] Mon Jul 21 19:14 EDT 1997
Date: Mon, 21 Jul 1997 16:13:20 -0700
From: [email-masked] (Robert Herriot)
To: [email-masked], [email-masked]
Subject: Re: IPP>MOD - best effort
Cc: [email-masked]

Bob Herriot

----- End Included Message -----

---

From: [email-masked] (Robert Herriot)
Date: Tue, 22 Jul 1997 17:42:44 -0700

> From [email-masked] Tue Jul 22 13:22:23 1997
> 
> Finally, in terms of the placement of the best-effort attribute, I do
> not feel that it is burdensome to the implementation to allow it as an
> attribute, and allow it to occur anywhere in the sequence of job
> attributes.  If anyone has a concrete example to the contrary, I
> would love to hear it.

RGH: Best-effort is the only attribute whose value affects the processing
RGH: of other attributes while the Printer is acquiring the attributes
RGH: from the operation.

RGH: If best-effort remains an attribute, an implementation must acquire the
RGH: value of best-effort before it validates any other attributes.  This is
RGH: a constraint which may or may not cause implementors a problem, but it
RGH: does create a potential look-ahead problem.  

RGH: If best-effort becomes a parameter, it will always precede all
RGH: attributes, leaving more flexibility for the implementor.  I prefer a
RGH: design that avoids look-ahead problems as much as possible.

RGH: Bob Herriot
> 
> ...walker
> 
> --
> Jim Walker <[email-masked]>

---

From: Roger K Debry <[email-masked]>
Date: Wed, 23 Jul 1997 11:13:28 -0400

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: [email-masked]
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 [email-masked] @ 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 [email-masked] Tue Jul 22 06:26:08 1997
>

 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.

---

From: JK Martin <[email-masked]>
Date: Wed, 23 Jul 1997 13:50:31 -0400 (EDT)

After reading Jim Walker's comments on this issue, I find myself
somewhat ambivalent on whether "best-effort" should be a parameter
or a job attribute.

Jim's made some good observations in support of the attribute approach,
and Roger feels pretty strongly about having it as an attribute, too.
I can go either way.

Roger's right, though.  Let's resolve this issue pronto and move on
to other issues.

	...jay

----- Begin Included Message -----

>From [email-masked] Wed Jul 23 11:20 EDT 1997
From: Roger K Debry <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: IPP>MOD - best effort
Date: Wed, 23 Jul 1997 11:13:28 -0400

Bob,

Roger K deBry

        ipp-owner @ pwg.org
        07/22/97 04:36 PM

Bob Herriot

----- End Included Message -----