Subject: Re: [IPP] New Cloud-related operations for IPP System Service

From: Michael Sweet <[email-masked]>
Date: Mon, 01 Dec 2014 10:58:39 -0500

Ira,

> On Nov 26, 2014, at 11:51 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Mike,
> 
> For operation (3) DeregisterOutputDevice, I was thinking of the case
> where a running service (Print in the near term) crashes (and this is
> noticed by System Service, let us hope).  If DeregisterOutputDevice
> is (redundantly) supported by the System Service, then an Administrator
> could do the cleanup for the Infrastructure Printer (who might queue
> jobs).

Presumably DeregisterSystem is the way for the System service to clean up references to the output device in all services it manages, even those that have "crashed" (which is a state we don't really model semantically...) If you want to deregister from a single service, you talk to that one service.

> Or, I'm crazy, and the System Service would automatically do this
> cleanup internally and no external operation needs to be exposed.
> But that risks a Deregister when the crashed service can be
> successfully automatically restarted by the System Service after
> a brief interval of unavailability.  

I would assume that self-healing of this sort would be expected of a cloud/SDN solution, with notifications sent to the relevant admin/operator. And I don't think we can necessarily recover from all situations like this - the Proxy might well have gotten a response from its Deregister-Output-Device request, with the cloud service crashing after successfully sending a response, so we have to hope that implementations will provide a way to perform manual cleanup as needed...

> I have mixed feelings about the reliability (and advisability) of 
> automatic recovery by the System Service for crashed or stalled 
> Job Services.

Typically servers will be restarted a certain number of times in order to provide continuous service, with an alert going out for each crash/failed restart. And such things are typically configurable by service and various events - I have such things setup with our PWG.org <http://pwg.org/> server instance, for example...

_________________________________________________________
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, 1 Dec 2014 15:51:43 -0500

Hi Mike,

Thanks - that all makes sense to me.

Oh - the other new operation for System Service should be
Get-Printer-Attributes that allows a simple "ipp" URI (w/out
any authentication?) that does a "magic" redirect to the default
print service, right?

BTW - what *is* the default print service?  The first one in
the list of configured-printers (services) that's of type print?

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 1, 2014 at 10:58 AM, Michael Sweet <[email-masked]> wrote:

> Presumably DeregisterSystem is the way for the System service to clean up
> references to the output device in all services it manages, even those that
> have "crashed" (which is a state we don't really model semantically...) If
> you want to deregister from a single service, you talk to that one service.
>
> I would assume that self-healing of this sort would be expected of a
> cloud/SDN solution, with notifications sent to the relevant admin/operator.
> And I don't think we can necessarily recover from all situations like this
> - the Proxy might well have gotten a response from its
> Deregister-Output-Device request, with the cloud service crashing after
> successfully sending a response, so we have to hope that implementations
> will provide a way to perform manual cleanup as needed...
>
> Typically servers will be restarted a certain number of times in order to
> provide continuous service, with an alert going out for each crash/failed
> restart. And such things are typically configurable by service and various
> events - I have such things setup with our PWG.org server instance, for
> example...
>

---

From: Michael Sweet <[email-masked]>
Date: Mon, 01 Dec 2014 16:36:15 -0500

Ira,

> On Dec 1, 2014, at 3:51 PM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Mike,
> 

Right, without authentication to allow Clients to discover printers.  Most IPP clients cannot support authentication of Get-Printer-Attributes, but instead need the "get" call to setup a queue and *then* they can authenticate...

> the list of configured-printers (services) that's of type print?

I'd leave that as implementation-defined - default queue could be designated by an admin or could be a release queue (so nothing gets printed until the user releases the job at a printer...)