IPP> Proposed Resolution to BO Issue 4: requesting unsupported d attributes in query operations

IPP> Proposed Resolution to BO Issue 4: requesting unsupported d attributes in query operations

IPP> Proposed Resolution to BO Issue 4: requesting unsupported d attributes in query operations

Harry Lewis/Boulder/IBM harryl at us.ibm.com
Wed Nov 8 12:26:58 EST 2000


Agree that a single "preferred" choice is best... and recommend D (as 
originally intended and specified)
---------------------------------------------- 
Harry Lewis 
IBM Printing Systems 
---------------------------------------------- 




"Jay Martin" <jmartin at altaworks.com>
Sent by: owner-ipp at pwg.org
11/07/2000 03:59 PM

 
        To:     ipp at pwg.org
        cc: 
        Subject:        Re: IPP> Proposed Resolution to BO Issue 4: requesting unsupported d 
attributes in query operations


I tend to agree with Bill Wagner on this one.  Despite the
many (confusing) choices, a single *preferred* choice would
be the best way to cultivate broad compatible support.

        ...jay


"Wagner,William" wrote:
>
> I would agree with allowing C or D, but I would still like a definite 
single
> recommendation.  In addition, note that C is confusing since it is an
> exception to an absolute, unqualified requirement  made earlier in the 
RFC.
>
> Bill Wagner
>
> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> Sent: Monday, November 06, 2000 9:07 PM
> To: ipp at pwg.org
> Subject: RE: IPP> Proposed Resolution to BO Issue 4: requesting
> unsupporte d attributes in query operations
>
> Reminder to indicate your preferences by Tuesday, November 7.
>
> Harry's suggestion seems to be the most reasonable, given that the 
current
> replies are in disagreement with each other:
>
> Namely:
>
> 1. don't change the standard which allows C or D
>
> 2. indicate in the Implementer's Guide a warning to client implementers 
that
> Bake Off 3 found a number of implementations that also did A (which is 
not
> in conformance with the standard).
>
> Tom
>
> -----Original Message-----
> From: Harry Lewis/Boulder/IBM [mailto:harryl at us.ibm.com]
> Sent: Thursday, November 02, 2000 13:25
> To: Hastings, Tom N
> Cc: ipp at pwg.org
> Subject: Re: IPP> Proposed Resolution to BO Issue 4: requesting
> unsupported attribu tes in query operations
>
> I do not support the proposal.
>
> The Model document specifies
>
> D)   successful-ok-attribute-or-value-ignored (0x0001)/ unsupported
>
> We made the exception following BO-1 to also allow
>
> C)   successful-ok-attribute-or-value-ignored (0x0001)/ no attributes
>
> I don't think we should loosen the specification further. I do think the
> Implementer's guide should warn Clients of the current BO findings.
>
> ----------------------------------------------
> Harry Lewis
> IBM Printing Systems
> ----------------------------------------------
>
> "Hastings, Tom N" <hastings at cp10.es.xerox.com>
> Sent by: owner-ipp at pwg.org
> 11/01/2000 08:16 PM
>
>
>         To:     ipp at pwg.org
>         cc:
>         Subject:        IPP> Proposed Resolution to BO Issue 4: 
requesting
> unsupported attribu tes
> in query operations
>
> Please indicate on the mailing list whether or not you support this
> proposed
> resolution to Issue 4 by Tuesday November 7.  Then I will update the
> Implementer's Guide and replace it in the IESG queue according to the 
IESG
> procedures.
>
> At the telecon today we discussed Bake Off Issue 4:
>
> ISSUE BO3-4:  Which status code does the Printer return for the
> Get-Printer-Attributes, Get-Job-Attributes, and Get-Jobs operations, 
when
> a
> client submits an unsupported "requested-attributes" value?  Also does 
the
> Printer return the "requested-attributes" attribute with (just) the
> unsupported values in the Unsupported Attributes Group like it MUST for
> all
> other attributes in this and all other operations?
>
> There are four combinations of status code and Unsupported Attributes
> Group:
>
>   A)   successful-ok (0x0000)/no attributes
>   B)   successful-ok (0x0000)/unsupported requested-attributes returned
>   C)   successful-ok-attribute-or-value-ignored (0x0001)/ no attributes
>   D)   successful-ok-attribute-or-value-ignored (0x0001)/ unsupported
> "requested-attributes" returned
>
> The standard requires (C) or (D) for the Get-Xxx operations if all
> sections
> of the standard are read.  The standard requires (D) for all other
> attributes for the Get-Xxxx operation and for all attributes for all 
other
> operations.
>
> All four combinations were present at the Bake Off for the Get-Xxxx
> operations, with a majority of implementations doing (A), one doing (B),
> and
> some doing (C) or (D).
>
> Discussion:
> We agreed that the purpose of a Bake Off isn't to change the standard to
> agree with implementations.  We also agreed that having alternatives for
> Printers usually makes it harder for clients.  We also agreed that we 
did
> not want to invalidate currently conforming Printer implementations, 
i.e.,
> ones that did (C) or (D).
>
> However, for this issue and because these are query operations, rather
> than
> operations that change the state of the Printer, we felt that allowing 
all
> four alternatives does not make it harder for clients and does not 
impact
> interoperability, because we think that most clients will:
>
> 1. treat the two success status codes the same for query (Get-xxx)
> operations
> 2. will probably ignore the Unsupported Attribute Group for query
> operations
> 3. will only look at the Printer or Job Attributes Group returned which
> will
> only contain requested attributes that are supported for query 
operations
>
> We could not even agree on which alternative to recommend for future
> implementations and hence could not even agree on deprecating any.
> Alternative (A) is simple, but some implementations want to handle ALL
> attributes and operations consistently and not make an exception for the
> Get
> operations with the "requested-attributes" operation attribute, i.e., 
such
> implementations want to do (D).  At Bake Off 1, several implementations
> found alternative (D) difficult, since they didn't have a list of
> supported
> attributes from which to compare the values of the 
"requested-attributes"
> operation.
>
> Therefore, we propose to explain in the Implementer's Guide (which is in
> the
> IESG queue, but is not yet approved by them), that a client should 
handle
> all four alternatives (which is easy as described above) and that 
Printers
> may do any one of the four alternatives.
>
> In the future, when an updated Model and Semantics document is produced,
> these same alternatives will be explained.  However, at present there is
> no
> opportunity to change the current RFCs.
>
> Please indicate on the mailing list whether or not you support this
> proposal
> by Tuesday November 7, before I update the Implementer's Guide and 
replace
> it in the IESG queue according to the IESG procedures.
>
> Thanks,
> Tom
>
> P.S. the entire mail thread is attached.
>
> -----Original Message-----
> From: Harry Lewis/Boulder/IBM [mailto:harryl at us.ibm.com]
> Sent: Monday, October 30, 2000 09:47
> To: Carl Kugler/Boulder/IBM
> Cc: hastings at cp10.es.xerox.com; ipp at pwg.org
> Subject: RE: IPP> IPP Bake-Off 3 issue 4
>
> I agree with Carl. I don't think the goal (or result) of interop testing
> should be to loosen the spec because of diverse findings. This does not
> yield interoperability! Diverse interpretations are a sign of an area 
(of
> the spec) that may have been unclear, unnecessarily complex or simply 
not
> needed.
>
> This is a case of mismatched redundant information. I think either ....
> a. Forcing the information to match
> b. Removing the redundancy
> ... would be helpful... but not just throwing our hands up and allowing
> any combination to be considered valid.
>
> ----------------------------------------------
> Harry Lewis
> IBM Printing Systems
> ----------------------------------------------
>
> Carl Kugler/Boulder/IBM at IBMUS
> Sent by: owner-ipp at pwg.org
> 10/30/2000 09:44 AM
>
>         To:     "Hastings, Tom N" <hastings at cp10.es.xerox.com>
>         cc:     ipp at pwg.org
>         Subject:        RE: IPP> IPP Bake-Off 3 issue 4
>
> To be really anal ytical, the spec still only allows D:
>
> <<<<<<<<<<<<<
> 3.1.7 Unsupported Attributes
> ...
> A Printer object MUST include an Unsupported Attributes group in a
> response
> if the status code is one of the following:
> 'successful-ok-ignored-or-substituted-attributes',
> 'successful-ok-conflicting-attributes',
> 'client-error-attributes-or-values-not-supported' or
> 'client-error-conflicting-attributes'.
> >>>>>>>>>>>>
>
> My opinion is that specifying four or more ways to accomplish the same
> thing just complicates matters and makes implementation more confusing.
> Back at bakeoff 1, the spec only allowed D.  I admit that I was one of
> those who implemented it wrong for bakeoff 1.  But when the spec was
> loosened up, I still got it wrong and ended up in camp A.  IBM is
> currently
> shipping three different implementations of "requested-attributes".  I
> don't consider this a good thing.
>
>      -Carl
>
> "Hastings, Tom N" <hastings at cp10.es.xerox.com> on 10/27/2000 06:36:07 PM
>
> To:   Carl Kugler/Boulder/IBM at IBMUS, ipp at pwg.org
> cc:
> Subject:  RE: IPP> IPP Bake-Off 3 issue 4
>
> I agree with Carl that the current standard only allows C and D.  But
> since
> so many implementations did A and since the client gets back the 
supported
> attributes anyway, whether or not the unsupported requested attributes 
are
> returned or not seems less important to the client.
>
> However, I disagree with Carl that we should tighten up the standard to
> allow only D.  That is the way the standard was written for the first 
Bake
> Off and we agreed to allow C.
>
> So the current standards allows C and D.  Since requesting unsupported
> attributes isn't really going to cause the client to get unexpected
> results
> (since the client will be looking at the supported returned attributes
> anyway), I favor adding A as allowed.  And we may as well allow B as 
well.
> No matter which of the 4 ways the Printer is written, the client doesn't
> have any extra work to work with all 4 ways:
>
> Until we add OPTIONAL operation attributes or OPTIONAL operation 
attribute
> values to the Get-Printer-Attributes operation, there is not much need 
for
> the client to look at the Unsupported Attribute group returned by the
> Printer at all.  (Currently the only other attribute that a Printer 
could
> return in the Unsupported Attributes Group is "document-format" with an
> unsupported document format that the client requested).
>
> So the client merely treats success (0) and
> Successful-attribute-or-value-ignored (1) status codes the same and then
> looks at the Printer Attributes Group returned.
>
> Lets here from others...
>
> Tom
>
> -----Original Message-----
> From: Carl Kugler/Boulder/IBM [mailto:kugler at us.ibm.com]
> Sent: Friday, October 27, 2000 13:44
> To: ipp at pwg.org
> Subject: Re: IPP> IPP Bake-Off 3 issue 4
>
> "Zehler, Peter" <Peter.Zehler at u...> wrote:
> > All,
> >
> > BO3-4: For get-printer-attributes operation submitted with an
> unsupported
> > "requested-attributes" value what is the return code and should an
> > unsupported attributes group be returned containing the
> requested-attributes
> > attribute and the unsupported value.  There are four possibilities of
> status
> > code and unsupported attribute:
> >    A)   successful-ok/no attributes
> >    B)   successful-ok/unsupported requested-attributes returned
> >    C)   Successful-attribute-or-value-ignored/ no attributes
> >    D)    Successful-attribute-or-value-ignored/ unsupported
> > requested-attributes returned
> >         The standard currently allows A, C, D.  Should the standard
> > be relaxed to include C.
> >
> I'm not sure I follow you here!
>
> Looks to me like the spec currently allows only C or D:
> <<<<<
> 13.1.4.12 client-error-attributes-or-values-not-supported (0x040B)
> ...
> For any operation where a client requests attributes (such as a 
Get-Jobs,
> Get-Printer-Attributes, or Get-Job-Attributes operation), if the IPP
> object
> does not support one or more of the requested attributes, the IPP object
> simply ignores the unsupported requested attributes and processes the
> request as if they had not been supplied, rather than returning this
> status
> code.  In this case, the IPP object MUST return the
> 'successful-ok-ignored-or-substituted-attributes' status code and MAY
> return the unsupported attributes as values of the 
"requested-attributes"
> in the Unsupported Attributes Group (see section 13.1.2.2).
> >>>>>
> Choice D would simplify the spec, since there wouldn't need to be any
> special exception for "requested-attributes";  it would be treated the
> same
> as any other attribute.  However, "requested-attributes" seems to be
> confusing to implement, since I have seen implementations all over the 
map
> on this.  I have even seen some imaginative responses that don't fall 
into
> any of the above possibilities (but not at the bakeoff).  Maybe we 
should
> settle on D, the simplest one to specify, then put a big chapter in the
> Implementer's Guide explaining the details.
>
>      -Carl
>
> > The implementations at the Bake-Off supported were
> > A-11, B-1, C-3, D-0
> >         Proposed Resolution: Allow all combinations
> >
> >





More information about the Ipp mailing list