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: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Kennedy,
Smith (Wireless Architect)
Sent: Tuesday, December 10, 2013 12:31 PM
To: Ira McDonald; Michael Sweet
Cc: <ipp at pwg.org>
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
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/blueroofmusic
<http://sites.google.com/site/highnorthinc>
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/blueroofmusic
<http://sites.google.com/site/highnorthinc>
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/blueroofmusic
<http://sites.google.com/site/highnorthinc>
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.orghttps://www.pwg.org/mailman/listinfo/ipp
_______________________________________________
ipp mailing list
ipp at pwg.orghttps://www.pwg.org/mailman/listinfo/ipp
_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
_______________________________________________
ipp mailing list
ipp at pwg.orghttps://www.pwg.org/mailman/listinfo/ipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20131210/50826a1c/attachment.html>