[IPP] RFC: Identify-Printer mini-extension

[IPP] RFC: Identify-Printer mini-extension

[IPP] RFC: Identify-Printer mini-extension

Kennedy, Smith (Wireless Architect) smith.kennedy at hp.com
Tue Dec 10 17:07:46 UTC 2013


I agree with Mike on this.  If I am a client and communicating with / using IPP Printers hosted on an IPP print server, I would want the Identify-Printer to map to the IPP Printer, which may or may not be implemented as a sub-system of the physical hardware of the print server (as represented by the System Control Service).

From that cloud discussion the other day, and this topic, I really feel like we need to have pictures, so that people can discuss topics from unambiguous scenarios.  Trying to verbally describe the topology of a graph of edges and vertices can be awfully error prone.

Smith



On 2013-12-10, at 9:36 AM, Michael Sweet <msweet at apple.com> wrote:

> Ira,
> 
> On Dec 10, 2013, at 8:51 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
> 
>> Hi Bill,
>> 
>> I agree with you - that's what I was realizing when I wrote my previous note.
>> Identify-Xxx is a device-level operation.
> 
> I disagree, Identify-Xxx is a service-level operation that causes the identification of any physical device(s) associated with that service.  We don't provide device interfaces, just service interfaces...
> 
>> BTW - what about conflicts between two different services that receive 
>> conflicting Identify-Xxx operations (or cancels)?
> 
> AFAIK, coordination of subunits between services is implementation-defined behavior.  If one service is using the buzzer then another service has to wait (or error-out) to use it.
> 
> IMHO, cancel should only apply to the identification done by that service, not to all services.
> 
> 
>> 
>> Cheers,
>> - 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
>> http://sites.google.com/site/blueroofmusic
>> http://sites.google.com/site/highnorthinc
>> 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 Tue, Dec 10, 2013 at 12:34 AM, William A Wagner <wamwagner at comcast.net> wrote:
>> Ira,
>> 
>> 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 McDonald
>> 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 operation?
>> 
>> Someday, we need a lightweight IPP registration for whole new attributes
>> 
>> (in an existing attribute group), I suspect.
>> 
>>  
>> 
>> Cheers,
>> 
>> - 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
>> http://sites.google.com/site/blueroofmusic
>> http://sites.google.com/site/highnorthinc
>> 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?
>> 
>> Smith
>> 
>> 
>> 
>> 
>> 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" attribute...
>> >
>> > 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
>> https://www.pwg.org/mailman/listinfo/ipp
>> 
>>  
>> 
>> 
>> _______________________________________________
>> ipp mailing list
>> ipp at pwg.org
>> https://www.pwg.org/mailman/listinfo/ipp
> 
> _______________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20131210/4117e70d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3319 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20131210/4117e70d/attachment.p7s>


More information about the ipp mailing list