Subject: [IPP] RFC: Identify-Printer mini-extension

From: Michael Sweet <[email-masked]>
Date: Mon, 09 Dec 2013 14:53:35 -0500

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
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Ira McDonald <[email-masked]>
Date: Mon, 9 Dec 2013 15:04:09 -0500

Hi Mike,

I like your clarifications as suggested.

Are you suggesting a *tiny* document that updates JPS3 and extends
Identify-Printer?

It seems like it would be nice to handle this as a minor release update
to JPS3 (so that everyone sees it).  I know, process...process.  But this
seems like the cleaner fix to me.

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: [email-masked]
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 2:53 PM, Michael Sweet <[email-masked]> 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...
>
> (I considered adding this to IPPSIX, but since this has application
> outside of shared infrastructure/cloud deployments I think we should
> register it separately...)
>

---

From: Michael Sweet <[email-masked]>
Date: Mon, 09 Dec 2013 16:17:54 -0500

Ira,

> Are you suggesting a *tiny* document that updates JPS3 and extends

No, I really don't want to open up that can of worms.

> seems like the cleaner fix to me.

I know I don't have the cycles or the energy to update JPS3 right now.  Given our recent move to start accepting value registrations on the mailing list (with the mailing list serving as the durable source of information), I was hoping we could simply treat these as new value registrations for existing attributes and do the registration.  Both attributes are type2 and permit extension without full standards backing them...

---

From: Ira McDonald <[email-masked]>
Date: Mon, 9 Dec 2013 16:50:10 -0500

Hi Mike,

You're right.  Lost my mind.

Handle them w/ new values for existing attributes (same way
we handle Printer MIB TC updates for existing datatypes).

So we need to work out that process (I agree with you that a
durable pointer into the PWG email archives is sufficient).

Cheers,
- Ira

On Mon, Dec 9, 2013 at 4:17 PM, Michael Sweet <[email-masked]> wrote:

> I know I don't have the cycles or the energy to update JPS3 right now.
>  Given our recent move to start accepting value registrations on the
> mailing list (with the mailing list serving as the durable source of
> information), I was hoping we could simply treat these as new value
> registrations for existing attributes and do the registration.  Both
> attributes are type2 and permit extension without full standards backing
> them...
>

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Mon, 9 Dec 2013 22:28:35 +0000

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

---

From: Ira McDonald <[email-masked]>
Date: Mon, 9 Dec 2013 17:36:59 -0500

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

On Mon, Dec 9, 2013 at 5:28 PM, Kennedy, Smith (Wireless Architect) <
[email-masked]> 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
>
>
>
> > 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...
> >

---

From: "William A Wagner" <[email-masked]>
Date: Tue, 10 Dec 2013 00:34:54 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Ira
McDonald
Sent: Monday, December 09, 2013 5:37 PM
To: Kennedy, Smith (Wireless Architect)
Cc: <[email-masked]>
Subject: Re: [IPP] RFC: Identify-Printer mini-extension

Hi Smith,

Cheers,

- Ira

 <http://sites.google.com/site/blueroofmusic>
 <http://sites.google.com/site/highnorthinc>

On Mon, Dec 9, 2013 at 5:28 PM, Kennedy, Smith (Wireless Architect)
<[email-masked]> 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

> 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...

---

From: Ira McDonald <[email-masked]>
Date: Tue, 10 Dec 2013 08:51:30 -0500

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.

BTW - what about conflicts between two different services that receive
conflicting Identify-Xxx operations (or cancels)?

Cheers,
- Ira

On Tue, Dec 10, 2013 at 12:34 AM, William A Wagner <[email-masked]>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:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Ira
> McDonald
> *Sent:* Monday, December 09, 2013 5:37 PM
> *To:* Kennedy, Smith (Wireless Architect)
> *Cc:* <[email-masked]>
> *Subject:* Re: [IPP] RFC: Identify-Printer mini-extension
>
>
>
> Hi Smith,
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 10 Dec 2013 10:32:13 -0500

Smith,

*If* we were to adopt some notion of client-controlled duration, that would be major new semantics with defined defaults for each action.

However, I thought the purpose of adopting a 'cancel' action was to obviate the need for a duration, which is (currently) implementation specific behavior.  And I believe we were planning on adding guidance for Identify-Printer, both for the Client and Printer, to the IIG2.

