Smith,
On 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.
Agreed, I've been thinking the same thing and will try to put something together based on my understanding of the current model document.
>> 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/133858f3/attachment.html>