[IPP] RFC: Identify-Printer mini-extension

[IPP] RFC: Identify-Printer mini-extension

[IPP] RFC: Identify-Printer mini-extension

William A Wagner wamwagner at comcast.net
Tue Dec 10 05:34:54 UTC 2013


I suggest that what is being identified is the physical device, and that the
System Control Service is the proper recipient. 

Bill Wagner


From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Ira
Sent: Monday, December 09, 2013 5:37 PM
To: Kennedy, Smith (Wireless Architect)
Cc: <ipp at pwg.org>
Subject: Re: [IPP] RFC: Identify-Printer mini-extension


Hi Smith,

Tricky.  The "identify action duration" would be a new attribute (which
would require a revision of JPS3 spec - yuck).

Mike's right that IPPSIX is the wrong place to do this - the conformance

shouldn't have anything to do with IPPSIX.

I also don't think that System Control Service should get into this business

- or maybe I'm crazy and that actually is the *right* place?  Should SCS,

rather than an individual service, be the target of this device-level

Someday, we need a lightweight IPP registration for whole new attributes

(in an existing attribute group), I suspect.



- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
mailto: blueroofmusic at gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434


On Mon, Dec 9, 2013 at 5:28 PM, Kennedy, Smith (Wireless Architect)
<smith.kennedy at hp.com> wrote:

IMHO, these look fine.  I wonder if the "identify action duration" needs to
be covered by something?  Does the System Control Service need to concern
itself with this domain?


On 2013-12-09, at 12:53 PM, Michael Sweet <msweet at apple.com> wrote:

> All,
> During our last Cloud Imaging Model WG meeting, we discussed having the
ability to explicitly cancel a previous Identify-Printer operation.  The
consensus during that meeting was to add a new "identify-actions" keyword
('cancel') that would cancel any active identification mechanism.
> In addition, a new "printer-state-reasons" keyword ('identifying-printer'
was proposed, although given the existing 'identify-printer-requested' value
I like adding 'identify-printer-active' instead) would be added to allow a
Client to discover whether a printer is currently identifying itself using
an action other than 'cancel', which by definition stops any active
identification and removes the new keyword from the "printer-state-reasons"
> The official registration would look like this:
>  Attributes (attribute syntax)
>    Keyword Attribute Value                       Reference
>    -----------------------                       ---------
>  identify-actions (1setOf type2 keyword)         [PWG5100.13]
>    cancel
>  printer-state-reasons (1setOf type2 keyword)    [RFC2911]
>    identify-printer-active
> Thoughts?
> (I considered adding this to IPPSIX, but since this has application
outside of shared infrastructure/cloud deployments I think we should
register it separately...)
> _______________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp

ipp mailing list
ipp at pwg.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20131210/08bb3864/attachment.html>

More information about the ipp mailing list