As for System Control Service, it might be a service that implements Identify-Printer but it shouldn't be the only one.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 10 Dec 2013 10:46:35 -0500

Ira,

On Dec 9, 2013, at 5:36 PM, Ira McDonald <[email-masked]> wrote:
> ...
> rather than an individual service, be the target of this device-level operation?

I don't think so.  Clients are talking to a particular service, not generally the system control service.  Sending an Identify-Printer means "identify the device(s) used by this service".

> (in an existing attribute group), I suspect.

Technically that process is defined in RFC 2911 as "submit a registration through the IANA web site", which lands the registration in our hands.  And of course WG discussion, just as we do for MIB registrations.

However, PWG Process/3.0 already provides us with the required process for us (vs. the IETF):

9.2 Registration of Keywords and Values

Proposals for registrations of new keywords and values for existing elements shall follow the following process:

1)  Each Working Group will appoint a Maintenance Editor for their PWG Standard.

2)  Anyone can initiate a proposal by starting an e-mail discussion on the appropriate Working Group mailing list or submitting a Technical Brief describing the request.

3)  After there is general agreement on the mailing list for the proposal, the Working Group Chair or the proposer issues a Call for Objection (see below) on the pwg-announce mailing list with a description of the proposal that includes:

⎯  A description of the requirement being met or the problem being solved.

⎯  A description of the proposed solution.

⎯  A detailed description of the changes to the standard or schemas which are proposed to be integrated into the standard at a future date.

4) To make the status of proposed registrations clear to PWG participants and others, the Working Group Chair will ensure that approved registrations are documented in the following Working Group directory:

ftp://ftp.pwg.org/pub/pwg/[working group]/approved-addenda

where [working group] is the project acronym. When the standard is revised and re-approved, any relevant registrations or extensions that were included in the revision will be removed from the addenda directory.

9.3 Registration of New Operations and Semantic Elements

Proposals for registration or extension of a standard to include new operations or semantic elements for existing groups shall adhere to the following process:

1)  Anyone can initiate a proposal by submitting a Technical Brief to the appropriate Working Group describing the registration or extension. The Technical Brief should be able to function as a complete, standalone technical description of the proposed extension with formal references to the relevant standard.
2)  After there is general agreement in the Working Group, the Working Group Chair will issue a Last Call for comments on the proposal. Upon successful Last Call completion, the Working Group Chair may issue a Call for Objection on the pwg-announce mailing list or continue with PWG Formal Approval for a Technical Brief.
3)  To make the existence and status of the approved Technical Brief clear to PWG participants and others, the Working Group Chair will ensure that approved registrations are documented in the following Working Group directory: ftp://ftp.pwg.org/pub/pwg[working group]/approved-addenda, where [working group] is the project acronym.
When the standard is revised and re-approved, any relevant registrations or extensions that were included in the revision will be removed from the addenda directory.

9.4 Compatible Extension of a Standard that Includes Major New Element Groups or Objects

Any extension to a PWG standard that includes the addition of major new element groups or objects will be treated as a revision of the standard and shall follow the Formal PWG Standards-track Process.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 10 Dec 2013 11:03:50 -0500

Bill,

I humbly disagree.  I am a Client trying to use a Print service.  I may or may not know how to or be able to talk to a System Control service.  All I care is that I can confirm which physical device my output will come out on if I submit a job to that Print service.

Services of all kinds are able to access a physical device's subunits today, even in the Semantic Model.  There is no reason to treat Identify-Printer/Device differently than Create-Job.

On Dec 10, 2013, at 12:34 AM, William A Wagner <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On Behalf Of Ira McDonald
> On Mon, Dec 9, 2013 at 5:28 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:

---

From: Michael Sweet <[email-masked]>
Date: Tue, 10 Dec 2013 11:36:58 -0500

Ira,

On Dec 10, 2013, at 8:51 AM, Ira McDonald <[email-masked]> wrote:

> Hi Bill,
> 
> I agree with you - that's what I was realizing when I wrote my previous note.

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...

> 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.

> On Tue, Dec 10, 2013 at 12:34 AM, William A Wagner <[email-masked]> wrote:
> Ira,
>

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Tue, 10 Dec 2013 17:07:46 +0000

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

---

From: Ira McDonald <[email-masked]>
Date: Tue, 10 Dec 2013 12:17:11 -0500

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

