Smith,
On Dec 10, 2013, at 12:30 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
> Does limiting the duration obviate the need for the additions, then? If the duration is brief, why provide a cancel option?
Currently we provide no guidance for the duration of each identify action, so providing a 'cancel' is a way to force the printer to stop beeping, flashing, etc. regardless of printer configuration by the user/operator/administrator.
>> Smith
>>>> On 2013-12-10, at 10:17 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>>> Hi,
>>>> I was wrong.
>>>> I agree with Mike and Smith that it's a service-level operation.
>>>> I also agree with Mike that we should not add "identify duration"
>> at all. The identity action should be brief (seconds, not minutes).
>> Otherwise, it becomes an annoyance for a shared workgroup
>> printer in the modern (barbarian) cubicles style of office.
>>>> 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:07 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>> 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>>>>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20131210/fc2cd4d1/attachment.html>