Yes, we agreed to add a TTL to the registration (consistent w/ notification
The Device-Keep-Alive operation was renamed Get-Notifications (to align w/
The notifications *are* asynchronous from the Cloud Imaging Service to the
(keep-alive, jobs-available, etc.). The in-band IPP Get-Notifications
introducing XMPP or some other notification transport.
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
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, Sep 30, 2013 at 7:24 PM, Randy Turner <rturner at amalfisystems.com>wrote:
>> Hi All,
>> From today's conference call, I noticed there was a discussion regarding
> registration lifetimes -- the cloud service would be the potential
> bottleneck for scalability, so it might be a good idea for
> a "registration-response" to include a time-to-live (TTL) value. This TTL
> value would indicate to the device when the registration will expire (from
> the perspective of the cloud service). The device would have to
> re-register before the TTL expires
>> This re-registration *could* be used to obviate the need for an
> application-layer keep alive.
>>> I was curious if the notifications that were discussed were meant to be
> "asynchronous" -- meaning, the cloud would asynchronously notify a device
> or client regarding "something" happening in the cloud.
> cloud mailing list
>cloud at pwg.org>https://www.pwg.org/mailman/listinfo/cloud>-------------- next part --------------
An HTML attachment was scrubbed...