IPP> OPS - Proposal to go back to precluding 'out-of-band' values withvalues

IPP> OPS - Proposal to go back to precluding 'out-of-band' values withvalues

IPP> OPS - Proposal to go back to precluding 'out-of-band' values withvalues

Carl-Uno Manros carl at manros.com
Tue Mar 21 22:29:52 EST 2000


Ron,

In response to your comment about phone conference decisions and minutes.

First, we don't make decisions in the phone conferences. We usually look at
the presented alternatives given in input documents or email messages and
tend to hand out assignments to do further work or write up new alternatives
that have come up in the discussions. We used to have a permanent note taker
earlier, but when he resigned we never found a new one to take over.
The job is still open for anybody who wants to volonteer.

Carl-Uno

> -----Original Message-----
> From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of Ron
> Bergman
> Sent: Tuesday, March 21, 2000 6:05 PM
> To: Hastings, Tom N
> Cc: ipp
> Subject: Re: IPP> OPS - Proposal to go back to precluding 'out-of-band'
> values withvalues
>
>
> Tom,
>
> I must have missed some of the emails, since I don't recall any serious
> problems with extending parsers to allow new out-of-band values to
> have a non-zero value.  However, I don't see a strong need for the
> value to be present as proposed for 'any-value'.  So, I have no
> objection to Yet Another Proposal (YAP). ;-)
>
> But why are you proposing the name change to 'custom'?  This name
> could have implied meanings which are not appropriate.  I much
> prefer keeping the name 'any-value'.  An alternative name suggestion
> is 'admin-type', short for "it can be administratively defined."
>
> Again, I cannot attend the conference call tomorrow, due to meeting
> conflicts.  Long time ago there were meeting minutes that summarized
> the decisions made in the conference calls.  Now, the only minutes
> are deeply imbedded in new documents.  Sure would be nice to see
> minutes again.  I am sure that there are many who are unable to
> participate that would like to see the decisions made.
>
>     Ron Bergman
>     Hitachi Koki Imaging Solutions
>
>
> "Hastings, Tom N" wrote:
>
> > After hearing the problems with existing parsers on extending
> IPP to allow
> > new out-of-band values to have a non-zero value, it appears prudent to
> > abandon such an extension.  Please send comments to the mailing
> list.  We
> > will also discuss, tomorrow, Wednesday, 3/22, on the IPP telecon.
> >
> > Instead, lets replace the proposed 'any-value' out-of-band
> value which had
> > an attribute syntax value with a simpler 'custom' out-of-band
> value which
> > MUST have a zero length.  The 'custom' out-of-band value (as with the
> > 'any-value') is used in a Get-Printer-Supported-Values response
> for as one
> > of the values of a requested "xxx-supported" attribute to
> indicate that the
> > System Administrator can set custom values using the
> > "Set-Printer-Attributes" operation.
> >
> > Here is the suggested updates to the "Job and Printer Set Operations"
> > document:
> >
> > 15.1    Changes to the March 8, 2000 version to make the March 21, 2000
> > version
> > The following changes have been made to the March 8, 2000
> version to make
> > the March 21, 2000 version as a result of the IPP WG telecons
> and mailing
> > list discussion:
> > 1.      Changed the name of the 'any-value' out-of-band value
> to 'custom'.
> > Removed the idea of encoding the attribute syntax that the 'custom'
> > out-of-band value goes with.  Instead, the spec for the
> attribute defines
> > whether or not the 'custom' out-of-band value can be used.
> > 2.      Clarified that the 'custom' out-of-band value can be used in
> > combination with other values of an "xxx-supported" Printer attribute.
> > 3.      Clarified that an implementation is not prevented from
> supporting
> > some 'name' attribute values for "xxx-supported"
> out-of-the-box, if desired.
> > But these values would be returned in a Get-Printer-Supported-Values
> > response, such like keywords are.
> >
> >
> > 8.3     'custom' out-of-band attribute value
> > The 'custom' out-of-band attribute value MAY be used as one of
> the values of
> > an "xxx-supported" Printer attribute to indicate that the
> client can supply
> > custom values in a request.  The client MUST supply any such
> values in the
> > particular attribute syntax explicitly defined for that attribute.
> > See section 4.3 in this document for an example definition of
> the usage of
> > the 'custom' out-of-band attribute value in any "xxx-supported"
> attribute
> > returned in a Get-Printer-Supported-Values response.
> >
> > 8.3.1   Encoding of the 'custom' out-of-band attribute value
> > The encoding of the 'custom' out-of-band attribute value is 0x17 (see
> > [ipp-pro]).  The value-length MUST be 0 and the value empty.
> >
> > 1.1     Get-Printer-Supported-Values Operation
> > This OPTIONAL operation allows a client to request the values that the
> > Printer allows in the Set-Printer-Attributes operation for
> "xxx-supported"
> > attributes.  If the Printer supports the Set-Printer-Attributes
> operation
> > AND some of its "xxx-supported" Printer attributes are
> settable, then the
> > Printer MUST also support this operation.  This operation has identical
> > request/response attributes to the Get-Printer-Attributes operation in
> > IPP/1.1 [ipp-mod].  The operation also behaves identically to the
> > Get-Printer-Attributes operation in IPP/1.1 [ipp-mod] with the following
> > exceptions:
> > 1.      The Get-Printer-Supported-Values operation supports only
> > "xxx-supported" attributes.
> > 2.      The Get-Printer-Attributes operation returns the
> current value of
> > specified attributes while the Get-Printer-Supported-Values operation
> > returns values that permit a client to determine what values of
> > "xxx-supported" attributes the Printer supports in the
> > Set-Printer-Attributes operation.
> > 3.      If an implementation does not support setting an
> attribute that is
> > requested, it MUST NOT return that attribute in the Printer
> Attributes Group
> > of the Get-Printer-Supported-Values response.  Furthermore, in
> such a case,
> > as in the Get-Printer-Attributes response, the Unsupported
> Attributes Group
> > of the response NEED NOT contain the "requested-attributes" operation
> > attribute with any supplied values (attribute keywords) that
> were requested
> > by the client but are not supported or are not settable by the
> IPP Printer.
> > 4.      The Get-Printer-Supported-Values operation does not return any
> > values for any "xxx-supported" attributes that were configured
> by the System
> > Administrator using the Set-Printer-Attributes operation.
> Instead, if the
> > Set-Printer-Attributes operation allows the System Administrator to
> > customize the Printer's "xxx-supported" attribute by adding
> arbitrary values
> > of a specified attribute syntax, then the Get-Printer-Supported-Values
> > operation MUST return the 'custom' out-of-band attribute value
> (see section
> > 8.3) as one of the values of the "xxx-supported" attribute.  In
> other words,
> > the 'custom' out-of-band attribute value indicates that the Printer
> > implementation supports clients setting arbitrary values for that
> > "xxx-supported" attribute as long as the value is of the
> attribute syntax
> > defined for that attribute.
> > For example, if the Get-Printer-Supported-Values operation
> returns several
> > keywords as the value of the "media-supported" attribute, then the
> > Set-Printer-Attributes operation MUST accept any of these
> keywords as values
> > for the "media-supported" attribute.  If the
> Get-Printer-Supported-Values
> > operation returns a 'custom' out-of-band attribute value as one of the
> > values of the "media-supported" attribute, then the
> Set-Printer-Attributes
> > operation MUST accept any value whose attribute syntax is
> 'name' as values
> > for the "media-supported" attribute.
> > The Get-Printer-Supported-Values MAY return the 'custom' out-of-band
> > attribute value for any IPP/1.1 or extension Job Template
> attribute if the
> > implementation supports allowing the System Administrator to
> add values to
> > the "xxx-supported" attribute using the Set-Printer-Attributes
> operation.
> > In this case, the Printer MUST accept any value of the correct attribute
> > syntax in a Set-Printer-Attributes operation that is setting
> that attribute.
> > For "xxx-supported" attributes that are defined with a choice
> of attribute
> > syntaxes, such as 'keyword | name', it is the 'name' attribute
> syntax that
> > the System Administrator can use to add new values, not the 'keyword'
> > attribute syntax.  For IPP/1.1 this requirement includes the
> following Job
> > Template attributes:
> >                 media-supported
> >                 job-hold-until-supported
> >                 job-sheets-supported
> > For "xxx-supported" attributes that are defined to have only a single
> > attribute syntax, the 'custom' out-of-band value indicates that
> the Printer
> > will accept any value of that attribute syntax in a
> Set-Printer-Attributes
> > request for that "xxx-supported" attribute.
> > If the 'custom' out-of-band attribute value is not one of the
> values of an
> > "xxx-supported" attribute returned in a Get-Printer-Supported-Values
> > response, then the Printer MUST NOT allow the Set-Printer-Attributes
> > operation for that attribute to contain a value that is not one of the
> > explicit values returned in a Get-Printer-Supported-Values response.
> > See Appendix B for a full list of values returned by this operation.
> >
> > Send any comments to the mailing list.
> > Thanks,
> > Tom
>
>




More information about the Ipp mailing list