[IPP] RFC: Identify-Printer mini-extension

[IPP] RFC: Identify-Printer mini-extension

[IPP] RFC: Identify-Printer mini-extension

Ira McDonald blueroofmusic at gmail.com
Tue Dec 10 17:40:08 UTC 2013


Hi Smith,

I pretty agree w/ you.  If the duration is brief (which was the original
intent of IPP Identify-Printer when proposed), then the cancel is
superfluous.

I don't think we can give a hard upper limit for the duration - instead
I suggest that implementations could support (e.g., via embedded
web server) changing the default times of various actions (e.g.,
blinking lights should probably last longer than audible signals).

I don't see the value in long durations (minutes) - tends to lead to
users cutting wires or taping over LEDs (there's a lively business
among independent mechanics in destroying stupid car alarms,
which studies have shown have no impact on reducing theft).

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


More information about the ipp mailing list