On Tue, Dec 10, 2013 at 12:07 PM, Kennedy, Smith (Wireless Architect) <
[email-masked]> 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
>
>
>
> 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...
>
> 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.
>

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Tue, 10 Dec 2013 17:30:52 +0000

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 <[email-masked]> wrote:

> On Tue, Dec 10, 2013 at 12:07 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:

---

From: Ira McDonald <[email-masked]>
Date: Tue, 10 Dec 2013 12:40:08 -0500

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

On Tue, Dec 10, 2013 at 12:30 PM, Kennedy, Smith (Wireless Architect) <
[email-masked]> wrote:

> Does limiting the duration obviate the need for the additions, then?  If
> the duration is brief, why provide a cancel option?
>
> Smith
>
>
>
>> 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.
>>
>> On Tue, Dec 10, 2013 at 12:34 AM, William A Wagner <[email-masked]
>> > wrote:
>>
>>> Ira,
>>>
>>> > 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.
>>> >

---

From: Michael Sweet <[email-masked]>
Date: Tue, 10 Dec 2013 13:28:41 -0500

Smith,

> 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…

Agreed, I've been thinking the same thing and will try to put something together based on my understanding of the current model document.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 10 Dec 2013 13:47:46 -0500

Smith,

> 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.

---

From: "William A Wagner" <[email-masked]>
Date: Tue, 10 Dec 2013 14:10:14 -0500

How brief is the Identify signal?  It will probably be both implementation
and identify type dependent. A 10-second flash of a message on a screen on a
printer would probably be useless unless the observer were already looking
at the screen. But a 10- second beep might be more than enough. Ideally, the
implementation would allow local cancel, so the person for whom the identify
was intended could shut it off. But I think that allowing for remote cancel
is desirable, if not mandatory.

The idea of illustrations for Identify is interesting. Consideration of the
identify capability requires going from the conceptual to the physical, and
points out an inconsistency between the IPP model and (at least my
conception of ) the Semantic Model (which has hung up Cloud work.)  Coming
out of the MFD work, an SM Device is "An abstract object representing a
hardware component that implements one or more Imaging Services."  Further,
an SM  System is "The object handling interaction that needs to be with the
MFD as an entity rather than a specific Service".   It can therefore be
argued that the System elements refer  to the Device. And is must be the
physical device that is identified. IPP evolves from a "Printer" entity
and, as far as I can tell, the concept of System does not yet exist.there
are just Services. I  suspect that in IPP, the System Control Service will
refer to the "Printer", notwithstanding that rather nebulous definition of
Printer as "Listener for incoming IPP session requests and receiver of
incoming IPP operation requests that represents one or more Physical Devices
or a Logical Device. " (but would appreciate being corrected if that is
wrong).  An IPP Physical Device is "a hardware implementation of a endpoint
device, e.g., a marking engine, a fax modem, etc.", that appears to
correspond to a subunit in the Semantic Model, and cannot be addressed by a
Client. 

Because the  IPP Physical Device is what should be identified but cannot be
accessed, I recognize and agree with  Mike's contention that IPP Identify
should be a Service operation since the User requesting Identify is
communicating with an Imaging  Service and the Service usually knows what
IPP Device it is using (although, in a case such as  a Print Service using
multiple marking engines, perhaps not).  Perhaps this carries over to the
SM, so that Identify operations to a Service  cause an identification of the
endpoint subunit used by that Service (although it most cases, the Identify
will be of the MFD).  Going from the Abstract to the Physical has some
problems.

Thanks,

Bill Wagner

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kennedy,
Smith (Wireless Architect)
Sent: Tuesday, December 10, 2013 12:31 PM
To: Ira McDonald; Michael Sweet
Cc: <[email-masked]>
Subject: Re: [IPP] RFC: Identify-Printer mini-extension

Does limiting the duration obviate the need for the additions, then?  If the
duration is brief, why provide a cancel option?

Smith

Hi,

I was wrong.

Cheers,

 -  Ira

On Tue, Dec 10, 2013 at 12:07 PM, Kennedy, Smith (Wireless Architect)
<[email-masked]> 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

Ira,

Hi Bill,

IMHO, cancel should only apply to the identification done by that service,
not to all services.

Cheers,

- Ira

On Tue, Dec 10, 2013 at 12:34 AM, William A Wagner <[email-masked]>
wrote:

Ira,

Bill Wagner

Hi Smith,

Cheers,

- Ira

Smith