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/blueroofmusichttp://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>>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20131210/6ba1b721/attachment.html>