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

Jay Martin jmartin at altaworks.com
Tue Nov 7 17:59:37 EST 2000


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