[IPP] Some thoughts on the future directions of the IPP WG

[IPP] Some thoughts on the future directions of the IPP WG

[IPP] Some thoughts on the future directions of the IPP WG

Randy Turner rturner at amalfisystems.com
Mon Aug 19 19:30:35 UTC 2013


Hi Mike 

I think we could do more work on "print by reference" to make it more of a usable feature

Randy

On Aug 19, 2013, at 2:06 PM, Michael Sweet <msweet at apple.com> wrote:

> All,
> 
> I've been talking privately with several of you to get a sense of what our priorities should be for IPP going forward.  What follows is a suitably anonymized version of those discussions and my own tentative conclusions, with the goal to continue development of useful specs that will get implemented.  Comments, as always, are welcome.
> 
> 
> CURRENT SPECS
> 
> - IPP FaxOut: We all want fax to die, but this is basically done.
> 
>       Conclusion: We should finish the IPP FaxOut Service spec (update
>       and put to a formal vote) so products that do still support fax
>       use a common interface.
> 
> 
> - IPP Finishings 2.0: Several vendors have products depending on the extensions for folding and punching.
> 
>       Conclusion: Continue development of this update to 5100.1.
> 
> 
> - IPP Scan: Everyone has their own protocol and no one will step up to be editor of the document since there is no incentive to change things.
> 
>       Conclusion: We should put IPP Scan in hybernation until
>       someone steps up to be the editor and we have vendors willing
>       to implement it.
> 
> 
> - IPP Shared Infrastructure Extensions (IPPSIX): There is definite interest in continuing this work, but concerns about the initial setup/configuration, i.e., there is no registration defined here so it isn't a complete solution.
> 
>       Conclusion: Continue developing this document, look at how we
>       can address registration, here or in another specification.
> 
> 
> - IPP Transaction-Based Printing Extensions; Several vendors now have products depending on the extensions for paid/quota/release printing.
> 
>       Conclusion: Finish last call and formal vote.
> 
> 
> 
> 
> FUTURE SPECS (CHARTERED/ERRATA)
> 
> - IPP EmailIn/EmailOut: No interest. "We already do email on our clients."
> 
>       Conclusion: Drop this from our roadmap.
> 
> 
> - IPP FaxIn: No interest, most MFDs can be configured to print or email incoming fax documents, and email takes care of fax document ingestion.
> 
>       Conclusion: Drop this from our roadmap.
> 
> 
> - IPP Job Extensions 1.1: Seems like a lot of work to add a "job-mandatory-attributes-supported (boolean)" attribute.
> 
>       Conclusion: Discuss options in the WG - separate "errata"
>       document?
> 
> 
> - IPP Multifunction: Doesn't make a lot of sense if we don't have an answer for all of the functions of a MFD.
> 
>       Conclusion: Put IPP Multifunction into hibernation until
>       we have an answer for at least scanning.
> 
> 
> - IPP Output Bins 1.1: Seems like a lot of work to add a "roll" output-bin value.
> 
>       Conclusion: Discuss options in the WG - separate "errata"
>       document?
> 
> 
> - IPP Resource: We've tried doing a resource service before. Firmware updates seems to be the "killer feature" for this, although fonts and forms are also commonly cited use cases.
> 
>       Conclusion: We should revisit an IPP Resource service
>       with specific use cases in mind. We should also survey
>       our members to gauge interest in such a service.
> 
> 
> - IPP System Control Service: Everyone likes the idea of read-only access to device attributes a la the Printer MIB and IDS Health Assessment Attributes. Listing of services would be nice, particularly for multifunction.  Creation of services is more problematic (do we need "service tickets"?), as is write access to device attributes and power management.  We need more in the realm of AAA, ACLs, and roles.
> 
>       Conclusion: Break this into two versions: a 1.0 that is
>       read-only and a 2.0 that extends it to address service
>       creation/deletion, write access, power management, AAA,
>       and ACLs.
> 
> 
> - IPP Transform Service: The current Semantic Model service is hidden and probably isn't suitable as an externally-accessible service via IPP.
> 
>       Conclusion: Put IPP Transform into hibernation until we
>       have something useful to expose.  Focus on IPPSIX's
>       transform capabilities for now.
> 
> 
> _________________________________________________________
> 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/20130819/e8b50403/attachment.html>


More information about the ipp mailing list